Re: [Vote] Move portlet environment into portal block
Carsten Ziegeler wrote: In the scratchpad is the portlet environment which allows Cocoon to act as a JSR-168 producer. The portal block contains the JSR-168 consumer implementation. I propose to move the producer part from the scratchpad into the block combining both and maintaining everything that belongs to the portal in one place. (This will also avoid the duplicate need of the portal jars). So, please cast your votes: Here is my +1 :) +1 Chris.
Re: Of One-man Efforts and the like
Scott Robert Ladd wrote: Stefano Mazzocchi wrote: there are many ways to describe the spirit of the apache community, but there is one that I like more than all the others: we care about people more than we care about code. Well then, we are on the same philosophical ground! :) Great :-) Now. You, as the author and copyright holder, have the freedom to modify licensing at any time and for whatever reason. Here, nobody will tell you what's good or bad for you, you know that better than we all do. As I said in another message, I'm going to ponder the issues (again) this weekend. I appreciate the detailed responses, though. You are mostly welcome. There was some negative vibe going on, but we all understand that you didn't realize many of the legal implications of your move. Now for apache pretending and not giving back. telnet www.coyotegulch.com 80 Trying 64.70.152.229... Connected to coyotegulch.com. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Fri, 20 Feb 2004 22:11:31 GMT Server: Apache Connection: close Content-Type: text/html Point taken, though given the complexity of my personal website, I could probably use just about any web server. Sure. And, with all due respect, given the community we have, we could rewrite Jisp if we really wanted. It's not exactly rocket science. I don't do much server-side work anymore; my specialty is high-performance and numeric applications. I suspect Apache has more than its share of experts on parallel coding and optimization... no, not really :-) But there is room for some for sure! That given, I'll consider what everyone's said. I'll do a bit more research and thinking. Many thanks indeed. As for your experience with companies not paying you back: The ASF counts 840 committers. Thinking that all of them are college kids with a bunch of free time or really rich people that don't need to work to make a living, well, it's statistically very poor as an assumption. This community in particular has many companies that started and make profit out of seeling their knowhow to people. I used to do this myself. But selling yourself is an art and pretending that a software license will do that for you is just very naive (with all due respect). Removing my cocoon hat now, my suggestion, if you were asking me personally for advice, would be to donate the code to the ASF. This would allow: 1) the creation of a community around it (means you don't have to do the maintainance yourself!) 2) keep all apache projects happy 3) keep your name attached to it forever (means free advertising) The situation you are finding yourself into is a common one: a personal project that is successful and is used. Since there is no community, no mail list, not CVS, people bug you personally and this is frustrating and feels abusive. I know what that means, my name is attached to many very popular java projects and I still get questions for Ant, JMeter, JServ and the like even if I stopped working on those projects years ago. My answer is almost always ask the appropriate mail list. But you can't do that now. The ASF was created exactly to wrap code with communities and protect indiviuals from lawsuits and general abuse, even private abuse like the one you have experienced. Of course, at that point, even protected, this won't solve your marketing for you or the way you sell yourself to companies. In short, you are on your own for that and you can be successful or suck. We have examples of both kinds in the ASF. But again, going the GPL way will lock you out of the ASF world, this means loosing all the visibility you had before. I'm not saying this is good or bad, the choice is yours. At the same time, you could find lots of reasonable people with very much in common with you that might help you in many ways in case you feel like joining forces. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Java continuations with joeq
I recently took a look at joeq (http://joeq.sourceforge.net/) which is a Java virtual machine written in Java. Included is a reflective Java interpreter that can run on top of an existing Java virtual machine (e.g. Sun JRE). It can interpret class files, but can also delegate some (or all) method calls to the underlying VM as well. It looks like it would be quite easy to support Java language continuations with this interpreter. There are some drawbacks however: 1) In order to be included in a continuation a method call must be interpreted by joeq - not by the underlying VM (= severe performance penalty. Probably at least 15 to 20 times slower than hotspot compiled code). Although the joeq interpeter is very high quality, I did some informal tests and it appears to actually be slower than interpreted Rhino (not sure exactly why, perhaps because Rhino bytecodes are higher level), but was significantly faster than BeanShell (which is a Java source code interpreter). 2) It has an LGPL license. Chris
Re: Java continuations with joeq
Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a écrit : ...I did some informal tests and it appears to actually be slower than interpreted Rhino (not sure exactly why, perhaps because Rhino bytecodes are higher level), but was significantly faster than BeanShell (which is a Java source code interpreter). Is it a lot slower, do you think it would make a significant difference? 2) It has an LGPL license. Means we might have to talk its author into changing the license, it wouldn't be the first one ;-) Note also an interesting comment of Geert Bevin on Steven's weblog at http://blogs.cocoondev.org/stevenn/archives/001745.html, he says I'll soon have added support for continuations with Groovy in RIFE too From what I've seen Groovy looks like a very nice and fairly complete scripting language, which also has an ASF-like license. So, if Groovy is really close to have continuations, we might want to wait or help? The only mention of continuations that I found on the groovy mailing lists is at http://thread.gmane.org/gmane.comp.lang.groovy.devel/298 -Bertrand
RE: Java continuations with joeq
From: Bertrand Delacretaz Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a écrit : ...I did some informal tests and it appears to actually be slower than interpreted Rhino (not sure exactly why, perhaps because Rhino bytecodes are higher level), but was significantly faster than BeanShell (which is a Java source code interpreter). Is it a lot slower, do you think it would make a significant difference? 2) It has an LGPL license. Means we might have to talk its author into changing the license, it wouldn't be the first one ;-) Note also an interesting comment of Geert Bevin on Steven's weblog at http://blogs.cocoondev.org/stevenn/arch ives/001745.html, he says I'll soon have added support for continuations with Groovy in RIFE too From what I've seen Groovy looks like a very nice and fairly complete scripting language, which also has an ASF-like license. So, if Groovy is really close to have continuations, we might want to wait or help? The only mention of continuations that I found on the groovy mailing lists is at http://thread.gmane.org/gmane.comp.lang.groovy.devel/298 Since Cocoon supports continuations they seem to attract more and more interest in the web development world ;-) Anyway, for me only **Java** Flowscript would really make sense because this would safe the two (technical) arguments against JavaScript flow: Java is type safe and it is compiled. So you can catch (some) errors at compile time and not at run time. If there is support for Groovy, Pyhton, [or whatever] continuations, I personally don't care because it doesn't make a real difference (languages are a matter of taste ...) and I don't think we should spread our energy over different Flowscript interpreter implementations which have to be maintained. Only my 2 cents ... -- Reinhard
Re: Java continuations with joeq
On 21 Feb 2004, at 17:48, Reinhard Poetz wrote: Since Cocoon supports continuations they seem to attract more and more interest in the web development world ;-) Which proves Ovidiu's visionary skills. We owe him a great deal because of this. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Java continuations with joeq
Reinhard Poetz wrote: If there is support for Groovy, Pyhton, [or whatever] continuations, I personally don't care because it doesn't make a real difference (languages are a matter of taste ...) and I don't think we should spread our energy over different Flowscript interpreter implementations which have to be maintained. Well, we actually have to maintain a non-current forked version of Rhino (even if pretty stable actually), so I'd much rather change my taste (I quite like Javascript flow actually) if that buys me a more hassle-free continuation engine. Ciao, -- Gianugo Rabellino
RE: Java continuations with joeq
From: Gianugo Rabellino Reinhard Poetz wrote: If there is support for Groovy, Pyhton, [or whatever] continuations, I personally don't care because it doesn't make a real difference (languages are a matter of taste ...) and I don't think we should spread our energy over different Flowscript interpreter implementations which have to be maintained. Well, we actually have to maintain a non-current forked version of Rhino (even if pretty stable actually), so I'd much rather change my taste (I quite like Javascript flow actually) if that buys me a more hassle-free continuation engine. Point taken, but we released Cocoon 2.1 half a year ago. Let's say we manage adding support for e.g. a GroovyFlowInterpreter and declare it as stable let's say in half a year. Firstly, I think this move would be very confusing for our user base. Secondly, I think somebody will come up with a JavaFlow implementation sooner or later. Let's say this happens in 18 months. This would mean we release an 'official flow implementation' every year ... -- Reinhard
RE: Java continuations with joeq
From: Gianugo Rabellino Reinhard Poetz wrote: If there is support for Groovy, Pyhton, [or whatever] continuations, I personally don't care because it doesn't make a real difference (languages are a matter of taste ...) and I don't think we should spread our energy over different Flowscript interpreter implementations which have to be maintained. Well, we actually have to maintain a non-current forked version of Rhino (even if pretty stable actually), so I'd much rather change my taste (I quite like Javascript flow actually) if that buys me a more hassle-free continuation engine. Point taken, but we released Cocoon 2.1 half a year ago. Let's say we manage adding support for e.g. a GroovyFlowInterpreter and declare it as stable let's say in half a year. Firstly, I think this move would be very confusing for our user base. Secondly, I think somebody will come up with a JavaFlow implementation sooner or later. Let's say this happens in 18 months. This would mean we release an 'official flow implementation' every year ... -- Reinhard
Re: Java continuations with joeq
On 21 Feb 2004, at 19:24, Gianugo Rabellino wrote: Well, we actually have to maintain a non-current forked version of Rhino (even if pretty stable actually), so I'd much rather change my taste (I quite like Javascript flow actually) if that buys me a more hassle-free continuation engine. I'm two of a kind on this: at the very least, JavaScript is a well-known standardized language, and looking at other uses of Rhino, it is a well-known and robust library. Too bad about the fork unfortunately. Groovy might have more sensible bindings with the Java language, it looks cool, but it's still a little language ATM. Then again, the expression language we use in Woody is a little language as well. Overall, I sense an interest to opt for ASF packages whenever possible. Both Rhino++ and Groovy aren't (c) ASF, so that point is moot. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Of One-man Efforts and the like
Scott Robert Ladd wrote: I almost think you are spoiling for a fight, since you insist on misrepresenting what I say. My intent is only to decipt the situation from our side so that you can have more input when judging how to license your code. I sincerely apologize if anything I've written came across as unrespectful or if you perceived that I put words in your mouth: it was not my intent to offend you or to spoil a fight. I just wanted to tell you our story and offer some help in case you want it. That's all. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Of One-man Efforts and the like
Stefano Mazzocchi wrote: I sincerely apologize if anything I've written came across as unrespectful or if you perceived that I put words in your mouth: it was not my intent to offend you or to spoil a fight. Apology accepted. I just wanted to tell you our story and offer some help in case you want it. That's all. And I appreciate the story. It helps me see where and if I fit into the Apache picture. ..Scott -- Scott Robert Ladd Coyote Gulch Productions (http://www.coyotegulch.com) Software Invention for High-Performance Computing
Re: Java continuations with joeq
On Feb 21, 2004, at 2:47 PM, Steven Noels wrote: Overall, I sense an interest to opt for ASF packages whenever possible. Both Rhino++ and Groovy aren't (c) ASF, so that point is moot. Umh... continuations in PHP or Jelly. That covers Apache (c) languages available ;-) -Brian
RE: Java continuations with joeq
Reinhard Poetz dijo: Since Cocoon supports continuations they seem to attract more and more interest in the web development world ;-) This is great! This means Cocoon is the leader in webapp development! :-DD Anyway, for me only **Java** Flowscript would really make sense because this would safe the two (technical) arguments against JavaScript flow: Java is type safe and it is compiled. So you can catch (some) errors at compile time and not at run time. But it can be abused too. This is one of the plus we found a year ago. comment AFAIK, the initial wisdom started with scheme, then we switched to javascript (thanks to Christian Oliver). All is documented in the 1 year of development in maillists. After Flow development reached a milestone, people started to comment about the pros and cons of using Javascript. Here is a interesting mail of these times (from Stefano): http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105284906231855w=2 The full thread is here: http://marc.theaimsgroup.com/?t=10527582916r=1w=2 /comment Now we have a year of Flow in Cocoon and based on our experience with Flow it is time to think how to improve it. I am not sure if Java is the best. Sometimes I will like to have the power of the eclipse IDE to debug my show flows, but In short I think this is a very interesting discusion that for sure will bring Flow to the next level. Best Regards, Antonio Gallardo
Momento Zip Distribution
Ya'll Momento is now ready for download. http://engrm.com/project/com.agtrz.momento/ Let me know if this works! Dependencies: JDK 1.4 Ant 1.6 Unzip zip distribution and run: ant -f mix.bootstrap.xml Then run: ant mix.distrubtion You should have a momento distribution. For those of you who, like me, are running Eclipse, also download: http://engrm.com/project/com.agtrz.xfixture/ http://engrm.com/project/com.agtrz.sax.strategy/ Follow the above instructions for both. Now load the projects into Eclipse and you will be in my build envrionment. I eagerly await your questions. Cheers. -- Alan / [EMAIL PROTECTED] / http://engrm.com/ aim/yim: alanengrm - icq: 228631855 - msn: [EMAIL PROTECTED]
Re: Momento Zip Distribution
Alan dijo: Ya'll Momento is now ready for download. http://engrm.com/project/com.agtrz.momento/ Let me know if this works! Dependencies: JDK 1.4 We will need here JDK 1.3 compatibility. Maybe a recompilation is enough. Best Regards, Antonio Gallardo
Re: Momento Zip Distribution
* Alan [EMAIL PROTECTED] [2004-02-21 22:35]: Momento is now ready for download. http://engrm.com/project/com.agtrz.momento/ Er, click on download in the sidebar and download the zip file... -- Alan / [EMAIL PROTECTED] / http://engrm.com/ aim/yim: alanengrm - icq: 228631855 - msn: [EMAIL PROTECTED]
Re: Momento Zip Distribution
* Antonio Gallardo [EMAIL PROTECTED] [2004-02-21 22:39]: Alan dijo: Ya'll Momento is now ready for download. http://engrm.com/project/com.agtrz.momento/ Let me know if this works! Dependencies: JDK 1.4 We will need here JDK 1.3 compatibility. Maybe a recompilation is enough. Don't know. I've had the 1.4 switch on in Eclipse. Saxon requires 1.4. I can play around with 1.3 settings and see if they work. Who wants 1.3? -- Alan / [EMAIL PROTECTED] / http://engrm.com/ aim/yim: alanengrm - icq: 228631855 - msn: [EMAIL PROTECTED]
[FYI] Cocoon reviewed in RLG DigiNews February 2004 Issue
My boss forwared this to me today: http://www.rlg.org/preserv/diginews/diginews8-1.html#hws A little context: quote RLG is a not-for-profit membership corporation of over 160 universities, national libraries, archives, historical societies, and other institutions with remarkable collections for research and learning. Rooted in collaborative work that addresses members' shared goals for these collections, RLG develops and operates information resources used by members and nonmembers around the world. Founded in 1974 and incorporated in 1975 by Columbia, Harvard, and Yale Universities and The New York Public Library, RLG was conceived to help achieve the economies and power of service that come from pooling resources, expertise, and operations. The organization became a pioneer in developing cooperative solutions to the problems that research collections and their users face in the acquisition, delivery, and preservation of information. /quote There is a clear perception of very *strong* convergence in the world of digital libraries toward Cocoon because the philosophy of separation of concern is something that all librarians resonate with (unlike the centralized, self-publishing orientation of the old web, that was done exactly to route around centralized libraries). For the digital libraries oriented people on this list, I can tell you that DSpace 2.0 will be using cocoon as the presentation layer. The shape of the 2.0 architecture is not yet defined, but a few ideas were fixed and the use of cocoon was one of them (apparently, lots of people asked them for this!) MIT OpenCourseWare (OCW) is very interested in Cocoon/Lenya, both for publishing and for content management. MIT MetaMedia is already based on Cocoon even if they don't say so [it was a surprise for me as well!] (see metaphor.mit.edu) And this has nothing to do with my presence here, since these decisions were already taken before I arrived. This said, everybody here is very excited about my presence because that glues the pieces together, so expect acceleration in the cocoon adoption at MIT. Ah, for the MIT people on this list, I'll be giving a Cocoon Walkthrough on March 8th for the Digital Libraries Research Group and other interested parties (like OCW) If you want to be invited, let me know privately. Thanks. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Momento Zip Distribution
* Alan [EMAIL PROTECTED] [2004-02-21 22:35]: Ya'll Momento is now ready for download. I just ran the build script again. If you downloaded in the last five minutes I am very sorry. :^( I eagerly await your questions still. (Off to Endemyon! Le Bon Temps Roule.) -- Alan / [EMAIL PROTECTED] / http://engrm.com/ aim/yim: alanengrm - icq: 228631855 - msn: [EMAIL PROTECTED]
Re: Of One-man Efforts and the like
On 21 Feb 2004, at 18:56, Scott Robert Ladd wrote: lots of snippage ahead Do I become more or less visible by donating Jisp to Apache? What do I give up, and what do I gain? This thread is helping me answer such questions. I think it's safe to say to a proper donation (provided it is accepted) of Jisp to the ASF might result in higher visibility of Jisp, and consequently of its main author. It is up to your own judgment whether you are seeking this visibility and whether the associated responsibilities and your private goals balance out. As you seem to indicate your interests might be in a different area than the one we are using Jisp for, I'm not entirely sure about this path. OTOH, we have seen many less mature projects candidating for ASF adoption, so the ASF brand seems to be a precious good. Again, you find words I never wrote. I like people asking me questions about Jisp; I am more than happy to support the package myself. My annoyance is that I've had people who expect me to provide free services because it's part of free-as-in-beer Apache. I am annoyed by specific case, not support in general. As I tried to explain, ASF projects typically address the burden of support by spreading it across a *community* of developers and users. Still, no-one can or should expect support to be readily available, let alone for free, just because the license allows for free redistribution and use. These days, for-pay support seems to be a reasonable way to make money out of open source, but this shouldn't mean the license should forbid free commercial use and redistribution. I think usage licenses and support models are different things, and the license alone will not help you much in defending your commercial interests. People will be attracted to your services because they see the quality of your work, and because they shouldn't be afraid to use your work because of reciprocity clauses. And if they make serious use of your work, they will come after support if they need to anyhow. Or that's at least how it sometimes works for us. The ASF was created exactly to wrap code with communities and protect indiviuals from lawsuits and general abuse, even private abuse like the one you have experienced. I applaud Apache's purpose. I think the FSF exists primarily to promote the egos of certain people, as opposed to caring about the needs of working programmers. Apache appears to have its heart in the right place. Thanks. :-) Of course, at that point, even protected, this won't solve your marketing for you or the way you sell yourself to companies. In short, you are on your own for that and you can be successful or suck. We have examples of both kinds in the ASF. But again, going the GPL way will lock you out of the ASF world, this means loosing all the visibility you had before. I'm not certain how visible I am in the ASF world. You and others point out that Jisp is a rather obscure, hidden, and easily-replacable component of some parts of Apache; that doesn't sound like much visibility to me. To attain visibility in Apache, I would need to do something more tha Jisp, I suspect. And so the question becomes: Is there something (beyond Jisp) that I can contribute, and will my increased visibility attract customers who need my skills? That is the debate I'm having with myself this weekend. On the visibility of Jisp in Cocoon, I can only repeat what I and some others stated: it's not very visible for mundane users, and its use has been made a configuration setting (which is the case with most Cocoon components) so that it can be swapped out. And we are already investigating what other cache or persistency engine we could integrate instead of Jisp - possibly JCS (http://jakarta.apache.org/turbine/jcs/index.html) since they are confronted with the same issue ATM. Now, about the visibility of a library like Jisp as a standalone project, I think you should investigate a bit of the history of Lucene (http://jakarta.apache.org/lucene/). It used to be a one-man-effort by Doug Cutting (also not quite a college kid), which was known and appreciated by quite a few people (as Jisp is right now), but still it became really well known only *after* it became part of Apache. I'm not saying you *should* follow the path of donation and incubation, since this requires a lot of work and energy, I just want to show you that being part of a larger family could buy you something. Hope this helps, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
[FYI] Niagara
Might want to take a look at this: http://www.cs.wisc.edu/niagara/ seems pretty interesting as a concept. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Mock classes without ASF license
Hi: We (Cocoon Community) already wrote some mock classes in blocks to allow sucessful compile even if a non-redistributed jar is missing. ie: mock classes in OJB block for JDO support. Currently, these mock java classes have not copyright notice. Is this correct? or we need to include a copyright notice and the respective ASL in each of these file? BTW, seeing that the ASL 2.0 need less code inside each source. I wonder how many kB will lose the current Cocoon code. ;-) Best Regards, Antonio Gallardo
Re: Problems with capture logicsheet function dom-variable
Dietmar Schlar wrote: I was trying to get a document fragment into a DOM variable in a XSP with: capture:dom-variable name=SomeFragment sometagxxxyyyzzz/sometag /capture:dom-variable But it fails with a NULL Pointer exception (without any usefull information ...). It's been an year ago... I think this does not work because of some bug in DOMBuilder: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104869688524792w=2 Vadim
Re: Java continuations with joeq
Stefano Mazzocchi wrote: Brian McCallister wrote: Umh... continuations in PHP or Jelly. That covers Apache (c) languages available ;-) Correction: as of a few days ago, PHP is no more a project of the ASF :-) Interesting... I always wondered why PHP is sooo non-Apache... Neither Apache front page nor PHP yet got updated with these news. Vadim
Re: Jisp 3.0 moved to GPL licence
Alan wrote: * Antonio Gallardo [EMAIL PROTECTED] [2004-02-20 11:25]: Reinhard Poetz dijo: Am 14:01 10.02.2004 -0500 schrieb Steve Krulewitz: Does anyone know what happened to the jisp website? The old URL http://www.coyotegulch.com/jisp/index.html sends you to an invalid link. It's back up now: http://www.coyotegulch.com/jisp/ I never went there before it went down, but it now has a version 3.0.0. That version isn't under the old license anymore but GPLed (or commercial for 2500$). Old versions I can't find there.. gunnar ps: sorry if you get this mail twice, steve. small mistake by me. -- G. Brand - interface:projects GmbH As our store depends on Jisp - what does this mean for us? IMO we have to look for a replacement. Any ideas/hints? AFAIK, we must move away from jisp. That was an ugly move! :-( Maybe this is a crazy idea but: Is posible to replace jisp with Apache Xindice? Mainly because I have concerns for another ugly move (as jisp did) if we choose a solution from a 3rd party again. If we use Apache Xindice I think this cannot happen again. Can I suggest moving to Momento? Alan, whilst I _am_ very interested to read about Momento, I do wonder if it is what we need for our caching persistence engine. I would describe that as primarily a binary data store, while sometimes storing XML. The cache sometimes stores XML part way through a pipeline, but usually stores the serialised result of a page, which may be in any format (i.e. binary). I tend to think that Momento isn't suited to this need. However, as an XML data repository, it seems very interesting. Regards, Upayavira snip/
