Performance

Dependence / Independence

Rating / Review

Testing

John Sechrest wrote:

1) Having a module system is an interesting idea.
2) When looking at the core of the system, you have to pay attention to performance. Many module systems are broken and broken badly for performance.
(Try to load up all of the drupal modules and test them)
3) Modules need to be independent of each other. Adding and removing a module should not break an unrelated module.
4) Having an apps-store/directory, that makes it trivial to install andmanage modules is important.
5) having a way to vet good modules that are "blessed" in some way is worth the energy.
6) You should always be able to run regression tests as things change and validate that modules still work.

Ethan McCutchen summarized:

True modularity  (see #3 and #4)  implies that code and functionality are strongly independent.  I just want to throw out the other option of tracked dependency, where modules can depend on other modules but must somehow indicate that dependency.  Either way, insuring conformity to either principle will require...

Rating / Review  (see #2, #5, and #6)  how and when to bless or forbid modules -- or at least to track things like performance, robustness, and (in)dependence transparently -- seems like a great discussion for this group.  What resources do we have for this?  How can we build more?  How can we make it easy to find the best and most trustworthy modules?  And how much of that can we automate....

Testing  (see #2 and #6) has become very central to Wagn's development process, and it probably ought to be central to our module plans.  Do we only accept modules with tests built in?  How and when do we run the tests?  If we have 2000 modules do we still test them all before each code update?  each release?  each major release?

Eric Harris-Braun said:

Make sure to consider the workflow of a developer developing a module.  So for example, if I have a github fork of wagn, and a fork of somebody's module, I want as little hassle as possible putting these forks together for my particular app, and still be able to contribute back any changes easily to the source project.

James Thompson said:

I'd suggest:

   Don't use modules for small features, make them part of the base and make them options in the configuration.

   Design the module API so that

       it can be extended without breaking old modules

       it is independent of internal WAGN data structures

       it includes a an interface for automated testing and benchmarking

    Include popular modules everyone uses in the base distribution

    Make module installation easy

 

It there are more than a handful of modules, its not feasible to test all combinations of modules.

I'd suggest that the WAGN installation process include

a test step that tests the local install including what ever modules are installed.  This

will validate that the installed WAGN and that any selected modules are working as intended.

The Perl module install system includes a similar install test step.

 

It would be nice to include an easy benchmark test as part of the WAGN

distribution.  Perhaps it should even be a required part of install tests.  This would make it

easier to gague the impact of changes and encourage authors to

thing about performance more.  As John noted, many CMS systems have

serious performance problems as the usage ramps up.

Having Performance numbers on the WAGN feature list would be good too.

For example, it would be nice to say something like this in the feature list:

 

Running WAGN on  ... hardware/software configuration, using the

standard WAGN benchmark test, WAGN supports 40 card retreivals/second.

 

This would also make it very easy to gague the performance inpact

of a new release.

I'm starting to think about a list of threshold points that could help
out with all of this:
1) Dependency checking and mapping.  I may finally remember next time
that "has_attachment" being undefined means that I forgot the "git
submodules update --init" and I won't have to go back to wagn.org to
remind me of the exact command.  Similarly, if some gems are missing,
you can't even get "rake gems:install" to fire up, and it gives a really
cryptic message.   Ideally, even these functions could be modules added
and tweaked by contributors, and in fact I would expect this would be a
hot area for outside pull requests since this is where you will have
many eyeballs of many admins with distinct configurations and potential
issues.
2) MVC separation.  From being in the code to add controller and view
features for XML, I can say that this separation isn't very good right
now.  The slot based card controller is highly connected both to the all
the rendering modes it needs as well as the card content encoding.  If
you clearly define the contents (API wise) of these interfaces with both
tests and docs, it can go a long way to helping contributors create high
quality plugins that don't interact in strange ways.
3) Mapping of what is in the core and what is replaceable/modifyable.
My suspicion is that the plans for patterns will go a long way on this.
Instead of having permissions, user extensions and templates all
overloaded onto the card models, they will be more like internal
plugins, and "outside the core" in a sense.

Talking to Michael about this on the phone yesterday has prompted me a
little bit more into action and inquiry on this.  He reminded me about
rack, and the necessity to use the best standards and strategies from
your language community.  That is why we are all here with ruby and
rails in the first place.  The MVC pattern already tells us a lot about
how we should break up the modules, and therefore there is a lot that is
already right with the structure of Wagn.

What we want to do is strip down Wagn to its core and move functions out
of the core into the appropriate place in the stack.  We also see rack
emerging as a standard way to modularize certain functions and
features.  For example by moving authentication and groups into rack
middleware, they can be shared by multiple applications and make things
like single sign on easy, and even go further so that Wagn cards can be
mixed up with FlowPlace and MetaCurrency features, all sharing the same
application spaces, being able to use each others models, views and
controllers.

Looking at warden for the auth layer: http://wiki.github.com/hassox/warden