Re: [Jelly] Executable XML vs. Rich Configuration
Two more proposals then: - Jelly: scripts in XML (scripts are a form of configuration... I like the naming) - Jelly: mouldable XML In the latter I think I should be able to get a few pictures out of moudling jell-o with my kids... this may be modern transluscent... I suggest we do not consider to change the jelly name, just the sub-title and maybe the overall graphical/marketing/word-choice appearance. paul Le 23 mai 05, à 03:36, Paul DeCoursey a écrit : I like the Jelly name as well. I use it for all kinds of things, mostly scripting. I can't say I have ever used it for configuration. As far as any sort of name change, I don't think it a good idea. It may need better marketing, but does that even fit into the open source world? Paul On May 21, 2005, at 12:52 AM, Hans Gilde wrote: My 2 cents: I got into Jelly as a framework for building Swing GUIs. In this case, the Tag model works very well and the ability to implement the scripting is also extremely useful. Unfortunately, the company I did it for laid me off and I have to start the whole framework from scratch if I want to publish it open source. However, I find Jelly to be rather more than configuration... the name Jelly really seems to fit for me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Jelly] Executable XML vs. Rich Configuration
Well, you've inspired me to write something. :) I hope to spend some time cobbling something together for Wiki by this weekend. It may not be much if anything, but considering how much I've benefited from Jelly, I feel like I ought to do something. -Original Message- From: Hans Gilde [mailto:[EMAIL PROTECTED] Sent: Monday, May 23, 2005 7:59 PM To: 'Jakarta Commons Users List' Subject: RE: [Jelly] Executable XML vs. Rich Configuration Absolutely. That's actually where I started with Jelly. I meant to copy all of it to the Wiki, but never had the time. That's what I meant by we all pretty much know what needs to be done. I think that if we could all somehow get our collective experiences with Jelly up on the site, people would respond positively. Dan was talking about marketing and I think that the best marketing is making it easy for other programmers to grab ideas about how to use it. I know that there are tones of people that use Jelly for all kinds of things and if we could each write one article on the Wiki, we would be in business. Myself included. -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Monday, May 23, 2005 9:32 PM To: Jakarta Commons Users List Subject: Re: [Jelly] Executable XML vs. Rich Configuration There are quite a few articles on my blog On 5/24/05, Hans Gilde [EMAIL PROTECTED] wrote: I happen to agree with you, except that I think my take is different than yours. Jelly could definitely use an upgrade to the documentation. Actually, the current docs are all good, but we could use more tutorials, how-to's and real world examples. In fact, I think that Jelly suffers the most from the lack of time on the part of the committers. We all pretty much know what needs to be done but all we ever have time to do is fix bugs. I'll bet that if there were more in the way of demonstration of how Jelly can be used, people would find uses for it left and right. Essentially, it makes a pretty good tool for writing just about any XML functionality that you can think of. We have a Wiki, so anyone can contribute. Maybe you could do an article about your project? With some examples? Seriously, that kind of thing is the best marketing an OSS project can get. In terms of corporate positioning of Jelly, I happen to think that all the harsh stuff you've read about it is a side effect of a positioning effort. You see, Jelly was originally tied to Maven, which was dramatically over hyped when it was first rolled out. Had there been less hype, both Maven and Jelly would have had the time they needed to become mature and stable before being touted as the next big thing. -Original Message- From: Dan Madoni [mailto:[EMAIL PROTECTED] Sent: Monday, May 23, 2005 2:02 PM To: 'Jakarta Commons Users List' Subject: RE: [Jelly] Executable XML vs. Rich Configuration Marketing to the tune of It slices! It dices! It mows your lawn! certainly doesn't belong in OSS, which is one reason why folks gravitate toward it, (i.e. to get away from all the marketing BS). However, Marketing as in OSS is a serious alternative and here's why, or this is an XML scripting engine, we believe you will benefit from it, and here's why is extremely important for OSS and for projects like Jelly. As long as open-source remains focused on being an ideological statement against the likes of Microsoft rather than maturing into a real alternative that can speak corporate-ese, it won't fully realize its goal of establishing OSS communities like Apache as the best source for useful and reliable software. -Original Message- From: Paul DeCoursey [mailto:[EMAIL PROTECTED] Sent: Sunday, May 22, 2005 6:37 PM To: Jakarta Commons Users List Subject: Re: [Jelly] Executable XML vs. Rich Configuration I like the Jelly name as well. I use it for all kinds of things, mostly scripting. I can't say I have ever used it for configuration. As far as any sort of name change, I don't think it a good idea. It may need better marketing, but does that even fit into the open source world? Paul On May 21, 2005, at 12:52 AM, Hans Gilde wrote: My 2 cents: I got into Jelly as a framework for building Swing GUIs. In this case, the Tag model works very well and the ability to implement the scripting is also extremely useful. Unfortunately, the company I did it for laid me off and I have to start the whole framework from scratch if I want to publish it open source. However, I find Jelly to be rather more than configuration... the name Jelly really seems to fit for me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http
RE: [Jelly] Executable XML vs. Rich Configuration
Marketing to the tune of It slices! It dices! It mows your lawn! certainly doesn't belong in OSS, which is one reason why folks gravitate toward it, (i.e. to get away from all the marketing BS). However, Marketing as in OSS is a serious alternative and here's why, or this is an XML scripting engine, we believe you will benefit from it, and here's why is extremely important for OSS and for projects like Jelly. As long as open-source remains focused on being an ideological statement against the likes of Microsoft rather than maturing into a real alternative that can speak corporate-ese, it won't fully realize its goal of establishing OSS communities like Apache as the best source for useful and reliable software. -Original Message- From: Paul DeCoursey [mailto:[EMAIL PROTECTED] Sent: Sunday, May 22, 2005 6:37 PM To: Jakarta Commons Users List Subject: Re: [Jelly] Executable XML vs. Rich Configuration I like the Jelly name as well. I use it for all kinds of things, mostly scripting. I can't say I have ever used it for configuration. As far as any sort of name change, I don't think it a good idea. It may need better marketing, but does that even fit into the open source world? Paul On May 21, 2005, at 12:52 AM, Hans Gilde wrote: My 2 cents: I got into Jelly as a framework for building Swing GUIs. In this case, the Tag model works very well and the ability to implement the scripting is also extremely useful. Unfortunately, the company I did it for laid me off and I have to start the whole framework from scratch if I want to publish it open source. However, I find Jelly to be rather more than configuration... the name Jelly really seems to fit for me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Jelly] Executable XML vs. Rich Configuration
I happen to agree with you, except that I think my take is different than yours. Jelly could definitely use an upgrade to the documentation. Actually, the current docs are all good, but we could use more tutorials, how-to's and real world examples. In fact, I think that Jelly suffers the most from the lack of time on the part of the committers. We all pretty much know what needs to be done but all we ever have time to do is fix bugs. I'll bet that if there were more in the way of demonstration of how Jelly can be used, people would find uses for it left and right. Essentially, it makes a pretty good tool for writing just about any XML functionality that you can think of. We have a Wiki, so anyone can contribute. Maybe you could do an article about your project? With some examples? Seriously, that kind of thing is the best marketing an OSS project can get. In terms of corporate positioning of Jelly, I happen to think that all the harsh stuff you've read about it is a side effect of a positioning effort. You see, Jelly was originally tied to Maven, which was dramatically over hyped when it was first rolled out. Had there been less hype, both Maven and Jelly would have had the time they needed to become mature and stable before being touted as the next big thing. -Original Message- From: Dan Madoni [mailto:[EMAIL PROTECTED] Sent: Monday, May 23, 2005 2:02 PM To: 'Jakarta Commons Users List' Subject: RE: [Jelly] Executable XML vs. Rich Configuration Marketing to the tune of It slices! It dices! It mows your lawn! certainly doesn't belong in OSS, which is one reason why folks gravitate toward it, (i.e. to get away from all the marketing BS). However, Marketing as in OSS is a serious alternative and here's why, or this is an XML scripting engine, we believe you will benefit from it, and here's why is extremely important for OSS and for projects like Jelly. As long as open-source remains focused on being an ideological statement against the likes of Microsoft rather than maturing into a real alternative that can speak corporate-ese, it won't fully realize its goal of establishing OSS communities like Apache as the best source for useful and reliable software. -Original Message- From: Paul DeCoursey [mailto:[EMAIL PROTECTED] Sent: Sunday, May 22, 2005 6:37 PM To: Jakarta Commons Users List Subject: Re: [Jelly] Executable XML vs. Rich Configuration I like the Jelly name as well. I use it for all kinds of things, mostly scripting. I can't say I have ever used it for configuration. As far as any sort of name change, I don't think it a good idea. It may need better marketing, but does that even fit into the open source world? Paul On May 21, 2005, at 12:52 AM, Hans Gilde wrote: My 2 cents: I got into Jelly as a framework for building Swing GUIs. In this case, the Tag model works very well and the ability to implement the scripting is also extremely useful. Unfortunately, the company I did it for laid me off and I have to start the whole framework from scratch if I want to publish it open source. However, I find Jelly to be rather more than configuration... the name Jelly really seems to fit for me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Executable XML vs. Rich Configuration
There are quite a few articles on my blog On 5/24/05, Hans Gilde [EMAIL PROTECTED] wrote: I happen to agree with you, except that I think my take is different than yours. Jelly could definitely use an upgrade to the documentation. Actually, the current docs are all good, but we could use more tutorials, how-to's and real world examples. In fact, I think that Jelly suffers the most from the lack of time on the part of the committers. We all pretty much know what needs to be done but all we ever have time to do is fix bugs. I'll bet that if there were more in the way of demonstration of how Jelly can be used, people would find uses for it left and right. Essentially, it makes a pretty good tool for writing just about any XML functionality that you can think of. We have a Wiki, so anyone can contribute. Maybe you could do an article about your project? With some examples? Seriously, that kind of thing is the best marketing an OSS project can get. In terms of corporate positioning of Jelly, I happen to think that all the harsh stuff you've read about it is a side effect of a positioning effort. You see, Jelly was originally tied to Maven, which was dramatically over hyped when it was first rolled out. Had there been less hype, both Maven and Jelly would have had the time they needed to become mature and stable before being touted as the next big thing. -Original Message- From: Dan Madoni [mailto:[EMAIL PROTECTED] Sent: Monday, May 23, 2005 2:02 PM To: 'Jakarta Commons Users List' Subject: RE: [Jelly] Executable XML vs. Rich Configuration Marketing to the tune of It slices! It dices! It mows your lawn! certainly doesn't belong in OSS, which is one reason why folks gravitate toward it, (i.e. to get away from all the marketing BS). However, Marketing as in OSS is a serious alternative and here's why, or this is an XML scripting engine, we believe you will benefit from it, and here's why is extremely important for OSS and for projects like Jelly. As long as open-source remains focused on being an ideological statement against the likes of Microsoft rather than maturing into a real alternative that can speak corporate-ese, it won't fully realize its goal of establishing OSS communities like Apache as the best source for useful and reliable software. -Original Message- From: Paul DeCoursey [mailto:[EMAIL PROTECTED] Sent: Sunday, May 22, 2005 6:37 PM To: Jakarta Commons Users List Subject: Re: [Jelly] Executable XML vs. Rich Configuration I like the Jelly name as well. I use it for all kinds of things, mostly scripting. I can't say I have ever used it for configuration. As far as any sort of name change, I don't think it a good idea. It may need better marketing, but does that even fit into the open source world? Paul On May 21, 2005, at 12:52 AM, Hans Gilde wrote: My 2 cents: I got into Jelly as a framework for building Swing GUIs. In this case, the Tag model works very well and the ability to implement the scripting is also extremely useful. Unfortunately, the company I did it for laid me off and I have to start the whole framework from scratch if I want to publish it open source. However, I find Jelly to be rather more than configuration... the name Jelly really seems to fit for me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Jelly] Executable XML vs. Rich Configuration
Absolutely. That's actually where I started with Jelly. I meant to copy all of it to the Wiki, but never had the time. That's what I meant by we all pretty much know what needs to be done. I think that if we could all somehow get our collective experiences with Jelly up on the site, people would respond positively. Dan was talking about marketing and I think that the best marketing is making it easy for other programmers to grab ideas about how to use it. I know that there are tones of people that use Jelly for all kinds of things and if we could each write one article on the Wiki, we would be in business. Myself included. -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Monday, May 23, 2005 9:32 PM To: Jakarta Commons Users List Subject: Re: [Jelly] Executable XML vs. Rich Configuration There are quite a few articles on my blog On 5/24/05, Hans Gilde [EMAIL PROTECTED] wrote: I happen to agree with you, except that I think my take is different than yours. Jelly could definitely use an upgrade to the documentation. Actually, the current docs are all good, but we could use more tutorials, how-to's and real world examples. In fact, I think that Jelly suffers the most from the lack of time on the part of the committers. We all pretty much know what needs to be done but all we ever have time to do is fix bugs. I'll bet that if there were more in the way of demonstration of how Jelly can be used, people would find uses for it left and right. Essentially, it makes a pretty good tool for writing just about any XML functionality that you can think of. We have a Wiki, so anyone can contribute. Maybe you could do an article about your project? With some examples? Seriously, that kind of thing is the best marketing an OSS project can get. In terms of corporate positioning of Jelly, I happen to think that all the harsh stuff you've read about it is a side effect of a positioning effort. You see, Jelly was originally tied to Maven, which was dramatically over hyped when it was first rolled out. Had there been less hype, both Maven and Jelly would have had the time they needed to become mature and stable before being touted as the next big thing. -Original Message- From: Dan Madoni [mailto:[EMAIL PROTECTED] Sent: Monday, May 23, 2005 2:02 PM To: 'Jakarta Commons Users List' Subject: RE: [Jelly] Executable XML vs. Rich Configuration Marketing to the tune of It slices! It dices! It mows your lawn! certainly doesn't belong in OSS, which is one reason why folks gravitate toward it, (i.e. to get away from all the marketing BS). However, Marketing as in OSS is a serious alternative and here's why, or this is an XML scripting engine, we believe you will benefit from it, and here's why is extremely important for OSS and for projects like Jelly. As long as open-source remains focused on being an ideological statement against the likes of Microsoft rather than maturing into a real alternative that can speak corporate-ese, it won't fully realize its goal of establishing OSS communities like Apache as the best source for useful and reliable software. -Original Message- From: Paul DeCoursey [mailto:[EMAIL PROTECTED] Sent: Sunday, May 22, 2005 6:37 PM To: Jakarta Commons Users List Subject: Re: [Jelly] Executable XML vs. Rich Configuration I like the Jelly name as well. I use it for all kinds of things, mostly scripting. I can't say I have ever used it for configuration. As far as any sort of name change, I don't think it a good idea. It may need better marketing, but does that even fit into the open source world? Paul On May 21, 2005, at 12:52 AM, Hans Gilde wrote: My 2 cents: I got into Jelly as a framework for building Swing GUIs. In this case, the Tag model works very well and the ability to implement the scripting is also extremely useful. Unfortunately, the company I did it for laid me off and I have to start the whole framework from scratch if I want to publish it open source. However, I find Jelly to be rather more than configuration... the name Jelly really seems to fit for me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Jelly] Executable XML vs. Rich Configuration
My 2 cents: I got into Jelly as a framework for building Swing GUIs. In this case, the Tag model works very well and the ability to implement the scripting is also extremely useful. Unfortunately, the company I did it for laid me off and I have to start the whole framework from scratch if I want to publish it open source. However, I find Jelly to be rather more than configuration... the name Jelly really seems to fit for me. -Original Message- From: Dan Madoni [mailto:[EMAIL PROTECTED] Sent: Monday, May 16, 2005 1:12 PM To: 'Jakarta Commons Users List' Subject: RE: [Jelly] Executable XML vs. Rich Configuration Hello Paul. I can't speak for Hale, but I would like to respond to your comments since these are important issues to me. Regarding your comment on the idea that a change to Executable XML amounts to a subtitle change, I would argue that it isn't merely about a subtitle, but about positioning. This, of course, is a critical difference. Even though Jelly is OSS and all that, there is still a job of selling to do, both in order for Jelly to reach its potential, and so that the most developers possible can benefit from it, and perhaps contribute to its continued improvement. I know I've already said my piece about the name Jelly, but if you'll indulge me again: the name is meaningless, even more so than most Apache project names, (and that's saying something). At least Tomcat might conjure images of something agile and street-savvy; Betwixt implies something that sits between something else (which hints at what it is); of course, names like FileUpload and Logging are precise and immediately communicate the purpose of the project... ...but Jelly? It might as well be called Blah or Hmmm, (don't get any ideas). :) -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Saturday, May 14, 2005 12:34 PM To: Jakarta Commons Users List Subject: Re: [Jelly] Executable XML vs. Rich Configuration This seems to be another voice in favour of even changing Jakarta Commons Jelly... I am really surprised and would make sure I understand it correctly. Changing Executable XML into Rich Configuration or Running XML is about changing a subtitle... can I just request clarification ? thanks paul Le 13 mai 05, à 18:44, Hale India a écrit : In any case I would like to avoid exotic name which could give a bad image - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Executable XML vs. Rich Configuration
Also, should keep in mind that if you use too much Jelly (or Jello, as other may preffer), it can get quite messy ;) And, although it's very flexible and appealing, only kids like to play with it. Dan Madoni wrote: Also Jelly (in British or Jello in American) can be molded to fit any shape required which kinda fits with Jelly's main aim to be a flexible Java and XML based scripting engine that can do anything. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Jelly] Executable XML vs. Rich Configuration
I just read through the FAQ's and found that Jelly does indeed have an intended meaning. From http://jakarta.apache.org/commons/jelly/faq.html#why-called-jelly: quote The name started out as 'Jele' as in Java ELEments but then I thought Jelly was a nicer spelling :-). The basic idea behind Jelly that Java code is bound on to XML elements. Also Jelly (in British or Jello in American) can be molded to fit any shape required which kinda fits with Jelly's main aim to be a flexible Java and XML based scripting engine that can do anything. There are many different specific frameworks that take an XML document, bind it to some kind of bean or object and then evaluate it in some kind of script or process, so Jelly was an attempt at a generic engine using ideas from JSP, JSTL, Velocity, Cocoon and Ant. /quote I can actually go along with the explanation of Jelly being molded into any shape, although that's a bit of a stretch of the word Jelly, as people don't really think of jelly as something you mold around something else. That is, I'll put jelly on my toast, but it's not the first thing I think of when I need something flexible and moldable like clay or Silly Putty. I should note at this point that I'm American, and the suggestion that British Jelly--our Jello--being moldable makes much more sense, as it is very common to mold Jello; but jelly and Jello have no implied connection here. If the original acronym (JELE) would have stuck, then the connection between jelly (by American definition) and something moldable would have made more sense, i.e. because you're not grasping at straws to use the word jelly to make the comparison since the name JELE is pronounced like the word jelly. Of course, the acronym would be problematic anyway since Java Elements isn't really meaningful either. Anyway, I'm the proverbial complainer with few good ideas to suggest as alternatives. :) I suppose if it were my invention, I would have named it something like Active XML, which conveys some meaning as to what it is and preemptively wards off some of the naysayers, (i.e. it stops short of the off-the-wall concept of executable XML and instead suggests that XML documents can be interactive, which is an important distinction). I'm aware of the fact that I'm beating this dead horse beyond recognition, but I'm enjoying this conversation. :) -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 17, 2005 8:52 AM To: Jakarta Commons Users List Subject: Re: [Jelly] Executable XML vs. Rich Configuration Le 16 mai 05, à 19:11, Dan Madoni a écrit : ...but Jelly? It might as well be called Blah or Hmmm, (don't get any ideas). :) re-interpreting differently... (really playing!): jelly glue along XML pipelines would be much understandable, or ? Doesn't jelly make you think, at least, to Jell-O or some jam a dirty kid would put on pens it borrows ? We probably need more explicit images for you! More or less kidding... but marketing brainstorming needs this, or ? paul PS: would honey or maple-syrup be more sticky ? PPS: I agree that the jelly-fish-like logo could be more explicit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Executable XML vs. Rich Configuration
On 5/19/05, Dan Madoni [EMAIL PROTECTED] wrote: [snip] I can actually go along with the explanation of Jelly being molded into any shape, although that's a bit of a stretch of the word Jelly, as people don't really think of jelly as something you mold around something else. That is, I'll put jelly on my toast, but it's not the first thing I think of when I need something flexible and moldable like clay or Silly Putty. I should note at this point that I'm American, and the suggestion that British Jelly--our Jello--being moldable makes much more sense, as it is very common to mold Jello; but jelly and Jello have no implied connection here. Come on, you're only American, if that's causing a problem for you, what about the rest of the world that doesn't even speak English! -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Executable XML vs. Rich Configuration
I've always liked the name Jelly... it makes me think of something very flexible and very much not rigid, which is very much the goal of XML in general and also of scripting tools. Then again, I start Homer-drooling every time I think about it, so that's a mark against it :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Dan Madoni wrote: Hello Paul. I can't speak for Hale, but I would like to respond to your comments since these are important issues to me. Regarding your comment on the idea that a change to Executable XML amounts to a subtitle change, I would argue that it isn't merely about a subtitle, but about positioning. This, of course, is a critical difference. Even though Jelly is OSS and all that, there is still a job of selling to do, both in order for Jelly to reach its potential, and so that the most developers possible can benefit from it, and perhaps contribute to its continued improvement. I know I've already said my piece about the name Jelly, but if you'll indulge me again: the name is meaningless, even more so than most Apache project names, (and that's saying something). At least Tomcat might conjure images of something agile and street-savvy; Betwixt implies something that sits between something else (which hints at what it is); of course, names like FileUpload and Logging are precise and immediately communicate the purpose of the project... ...but Jelly? It might as well be called Blah or Hmmm, (don't get any ideas). :) -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Saturday, May 14, 2005 12:34 PM To: Jakarta Commons Users List Subject: Re: [Jelly] Executable XML vs. Rich Configuration This seems to be another voice in favour of even changing Jakarta Commons Jelly... I am really surprised and would make sure I understand it correctly. Changing Executable XML into Rich Configuration or Running XML is about changing a subtitle... can I just request clarification ? thanks paul Le 13 mai 05, à 18:44, Hale India a écrit : In any case I would like to avoid exotic name which could give a bad image - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Executable XML vs. Rich Configuration
My first thought was a book I read in college about requirements called Nailing jelly to a tree - but personally I find it easier to remember and associate with a product, once I know what it is, than many other more descriptive names, especially the litany of products based on acronyms. Dan Madoni wrote: I know I've already said my piece about the name Jelly, but if you'll indulge me again: the name is meaningless, even more so than most Apache project names, (and that's saying something). At least Tomcat might conjure images of something agile and street-savvy; Betwixt implies something that sits between something else (which hints at what it is); of course, names like FileUpload and Logging are precise and immediately communicate the purpose of the project... ...but Jelly? It might as well be called Blah or Hmmm, (don't get any ideas). :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Jelly] Executable XML vs. Rich Configuration
Perhaps Jelly itself should be made into an acronym, which would make it both meaningful *and* memorable. :) Some suggestions for J.E.L.L.Y.: Jammin' Engine for XML Language and Lots more for You Join the Elites who Love to Lay out executable XML, Y Not? Jail Everyone who Loathes or Laughs at Your XML program Just Eat the Leftover Lasagna, Yvonne Jeeps, Escalades, Land Rovers, and Lincoln Navigators are popular SUV's. Oh, I forgot Yukons. Jerry Entertained Laura with his Lovely rendition of the 1950's hit Yakity Yak ...okay, I'll stop. :) -Original Message- From: Lauren Bish [mailto:[EMAIL PROTECTED] Sent: Monday, May 16, 2005 5:44 PM To: Jakarta Commons Users List Subject: Re: [Jelly] Executable XML vs. Rich Configuration My first thought was a book I read in college about requirements called Nailing jelly to a tree - but personally I find it easier to remember and associate with a product, once I know what it is, than many other more descriptive names, especially the litany of products based on acronyms. Dan Madoni wrote: I know I've already said my piece about the name Jelly, but if you'll indulge me again: the name is meaningless, even more so than most Apache project names, (and that's saying something). At least Tomcat might conjure images of something agile and street-savvy; Betwixt implies something that sits between something else (which hints at what it is); of course, names like FileUpload and Logging are precise and immediately communicate the purpose of the project... ...but Jelly? It might as well be called Blah or Hmmm, (don't get any ideas). :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Executable XML vs. Rich Configuration
Le 16 mai 05, à 19:11, Dan Madoni a écrit : ...but Jelly? It might as well be called Blah or Hmmm, (don't get any ideas). :) re-interpreting differently... (really playing!): jelly glue along XML pipelines would be much understandable, or ? Doesn't jelly make you think, at least, to Jell-O or some jam a dirty kid would put on pens it borrows ? We probably need more explicit images for you! More or less kidding... but marketing brainstorming needs this, or ? paul PS: would honey or maple-syrup be more sticky ? PPS: I agree that the jelly-fish-like logo could be more explicit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Jelly] Executable XML vs. Rich Configuration
Hello Paul. I can't speak for Hale, but I would like to respond to your comments since these are important issues to me. Regarding your comment on the idea that a change to Executable XML amounts to a subtitle change, I would argue that it isn't merely about a subtitle, but about positioning. This, of course, is a critical difference. Even though Jelly is OSS and all that, there is still a job of selling to do, both in order for Jelly to reach its potential, and so that the most developers possible can benefit from it, and perhaps contribute to its continued improvement. I know I've already said my piece about the name Jelly, but if you'll indulge me again: the name is meaningless, even more so than most Apache project names, (and that's saying something). At least Tomcat might conjure images of something agile and street-savvy; Betwixt implies something that sits between something else (which hints at what it is); of course, names like FileUpload and Logging are precise and immediately communicate the purpose of the project... ...but Jelly? It might as well be called Blah or Hmmm, (don't get any ideas). :) -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Saturday, May 14, 2005 12:34 PM To: Jakarta Commons Users List Subject: Re: [Jelly] Executable XML vs. Rich Configuration This seems to be another voice in favour of even changing Jakarta Commons Jelly... I am really surprised and would make sure I understand it correctly. Changing Executable XML into Rich Configuration or Running XML is about changing a subtitle... can I just request clarification ? thanks paul Le 13 mai 05, à 18:44, Hale India a écrit : In any case I would like to avoid exotic name which could give a bad image - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Executable XML vs. Rich Configuration
Le 11 mai 05, à 19:42, Dan Madoni a écrit : Perhaps a better term that isn't as restrictive as Rich Configuration or as strange as Executable XML might be Active XML Processing, or something like that. Such a term doesn't imply that you'll use it for programming, and instead suggests that it's useful for what you already use XML for, with Jelly adding a valuable active dimension to XML rather than just thinking of an XML document as a data container or template. Active XML processing tastes good although it might have a taste to be close to ASP which I really do not wish (that's kind of personal). How about the sub-title: XML processing with side-effects. (as opposed to XSLT processing) ? Or XML pipeline with effects. About the liability, I am not sure to understand you: I think the name Jakarta Commons Jelly is quite a good brand-name... I'd actually maybe like to help with the two big weaknesses I found in Jelly: sparse documentation and script error handling. I can't do that on my client's time, but feel free to e-mail me at [EMAIL PROTECTED] to discuss it on my own time. All this happens on commons-dev mailing list where you are happily invited! The documentation problem can become too big and I'd rather say we should just polish a bit only the little set before the release. The exception-in-the-face problem is a problem, for sure, see jira for this... I think that just, by default, displaying the line number would be better. paul PS: don't excuse yourself for such complaints, I've definitely understood your appreciation of Jelly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Executable XML vs. Rich Configuration
Dan Madoni wrote: I'm not sure how the argument can be made that processing semantics written in XML are more accessible than any well-designed language. snip/ In terms of human accessibility, I'd heartily disagree, acknowledging that the predication is a subjective one in any case. I have to admit my perspective is a bit subjective; i started my IT career as an HTML author and still carry the wrong assumption that markup is familiar even to non-programmers. In general though i think that XML does lower the bar for many different kinds of people, whether they are desingers with some markup experience or programmers that can choose from a variety of APIs and tools. A fine example of executable XML that shares some properties with Jelly is XSLT and few comment on it in the same manner they do for Ant build files (which, i believe, is where all this XML scripting is bad mostly comes from for some reason). It certainly isn't true in my case: my experience with using XML as a programming language is that it is much more cumbersome to express or discern something meaningful relative to programming languages that were designed from the outset to be programming languages. I can see your point, all i can say is that i dont think we dissagree. Most choices have their own pros and cons. Jelly is fabulous and certainly has its place; but as long as it is positioned as executable XML, which sounds about as relevant as Spreadsheet: The Video Game, few will understand or bother to investigate its usefulness. True, i think the term is unfortunate. Anyway, i think i've been too philosophical for this list already :-) Manos -Original Message- From: Emmanouil Batsis [mailto:[EMAIL PROTECTED] Sent: Thursday, May 12, 2005 12:25 AM To: Jakarta Commons Users List Subject: Re: [Jelly] Executable XML vs. Rich Configuration Paul Libbrecht wrote: I agree executable XML may suck With an emphasis on may ;-) This seems to be a common feeling. I never understood how most people dismiss so easily the fact that processing semantics written in XML are far more accessible (for humans and programs alike) than their non-XML counterparts. Manos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Executable XML vs. Rich Configuration
Le 11 mai 05, à 11:29, Paul Libbrecht a écrit : The best sub-title I found thus far was mix-and-match that's posted in one of the documentation pages. How about the following ? Apache Commons Jelly glue along XML pipelines (with side-effect!) paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Executable XML vs. Rich Configuration
Hi Just my one cent I was just looking for Rich Configuration when I have choosen to use Jelly for our project. And I got what I was looking for. Executable XML does not correspond to what it is and plus it seems to me that it not what people are looking for. I think that in maven, for example, jelly use is also for Rich Configuration. In any case I would like to avoid exotic name which could give a bad image Best regards Andre Legendre --- Paul Libbrecht [EMAIL PROTECTED] wrote: Le 11 mai 05, à 11:29, Paul Libbrecht a écrit : The best sub-title I found thus far was mix-and-match that's posted in one of the documentation pages. How about the following ? Apache Commons Jelly glue along XML pipelines (with side-effect!) paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Executable XML vs. Rich Configuration
Paul Libbrecht wrote: I agree executable XML may suck With an emphasis on may ;-) This seems to be a common feeling. I never understood how most people dismiss so easily the fact that processing semantics written in XML are far more accessible (for humans and programs alike) than their non-XML counterparts. Manos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Jelly] Executable XML vs. Rich Configuration
I'm not sure how the argument can be made that processing semantics written in XML are more accessible than any well-designed language. If you were to write an XML parser from scratch to handle Jelly scripts for instance (and don't forget to include parsing requirements for JEXL and other Jelly dependencies), it's likely you would require as much or more time developing code that can discern XML Jelly script semantics than if you went through the same exercise in writing, say, a C parser. Existing XML parsers typically provide API's that transform XML semantically from a mark-up language to a DOM representation. In this sense, XML semantics are easily accessible, but no less easily than any parser which transformed any structured language into a DOM representation. Then again, it may be apples and oranges to make this sort of comparison, but your assertion implies that such a comparison exists to begin with. In terms of human accessibility, I'd heartily disagree, acknowledging that the predication is a subjective one in any case. It certainly isn't true in my case: my experience with using XML as a programming language is that it is much more cumbersome to express or discern something meaningful relative to programming languages that were designed from the outset to be programming languages. Perhaps the most powerful argument against both of those assertions is your own observation that most people have the same visceral reaction. The instinctive repulsion to the idea of executable XML is not unlike the reaction one might have to the idea of using a screw driver to pound a nail. Jelly is fabulous and certainly has its place; but as long as it is positioned as executable XML, which sounds about as relevant as Spreadsheet: The Video Game, few will understand or bother to investigate its usefulness. -Original Message- From: Emmanouil Batsis [mailto:[EMAIL PROTECTED] Sent: Thursday, May 12, 2005 12:25 AM To: Jakarta Commons Users List Subject: Re: [Jelly] Executable XML vs. Rich Configuration Paul Libbrecht wrote: I agree executable XML may suck With an emphasis on may ;-) This seems to be a common feeling. I never understood how most people dismiss so easily the fact that processing semantics written in XML are far more accessible (for humans and programs alike) than their non-XML counterparts. Manos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] Executable XML vs. Rich Configuration
Dan, 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 self-defences...). 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 ! paul 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Jelly] Executable XML vs. Rich Configuration
Thanks for your reply, Paul. While I have several criticisms, my remarks need to be received in the context of my appreciation for Jelly. I have far more good than bad to say about it; but like most people, it's a lot easier for me to talk about the bad. :) I agree that rich configuration sells Jelly short (intelligent configuration or active configuration might come a little closer, but still wouldn't do it complete justice); but when it comes to positioning, I would argue that the issue isn't whether you sell something short as much as it is clearly demonstrating its usefulness. Because of its XML nature, the solved problem that immediately connects with Jelly would relate to configuration, storage, or perhaps page mark-up processing (a la Cocoon)--you know: XML-ly things. Perhaps a better term that isn't as restrictive as Rich Configuration or as strange as Executable XML might be Active XML Processing, or something like that. Such a term doesn't imply that you'll use it for programming, and instead suggests that it's useful for what you already use XML for, with Jelly adding a valuable active dimension to XML rather than just thinking of an XML document as a data container or template. I should also mention that the name Jelly may also be a liability. I know we're all geeks and we name things after pets or food or whatever makes for great lore; but for Jelly to grow up and be noticed, it needs a more meaningful name. I'd actually maybe like to help with the two big weaknesses I found in Jelly: sparse documentation and script error handling. I can't do that on my client's time, but feel free to e-mail me at [EMAIL PROTECTED] to discuss it on my own time. -Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 11, 2005 2:30 AM To: Jakarta Commons Users List Subject: Re: [Jelly] Executable XML vs. Rich Configuration Dan, 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 self-defences...). 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 ! paul 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
