supersym
commented
11 years ago I have been thinking about the plugin architecture for a while now. There are several angles of approach one could take, but for now, let's stick with what you have proclaimed here as a feature/milestone/goal: being able to use docpad without the core of docpad.
There are a few ways I could envision such a thing, in the end it boils down to, what I believe, a uniform and standardized approach on which other people e.g. third parties would be able to depend upon. Not changing frequently, steady - pre-announced changes / expansion at a incremental rate - much like... publishing an API I'd say. v1 -> 2 -> 3 (very mature) without too much in between. You'd have to make it near perfect/the way we like on basically the first version release straight away. Else, and you'll have enough problems with that as it is, it'll be just too hard for people to keep up with stuff, change their code to hook it up again (fix it) and they'll get annoyed and just ditch it before you can say "n00b".
This does bring me to the facet of what third parties would be. If I take your statement very literal, I'd assume you mean you'd like to see people say hook-up their Wordpress site from their side on with certain docpad (modular) plugin features. This would involve their manual effort primarily and is just as complex as you make your interface. For us to expect the "core team" behind Wordpress, or any other for that matter, to facility a hook to DocPad, you'd need to have made a big name for yourself. Them hooking into Flikr, or Google stuff sure, but I don't think we are at that scale yet and you'd eventually in the long run something like this.
So I think for it to succeed, you'd need to 'lure' the users of those (web) frameworks into hooking into docpad, and you need to make it as easy as 1,2,3 I'm afraid, else you'll loose on the less tech-savy users of those solutions (there is a reason Joomla, MediaWiki, WordPress, whatnot keep making their installation process easier and easier as people grow dumber and dumber I fear).
One way you'd be able to more or less facilitate a hookup, though you'll need a solid backend - might even have a business model upon it make a buck or two - is to provide a web SaaS like architecture where you'd have core components run server-side on easy web-form based selection of plugins, features and what not. You could even discriminate as in free as free beer, or some reasonable fee for the more exclusive parts. I don't really see why people wouldn't instead just get docpad with the core and render stuff client-side themselves, but eventually it just might be a bit too hard for some to use the console and you'd be able to use a more 'friendly' web based UI as a paid service to access it and a central rendering server which spits out desired stuff. I don't see anything wrong with that, though like I said, I think docpad already is quite user-friendly - but maybe not for everyone? Anyway this might be a bit off-topic though but just one of potentially a dozen models you'd be able to pick from and differentiate your time upon, assuming you (balupton) eventually would like to make at least a living out of docpad. If the plan is to generate income some other way, nothing said - but I know balupton spends a large amount of time upon docpad so one could envision a separation between community and official support /service/feature expanded one (enterprise version or membership whatever u want to call it)
Now back to the plugin topic: the point I haven't addressed yet is that of the role of the core system in all of this. A.t.m. the plugins are somewhat tightly bound to the core of docpad as in most require some part of the rendering process to take place, system events to fire and so on. How are you going to emit events from a non-existent system if plugins rely on it? And even if, how are you going to do this without breaking any and all plugins already in use? This requires some serious thinking ahead! (much like you'd need to do when deciding to use a formal API I guess).
These are just my first thoughts. I'll soon try and post some more, I've been forking/depending on a few nice solutions in different areas which should spawn some more brain-farts... I guess I should also write a bit on how I've viewed plugins, the construction of them, pragmatism, feature expansion and what not. In the end, that might lead to a discussion on the desired 'leanness' of the core system, what to integrate (i.e. become part of the core functionality ~ kernel) and when to wrap something up in a plugin (regardless the method to connect/interface the external and internal we decide to use to hook those two up). These in my book would be the kind of decisions the... what do they call it,... supreme ruler or dictator .. Google moment BDFL would make.
(to be continued...)
balupton
Delapouite
Would be cool to abstract out our plugin loading, so other systems can use our plugin architecture, and perhaps even our plugins, without having to use all of docpad.