"Pluglets" (please find a better name!)

[instance]

Joomla is hosting some pretty sophisticated extensions these days.

A lot of these extensions will themselves be modular in nature and support some sort of secondary plugin mechanism. Candidates include blogging tools, forums, e-commerce applications, CRM, ERP...

Therefore, it would be useful if the Joomla framework provided an API for these “pluglets”, along with support for installing and updating them. The API specification should both supply framework services to pluglets, and specify interfaces that they must provide, making for a nice happy ecosystem.

If we don't do this, then every extension will wind up implementing a different mechanism, and it will become an administrator's nightmare.

[Jinx]

Interesting idea ! Joomla! 1.5 already provides some of the groundwork with the JInstaller libraries that could be extended. You have any thoughts/ideas on how an API for 'plugets' would look like ? What services would the framework need to supply for example ?

[instance]

Not much specific, but I can say how I got the idea. I run Serendipity (http://www.s9y.org) for my blog, and of course now I want to move it over to Joomla (without hacking some bridge).

S9y has a large number of useful plug-ins, some are event-driven such as spam filters and sitemap generators, blogroll pingers, and a bunch of things that can be attached to the left or right sidebars. Some of these are stand alone extensions (e.g. an Amazon wish list), but some are closely tied to the blog (recent posts, archives).

I have something similar with a photo gallery (gallery view history, rate this picture, etc.) Some of these features are best implemented as simple options in the extension, but it seems to me that a standard pluglet interface just makes it easier for (ahem) "fourth party developers" to extend an extension -- something small and cool that doesn't take a comprehensive knowledge of the framework to implement.

So I think the areas where we would look is event generation and filtering, some way to hook into views (I have no idea how at this point), and maybe even some sensitivity to context (e.g. activate this pluglet only if the article author is X, or if the category is Y). That's ACL dependent, of course.

[As an aside, s9y also has a nice mechanism for discovering new and updated plugins right inside it's administration. Request a new plugin and it downloads and installs transparently.]

[mtlnews]

Hey

This is a good idea, i was thinking about that the other day. Maybe these "pluglets" could simply be installed the same way plugins and modules are installed in J1.5, but have some kind of indication in the install file that they are dependent on a particular component (or componentss?). Then they could be loaded at the same time the component is loaded, and they could use the objects and methods within the component, maybe, somehow.

I think a second place to install things would make things more complicated unnecessarily.

[instance]

I think a second place to install things would make things more complicated unnecessarily.

Exactly! If we don't provide something (even if all it is is a howto document), we'll have second, third, fourth... places where things are installed, as different extensions implement different mechanisms.

[Jinx]

Good points made, this concept fits in the orginial ideas behind the SOC 2006 JPackage project. The goal behind JPackage is that extensions could be installed as packages and dependencies could be set between them. This is something we have been poundering for a while now and want to implement into a future 1.x version. The JPackage code is still out there in the SOC 2006 project in case you guys wanna have a look.