Re: RIFE/Modules

Geert Bevin wrote:
> I think we misunderstood each-other. The jumpstart would just be the
> canvas we use to develop and try out the modules, as well as for
> creating examples of their usage. The binary distribution would just
> be a jar file with the compiled classes of the sources and any other
> required assets (XML files, templates, ...).
>
> As an example, just look at what I did with RIFE/Crud.

(Isn't rife-crud-*.jar included in the Jumpstart distribution?)

You're right, I misunderstood. I took "the advantage of including the
jumpstart..." to mean that you were thinking of packaging each module
with a complete copy of the jumpstart.

> This is not possible since RIFE looks up everything through the
> claspath. File globbing is thus not an option.

I think a good goal, though maybe others disagree, is to let someone
just plop a module jarfile in their lib directory, restart Jetty, and go
to a demo page to start playing with the module. No config file editing
needed. That goal requires some kind of automatic detection of modules,
and of course you might have any number of modules in any combination at
any given time.

Is it possible to distinguish between multiple instances of the same
resource on the classpath? If so, then a simple solution might be for
each module to include a "rife/modules/module.xml" or somesuch, that
declares the elements (and/or participants?) defined by that particular
module as well as a set of demo pages. The module element/participant
implementations, demo element implementations, and demo templates would
of course have unique names. The module autoloading would be done by a
new participant which takes a parameter to control whether demo
environments get set up; for a production environment you'd turn that
option off.  The autoloader could even have a little informational UI of
its own with a description of each module and a link to the
corresponding demo page. You could also, of course, explicitly declare
the module elements/participants in your configuration and not use
autoloading at all.

If it's not possible to distinguish identically-named resources on the
classpath, and the zero-configuration-required goal is a good one, maybe
this calls for a hack. Since we will be packaging the modules in a
coordinated way, we can give each one a number. Start with 1 and work
our way up. The jumpstart distribution can know how many official
modules were available at the time it was built. The module-loading
participant can scan for rife/modules/1.xml, rife/modules/2.xml, etc.,
up to some reasonable number higher than the highest known official
module at release time. The scan only needs to happen once at startup
time, so it should not be a performance problem.

I said it was a hack! :)

It might be reasonable to just tell people to edit their config files,
of course, but IMO the less effort between downloading a module and
trying it out locally, the better. Plus it would make RIFE the only
framework with true drop-in-and-use extension support, which would be
pretty cool in itself!

-Steve
_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel