Reading about the Tales framework, I got to thinking about Rails, and what Tales could profitably steal (er, borrow :-).
And the first thing I thought of (after testing) was user authentication. This lead to thinking about the fact that there have been several different user authentication gems/plugins for Rails. That lead to thinking about the overall gems/plugin architecture which Rails has (or doesn't have), and how you'd design a plugin architecture if you were starting from scratch on a project.
So this isn't supposed to be Tales specific, or I'd bring it up there.
The question is how do you design a plugin architecture for a project... Rails appears to have had no real guides for designing something like this, so while there's been tons of energy and drive, there has been an awful lot of duplication, confusion and contention.
I imagine that, in some ways, it's something akin to designing the library for a language, or the API for a framework, with the intent to provide extensibility. It seems like there's a tension between providing too much structure and functionality, so it's hard to imagine going beyond the framework, or too little so that everything is implemented differently and incompatibly.
So... how do you do it? Any fantastic models to follow out there?
brianFri 5 Nov 2010
Here are my thoughts:
Firstly a plugin is a contract for pluggable functionality between two modules of code. So that is a great fit for a type (some class, mixin or collection of).
Second is how plugins are discovered and glued together. For discovery, the Fantom way is to use indexed props. For example to add an "extension" in our SkySpark product you just create a subclass of Ext and register it with the "axon.ext" indexed prop. Then to add extensions you just drop a pod into the runtime and voila! We even expose indexed props in the JavaScript environment which is super cool.
Selecting specific plugins, such as "which authentication system should I use" seems to have all sorts of complicated solutions in Java-land. Personally I prefer the way languages like Python and Ruby tend to handle it with just using configuration scripts. They can be declarative, but drop into code when you need - like build files. Seems this is the approach Tales takes too (just browsing thru the code).
kaushikFri 5 Nov 2010
Tales does not support plugins yet. I've some Ideas, but I guess the best way is to discuss and think through all cool things a plugin developer need to be able to do and design the architecture around it. I am not (much) from Rails background, but love to borrow from it(stealing is fine too :). Having index props built-in is a great advantage.
One thing I would want to be able to do is have plugins developed with the same ease as pages itself. No server restarts and stuff. Let's see how it goes :).
yachris Thu 4 Nov 2010
Reading about the Tales framework, I got to thinking about Rails, and what Tales could profitably steal (er, borrow :-).
And the first thing I thought of (after testing) was user authentication. This lead to thinking about the fact that there have been several different user authentication gems/plugins for Rails. That lead to thinking about the overall gems/plugin architecture which Rails has (or doesn't have), and how you'd design a plugin architecture if you were starting from scratch on a project.
So this isn't supposed to be Tales specific, or I'd bring it up there.
The question is how do you design a plugin architecture for a project... Rails appears to have had no real guides for designing something like this, so while there's been tons of energy and drive, there has been an awful lot of duplication, confusion and contention.
I imagine that, in some ways, it's something akin to designing the library for a language, or the API for a framework, with the intent to provide extensibility. It seems like there's a tension between providing too much structure and functionality, so it's hard to imagine going beyond the framework, or too little so that everything is implemented differently and incompatibly.
So... how do you do it? Any fantastic models to follow out there?
brian Fri 5 Nov 2010
Here are my thoughts:
Firstly a plugin is a contract for pluggable functionality between two modules of code. So that is a great fit for a type (some class, mixin or collection of).
Second is how plugins are discovered and glued together. For discovery, the Fantom way is to use indexed props. For example to add an "extension" in our SkySpark product you just create a subclass of
Extand register it with the "axon.ext" indexed prop. Then to add extensions you just drop a pod into the runtime and voila! We even expose indexed props in the JavaScript environment which is super cool.Selecting specific plugins, such as "which authentication system should I use" seems to have all sorts of complicated solutions in Java-land. Personally I prefer the way languages like Python and Ruby tend to handle it with just using configuration scripts. They can be declarative, but drop into code when you need - like build files. Seems this is the approach Tales takes too (just browsing thru the code).
kaushik Fri 5 Nov 2010
Tales does not support plugins yet. I've some Ideas, but I guess the best way is to discuss and think through all cool things a plugin developer need to be able to do and design the architecture around it. I am not (much) from Rails background, but love to borrow from it(stealing is fine too :). Having index props built-in is a great advantage.
One thing I would want to be able to do is have plugins developed with the same ease as pages itself. No server restarts and stuff. Let's see how it goes :).