RIFE/Modules (was: Here's a handy little utility element)

[Geert Bevin]

Frederic, Steven and Tyler, are you guys subscribed to rife-devel, I  
think it's more appropriate to continue this discussion there.

--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com


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

[Steven Grimm]

I am now!

-Steve


Geert Bevin wrote:

> Frederic, Steven and Tyler, are you guys subscribed to rife-devel, I
> think it's more appropriate to continue this discussion there.
>
> --
> Geert Bevin
> Uwyn "Use what you need" - http://uwyn.com
> RIFE Java application framework - http://rifers.org
> Music and words - http://gbevin.com
>
>
> _______________________________________________
> Rife-users mailing list
> Rife-users@...
> http://lists.uwyn.com/mailman/listinfo/rife-users
>

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

[Geert Bevin]

So, do you guys have any idea about how to structure this? I was  
initially thinking of building this on the structure of the  
jumpstart, but I'm now not so sure that this is a good idea. I did do  
this for RIFE/Crud though, and people don't seem to have a problem  
with it since the binary distribution is simply a jar file. The  
advantage of including the jumpstart is that it's very easy to  
develop examples and allow people to try out the components. A  
disadvantage is that the included jumpstart needs to be kept up-to-
date with each release, and doing this already takes up a lot of my  
time.

What do you guys think?

On 01 Aug 2006, at 17:53, Steven Grimm wrote:

> I am now!
>
> Geert Bevin wrote:
>> Frederic, Steven and Tyler, are you guys subscribed to rife-devel,  
>> I think it's more appropriate to continue this discussion there.
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com


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

[Steven Grimm]

I don't think it's a big deal to say that the existing jumpstart is a
prerequisite. I doubt anyone will have an issue with the idea that the
modules are a plugin or addon to the base RIFE distribution. I don't
expect a Firefox extension download link to give me Firefox too, to name
one not very appropriate example.

Besides, it is quite likely that the vast majority of the people
downloading the modules will already have the jumpstart anyway, since
they will want to go through one of the tutorials to find out if they
care about RIFE in the first place. So bundling it all together would
just make a bigger download for those people.

As long as we work out some scheme where people can install multiple
modules over a jumpstart distribution without them overwriting each
other, we should be fine. The participant and site declarations are the
only sticky point there; maybe the "include" mechanism needs support for
wildcards, so we can just stick additional XML files in a couple known
directories and they'll be picked up automatically by an <include
file="rep/site/modules/*"/> directive or something like that? (I guess
that might not be so easy to do when things are packaged into a war file
and there is no actual directory to scan, but it's a thought.)

-Steve


Geert Bevin wrote:

> So, do you guys have any idea about how to structure this? I was
> initially thinking of building this on the structure of the jumpstart,
> but I'm now not so sure that this is a good idea. I did do this for
> RIFE/Crud though, and people don't seem to have a problem with it
> since the binary distribution is simply a jar file. The advantage of
> including the jumpstart is that it's very easy to develop examples and
> allow people to try out the components. A disadvantage is that the
> included jumpstart needs to be kept up-to-date with each release, and
> doing this already takes up a lot of my time.
>
> What do you guys think?

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

[Tyler Pitchford]

Just to be a devil's advocate. What advantages does relying on
Jumpstart provide?

Tyler

On 8/1/06, Steven Grimm <koreth@...> wrote:

> I don't think it's a big deal to say that the existing jumpstart is a
> prerequisite. I doubt anyone will have an issue with the idea that the
> modules are a plugin or addon to the base RIFE distribution. I don't
> expect a Firefox extension download link to give me Firefox too, to name
> one not very appropriate example.
>
> Besides, it is quite likely that the vast majority of the people
> downloading the modules will already have the jumpstart anyway, since
> they will want to go through one of the tutorials to find out if they
> care about RIFE in the first place. So bundling it all together would
> just make a bigger download for those people.
>
> As long as we work out some scheme where people can install multiple
> modules over a jumpstart distribution without them overwriting each
> other, we should be fine. The participant and site declarations are the
> only sticky point there; maybe the "include" mechanism needs support for
> wildcards, so we can just stick additional XML files in a couple known
> directories and they'll be picked up automatically by an <include
> file="rep/site/modules/*"/> directive or something like that? (I guess
> that might not be so easy to do when things are packaged into a war file
> and there is no actual directory to scan, but it's a thought.)
>
> -Steve
>
>
> Geert Bevin wrote:
> > So, do you guys have any idea about how to structure this? I was
> > initially thinking of building this on the structure of the jumpstart,
> > but I'm now not so sure that this is a good idea. I did do this for
> > RIFE/Crud though, and people don't seem to have a problem with it
> > since the binary distribution is simply a jar file. The advantage of
> > including the jumpstart is that it's very easy to develop examples and
> > allow people to try out the components. A disadvantage is that the
> > included jumpstart needs to be kept up-to-date with each release, and
> > doing this already takes up a lot of my time.
> >
> > What do you guys think?
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel
>

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

[Geert Bevin]

Hi Steve,

> I don't think it's a big deal to say that the existing jumpstart is  
> a prerequisite. I doubt anyone will have an issue with the idea  
> that the modules are a plugin or addon to the base RIFE  
> distribution. I don't expect a Firefox extension download link to  
> give me Firefox too, to name one not very appropriate example.
>
> Besides, it is quite likely that the vast majority of the people  
> downloading the modules will already have the jumpstart anyway,  
> since they will want to go through one of the tutorials to find out  
> if they care about RIFE in the first place. So bundling it all  
> together would just make a bigger download for those people.

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.

> As long as we work out some scheme where people can install  
> multiple modules over a jumpstart distribution without them  
> overwriting each other, we should be fine. The participant and site  
> declarations are the only sticky point there; maybe the "include"  
> mechanism needs support for wildcards, so we can just stick  
> additional XML files in a couple known directories and they'll be  
> picked up automatically by an <include file="rep/site/modules/*"/>  
> directive or something like that? (I guess that might not be so  
> easy to do when things are packaged into a war file and there is no  
> actual directory to scan, but it's a thought.)

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

Best regards,

Geert

> -Steve
>
>
> Geert Bevin wrote:
>> So, do you guys have any idea about how to structure this? I was  
>> initially thinking of building this on the structure of the  
>> jumpstart, but I'm now not so sure that this is a good idea. I did  
>> do this for RIFE/Crud though, and people don't seem to have a  
>> problem with it since the binary distribution is simply a jar  
>> file. The advantage of including the jumpstart is that it's very  
>> easy to develop examples and allow people to try out the  
>> components. A disadvantage is that the included jumpstart needs to  
>> be kept up-to-date with each release, and doing this already takes  
>> up a lot of my time.
>>
>> What do you guys think?
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel
>

--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com


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

[Steven Grimm]

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

[Geert Bevin]

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

Yeah, it is. Of course its jars are not include into RIFE/Crud  
itself. The structure is though, with the project files, Jetty, ...

> 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.

The main question here is what to achieve with that. I see RIFE/
Modules as a collection of reusable elements and sites. To use them,  
people will have to include them into their sites and customize them  
through properties. They might even want to put authentication on top  
of them, link them into existing flows, use them as embedded  
elements, ...

What you're describing sounds more like a CMS, which would be cool  
too btw. Being able to drop in jars and automatically 'register' them  
with the CMS system is indeed very powerful. An administration  
interface could then allow people to manage a site-structure  
intuitively and plug the 'modules' into the rest of the site and  
customize them.

> 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.

This is possible in several ways:

* use a dedicated classloader for each module jar and put all those  
jars in a specific location so that their names can be detected

* rely on the jar manifest to provide this information instead of an  
XML file, this does require quite some additional code in  
EngineClassLoader since RIFE doesn't use the manifest information at  
all atm because the JDKs URLClassLoader doesn't provide an API to be  
able to access its cached resources and meta data. Due to this we'd  
have to develop a parallel resource hierarchy caching mechanism  
ourselves, which is a lot of work, duplicated the memory footprint  
for that, and will slow down resource retrieval. Without such a  
caching system however, finding resources really crawls though.

> 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 don't like this much since it kind of prevents people from  
developing custom modules for themselves without fearing that one day  
they'll have a conflicting number. A huge hack indeed! ;-)

> 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
>

--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com


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