commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Libbrecht <>
Subject Re: [Jelly] Executable XML vs. Rich Configuration
Date Wed, 11 May 2005 09:29:46 GMT

This comes up to the point to re-consider the marketing of Jelly as we 
all wish to cut a release 1.0 soon!
I agree "executable XML" may suck but I think "rich configuration" is 
also quite "old fashioned" and is not that appropriate since there 
still is a notion of execution (or processing or pipeline).

Can you be more precise with the rants you've found about jelly ? (e.g. 
we could make a page "jelly sucks" with blog-like references and 

The best sub-title I found thus far was "mix-and-match" that's posted 
in one of the documentation pages.

We should brainstorm on this, I think.
Please bring more ideas about sub-titles or qualifiers for Jelly !


Le 11 mai 05, à 00:02, Dan Madoni a écrit :

> Having just completed a project using Jelly as a script execution 
> engine, it
> occurred to me that the perplexity I was initially met with regarding 
> Jelly
> ("executable XML? huh?") was displaced by appreciation for how 
> valuable it
> can be.
> As I began working on the project, I had a home-grown solution in mind 
> for
> the component that Jelly is now used in place of. The home-grown 
> component
> wasn't "executable XML", but it was very complex XML-based 
> configuration,
> and a cohort suggested that I look at Jelly after having perused my 
> design
> documentation.
> At first, I didn't exactly get it--why would I want to "execute" XML? 
> After
> thinking about it in the context of the project, it began to make a 
> great
> deal of sense for the specific purpose I had in mind: Jelly is ideal 
> for
> "rich configuration", where configuration data alone may be 
> insufficient or
> too cumbersome, and some sort of "intelligent" configuration is 
> needed, even
> to the point where the configuration data actually interacts 
> manipulatively
> with the application.
> I don't know if this is what Jelly's creator(s) had in mind upon 
> embarking
> on the project. Actually, I get the impression someone was caught up 
> in the
> same frenzy that compels people to try to solve every freaking problem 
> with
> XML, and just thought "It would be cool to program with XML. Yeah, 
> that's
> cool." In any case, I think I'm the rule and not the exception when I 
> say
> that the idea of "executable XML" sounds like a solution in search of a
> problem. If my fellow developer hadn't already been familiar with 
> Jelly and
> put two and two together to suggest it as something I could use, I may 
> well
> have come across the Jelly home page some other way and assumed a 
> Squidward
> attitude ("oh puh-leeze").
> Other than what I believe to be a misplaced identity, the only other 
> nits I
> have are that the documentation leaves much to be desired and debugging
> Jelly scripts is awfully cumbersome when the script error raises a Java
> exception (perhaps script execution exception handling could have been 
> a bit
> better thought out).
> But I can't really complain. Jelly is fabulous, and was absolutely key 
> in
> making this application work as well as it does. It would probably 
> find more
> users and less scorn (I read some really harsh stuff while researching 
> it)
> if it were simply repositioned a bit. The whole "executable XML" theme 
> is
> cute and might make an interesting discussion at a nerd convention, 
> but I
> would guess that there are far more developers who need to tackle 
> complex
> configuration problems and who will readily understand the meaning of 
> "rich
> configuration" or "intelligent configuration" than there are 
> developers who
> regard Utopia as being able to code in XML.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message