The Drupal subject reappears in the Perl blogsphere regularly. In my opinion there are three key architectural choices for 'portable plugin apps'. First, obviously, the plugins needs to be highly independent. Second they need to be controlled by pages - that is the page decide what plugins to use. To meet the independence requirement, in the Plack world, the obvious choice for the plugis is that they are simply PSGI apps that in body return a page fragment. This will make it easy to plugin existing wikis and blogs - you just need to remove the header and footer templates and voila you have a plugin instead of a standalone app. You can also use all the Plack infrastructure, for example the Plack::Client if you ever care about scaling your application.
There is one thing that I forgot in the first version of this post - Javascript and CSS. Applications are rarely pure HTML these days - we'll need also some way to gather all the js and css files that the plugins use and link them in the main page. At the main page side this is nothing special - it is not unusual that applications concatenate many Javascript libraries into one file automatically - so this is already well explored. The complication arises from the requirement to pass something more structured then just a HTML fragment in the Plack response from the plugins.
More interesting is the other key choice - how the plugins are supposed to be plugged in. That is how page handlers will choose what plugin to use and what data pass there. As much as I hate the 'program in XML' approach to language syntax - the obvious established standard here is ESI. Maybe we could even steal the semantics and replace the syntax with something saner? Plack based ESI implementation was submitted as an example GSOC idea - I really hope some student will pick it up.
Update: Added js/css handling consideration (thanks for cezio comment below).
Saturday, March 26, 2011
Subscribe to:
Post Comments (Atom)
4 comments:
http://blogs.perl.org/users/leo_lapworth/2011/02/portable-plugin-apps.html
I was thinking the same.
For 'interoperability' I was wondering about setting up roles for requirements, e.g. your $user_obj can be anything as long as it provides $user_role method, same for $cache, $db etc
But just a musing rather than something I have time for.
Embedding html content from 'external' applications is an error-prone and risky task. Conceptually it seems to be ok: you have host and embedded application, remove unnecessary content from embedded and you're in home. But, the flaw is that html apps are self-sufficient, and when mixed, they might fight for resources: css/js/markup structure/processing paths. Html is not designed for embedding. Once merged, both markups are equal. Well, maybe with exception for iframes, but this only shows how this model is broken here.
General reflection is that PSGI (as well as any other WSGI-like interface) is not designated for component approach to web applications. This is interface just for serving, all the rest is up to served application.
As for Drupal, it is an example for quite distinctive architecture - OOP without OOP: concepts are object oriented, but the code is functional. There is of course good rationale for such approach - to overcome limitations/flaws of OOP model in PHP ( http://drupal.org/node/547518 )
@cezio - thanks for the comment and the link. I am adding js/css assembling to the list. I can agree that whole idea is risky - but I would still like to play with it :)
@Ranguard - you know that the first link in my post is to your to your article? Ad interoperability - I need to play a bit more with that - but in general I like how the Plack middlewares usually provide a callback interface instead of exposing some 'setup' method that would connect the state storage directly. For Plack::Middleware::Auth::Form - this was enough - it does not need to know much about the thing that stores the users and their passwords it just needs a callback that would check if a given pair is OK.
Post a Comment