Re: FYI: OSGi JSR
Daniel Fagerstrom wrote: Apache and some other well known organizations have started an JSR for dynamic component framework in Java SE based on OSGi. http://www.osgi.org/blog/2006/02/jsr-291-dynamic-component-support-for.html http://www.jcp.org/en/jsr/detail?id=291 4 months to get a JSR out of the door? whatever. This seems a rushed up battle against JSR 277, which states: The current version of the Open Services Gateway Initiative (OSGi) specification defines a framework that enables the deployment of service-oriented applications (called bundles). However, the framework only supports package dependency based on the minimum version of a specification, and there is no support for exact version or version range. The framework also supports package dependency based on an implementation, but there is no support for versioning. Moreover, the framework must choose one bundle that will be the provider of the exported package for all bundles which have dependencies on that package, so it is impossible to support more than one version of shared package at runtime. Besides, the selection of exported package provider is anonymous, and there is no way to influence the selection. Because the versioning semantics in the OSGi framework is simplistic, it is not a sufficient solution to address the JAR referencing problem. While JSR 291 states: No current JSR (either complete or in process) defines a dynamic component and lifecycle solution to run on top of the existing family of Java SE platforms. However, JSR 232 does include this capability to run on top of Java ME (CDC based platforms) along with a comprehensive set of mobility services. JSR 277 has been filed to examine changes to the static module definition to be used within the Java SE platform for Java 7 (Dolphin) and beyond. JSR 277 is targeted for specification delivery in 2H/2007 with RI/TCK delivery as an integral part of Dolphin in 2008. This JSR aims to address the current needs for dynamic components based on existing Java SE platforms. When Dolphin becomes available, the specification lead of this JSR will either perform a maintenance release of this JSR or raise a follow on JSR to add Dolphin to the list of compatible supported platforms and to exploit Dolphin technology for static modules, as appropriate. These two JSRs are heading on a massive collision course. -- Stefano Mazzocchi Research Scientist Digital Libraries Research Group Massachusetts Institute of Technologylocation: E25-131C 77 Massachusetts Ave telephone: +1 (617) 253-1096 Cambridge, MA 02139-4307 email: stefanom at mit . edu ---
Re: [2.2] Simplifying configuration
Carsten Ziegeler wrote: In the last days I simpliefied the configuration for 2.2 a little bit. Since you're at it, I would suggest considering removing a lot of the cocoon.xconf stuff and turn them into compile-time settings. Two things should happen for cocoon 2.2, IMO: 1) if you *do not* have a cocoon.xconf file (or other xconf files), cocoon should behave normally. [this avoids the 'programming by configuration' problem that we 2) if a configuration change can break cocoon, it should not be a configuration but a compile-time switch. so #1 is for out of the box behavior, #2 is for solidity in your hands behavior. -- Stefano.
Re: [ANN] VTD-XML Version 1.5 Released
Jimmy Zhang wrote: Hi, Thanks for the email. My answers to your questions: 1. It is a tradeoff-VTD-XMl consumes more memory, but is easy to use and more powerful, Any random access capable XML processing API *needs* to at least load the entire hierachical structure in memory. My take is that among SAX, STAX, DOM and JDOM, vtd-xml is the least likely one to choke, and best one to handle peak loads... whatever most XSLT cases *NO NOT* need to load the xml in memory to be able to process it. Unless you abuse xsl:sort or xpaths with .., most things can be done with pure event-driven pipeline style, and only a small buffer needs to be kept in memory. Xalan XSLTC is able to pre-process xslt stylesheets and compile them into code that will know how much buffer to keep because it knows what kind of xpath events will be called on the incoming stream. 2. Agree with you, benchmarking a dummy SAX parser is unfair for VTD-XML, that will make VTD-XML look prettier in real life scenario. whatever #2, playing smartass (and avoiding the issue that I mentioned) is unlikely to make your points more solid. 3. Look at all the vertical industry XML related vocubalry, SOAP, Rest and XML schema, and infoset data model, DTD seems deprecated a bit, and VTD-XMl doesn't support external entities... other than that VTD-XML is equally capable I agree that DTDs should be deprecated and seem like an SGML vestigial feature. My point is that it's unfair to compete with a fully compliant xml parser with a parser that knows how to cut corners (and therefore doesn't have to scan the text for entities to expand!). if xerces was allowed to get away with no need to parse entities and didn't have to create strings, it would be just as fast as yours. BTW, you have not answered these questions: You claim xpath random access, but what is the algorithmical complexity of that? O(1), O(log(n)), O(n), O(n*log(n))? If one were to store the parsed tree index on disk, how many pages would one need to page in before reaching the required xpath? -- Stefano.
Re: [VOTE] Release 2.1.9
Ralph Goers wrote: The forms block is now marked stable. I believe legal has given the OK for us to use the JCR api. To the best of my recollection I believe those were the only two items standing in the way of a 2.1.9 release. So please vote. My +1 +1 -- Stefano.
Re: [ANN] VTD-XML Version 1.5 Released
Jimmy Zhang wrote: Eight years after the invention of XML, DOM and SAX, despite their respective issues, are still the mainstays of application developers. So is it the end of road for XML parsing innovation? The VTD-XML project team think not. We are proud to announce the availability of both C and Java version 1.5 of VTD-XML, the next generation open-source XML parser that goes beyond DOM and SAX in terms of performance, memory usage and ease of use. The technical highlights of VTD-XML are: * Performance: the world's fastest XML parser, between 5x~10x faster than DOM * Memory Usage: 3x to 5x less than DOM, 1.3x~1.5x XML document size * Random access with built-in XPath support * A simple and intuitive API Other advanced features include: * Buffer reuse * Large document support (2GByte) * Incremental update * Hardware acceleration * Native XML indexing. For demos, latest benchmarks, related articles and software downloads, please visit http://vtd-xml.sf.net. Also let us know your thoughts and suggestions and help us improve VTD-XML. H, I have to admit that I've toyed with this idea myself lately, especially since I'm diving deep into processing large quantities of XML files these days (when I say 'large', I mean it, large that 32 bits of address space are not enough). The idea of non-extracting parsing is nice but there are few issues: 1) the memory requirements, still much less than DOM, but are still *way* more than an event-driven model like SAX. Cocoon, for example, would die if we were to move to a parser like this one, especially under load spikes. 2) benchmarking against a dummy SAX content handler is completely meaningless. in order for the API to be of any use, you have to create strings, you can't simply pass pointers to char arrays around. I bet that if the SAX parser could go on without creating strings, it would be just as fast (xerces, in fact, does use a similar mechanism to return you the character() SAX event, where the entire document is kept in memory and the start/finish pointers are passed instead of a new array. 3) 90% of the slowness comes from 10% of the details in the XML spec, which means in order to keep fast, you need to sacrifice compliance... which is not an option these days given how cheap silicon is. But don't get me wrong, I think there is something interesting in what you are doing: I think it would be cool if you could serialize the 'tree index' alongside the document on disk and provide some sort of b-tree indexing for it. It would help me in my multi-GB-of-XML day2day struggle. You claim xpath random access, but what is the algorithmical complexity of that? O(1), O(log(n)), O(n), O(n*log(n))? If one were to store the parsed tree index on disk, how many pages would one need to page in before reaching the required xpath? -- Stefano.
Re: svn commit: r376379 - in /cocoon/blocks/serializers/trunk: charsets/ charsets/src/org/apache/cocoon/components/serializers/encoding/ java/org/apache/cocoon/components/serializers/
Pier Fumagalli wrote: On 9 Feb 2006, at 19:37, Antonio Gallardo wrote: [EMAIL PROTECTED] wrote: Author: pier Date: Thu Feb 9 10:49:12 2006 New Revision: 376379 URL: http://svn.apache.org/viewcvs?rev=376379view=rev Log: Backporting changes from BRANCH_2_1_X Backporting? You are foreporting, right? ;-) E sta` a guarda` er capello! (loosely translated for the non Italians, picky, are you! :-) LOL -- Stefano.
Re: Block deployment: working with blocks from a user's point of view
Giacomo Pati wrote: My final concern in this will be that Cocoon can be used as a platform (not just a framework) to host an arbitrary number of independant applications maintainable by the set of tools we develop/deliver here for deployment of such application and management of the Cocoon instance. There is a natural tendency for people to isolate independent services to that damage in one doesn't affect the other. It can be seen in clusters, OSs, JVMs, webapps and now blocks. I think it's not a bad thing that people can host two different things in the same cocoon (if they have memory issues, for example, it's a good thing), but if not, they have all a range of choices to do otherwise and I'm sure we target a user base that knows about all these anyway. -- Stefano.
Re: [M10N] cocoon-jcr
Jorg Heymans wrote: Giacomo Pati wrote: I'm trying to get the cocoon.jcr block compiling but cannot find a jcr-1.1.jar to download from any of the maven repos I know of. Anybody knows of one? I've found a jcr-1.0.jar at http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day server in our poms. I also don't know whether that one is publically redistributable and the Maven 2 docs suggests downloading it from the official Sun site and installing it into each ones local Maven2 repository. Any ideas how to solve this? This is mentioned in the maven docs (though of not much help) : http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html Also read the discussion on repository@apache.org : http://mail-archives.apache.org/mod_mbox/www-repository/200512.mbox/thread (thread Making a redist of all the javax.* packages) Aren't there geronimo packages available for this, like eg geronimo-spec-javamail.jar ? careful. JCR is *NOT* part of J2EE, so looking for them in Geronimo is the wrong place. The reference implementation of JCR is JackRabbit, currently under incubation. NOTE: unlike much of the sun stuff, JCR is released under a compatible license that was written by our very own Roy Fielding and is very similar to the Apache License 2.0, and designed to be compatible with it. I don't know the status of the licensing releasing of JCR, though, but I'm sure the email I copied on jackrabbit will give us the answers we want. -- Stefano.
Re: [M10N] cocoon-jcr
Giacomo Pati wrote: I'm trying to get the cocoon.jcr block compiling but cannot find a jcr-1.1.jar to download from any of the maven repos I know of. Anybody knows of one? I've found a jcr-1.0.jar at http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day server in our poms. I also don't know whether that one is publically redistributable and the Maven 2 docs suggests downloading it from the official Sun site and installing it into each ones local Maven2 repository. Any ideas how to solve this? I'm copying this to jackrabbit-dev because I honestly don't have an answer for this. -- Stefano.
Re: (Re)Licensing question
Helma van der Linden wrote: Guys, I usually keep away from licensing issues, but this time I'd like to know if it is done correctly. I'm looking at a project that is made up of several other open source projects, cocoon is one of them, another (sub)project is licensed under BSD. This project is licensed under GPL. It doesn't say that only their part is GPL and others are licensed differently. Looks like they included the entire Cocoon source tree with licensing files for all external jars used and they also left in the ASF license headers in the various files. Is this correct? According to both the FSF and the ASF legal counselors, the GPL2.0 is not compatible with the AL2.0 because of the patent termination clause of the apache license. More information can be found here: http://www.apache.org/licenses/GPL-compatibility.html There *IS* a way, however, to license your software as GPL and have it link to apache licensed software (or other GPL-incompatible free software licenses): you have to 'extend' the GPL by saying explicitly that only the part of the software that you own is covered by the GPL and not the entire bundle. Each part is covered by its own license and the GPL does not apply to that. As an example of such a thing see http://www.mysql.com/company/legal/licensing/foss-exception.html NOTE: there is legal debate to whether or not such an exception would stand if tested in court, but this is true for almost anything in the legal world anyway, but if you put such a GPL extension in place both sides of the open source and free software world would be happy and won't come after you. Others might, though, (see SCO), and the GPL2.0 does *NOT* have any sort of IP protection mechanisms in place when that happens but that's a risk that you take by just writing software these days. HTH -- Stefano.
Re: (Re)Licensing question
Andrew Stevens wrote: From: Helma van der Linden [EMAIL PROTECTED] Date: Tue, 10 Jan 2006 17:31:25 +0100 Guys, I usually keep away from licensing issues, but this time I'd like to know if it is done correctly. I'm looking at a project that is made up of several other open source projects, cocoon is one of them, another (sub)project is licensed under BSD. This project is licensed under GPL. It doesn't say that only their part is GPL and others are licensed differently. Looks like they included the entire Cocoon source tree with licensing files for all external jars used and they also left in the ASF license headers in the various files. Is this correct? Given that GNU [1] list the Apache licenses as GPL-Incompatible, Free Software Licenses, I've always interpreted that to mean that you can't link to (i.e. make use of) Apache-licensed libraries (jars) in a project that you're releasing under the GPL. They don't appear to have an equivalent list for LGPL compatibility, unfortunately. I do recall that previous discussions on this list have stated that Apache-hosted projects aren't allowed to [L]GPL libraries in their CVS repositories. If I've got this all backwards, someone please let me know; I've a project of my own [2] that I would have licensed under GPL if not for the fact that I made use of libraries that were released under Apache and BSD licenses. Instead I went for LGPL on the grounds that I can find a lot of other LGPL'd projects that use the same libraries, so it looks like that's okay... FYI, LGPL is incompatible with the Apache License as much as the GPL, so the exact same reasoning applies. -- Stefano.
Re: (Re)Licensing question
Pier Fumagalli wrote: On 10 Jan 2006, at 16:31, Helma van der Linden wrote: Guys, I usually keep away from licensing issues, but this time I'd like to know if it is done correctly. I'm looking at a project that is made up of several other open source projects, cocoon is one of them, another (sub)project is licensed under BSD. This project is licensed under GPL. It doesn't say that only their part is GPL and others are licensed differently. Looks like they included the entire Cocoon source tree with licensing files for all external jars used and they also left in the ASF license headers in the various files. Is this correct? It definitely is... The ASF doesn't pose any whatsoever restriction when its code is being re-distributed by a third party (you could virtually sell the ASF sources, and noone would be able to stop you). In this particular case, the entire project you methion is GPL licensed, thus, any modifications made to it will be (as well) have to be GPLed. This will guarantee that whoever inherits any of the files from that project will have to redistribute them using the same license (in case of any modification). The problem might arise for those willing to modify code based on that project and re-publish those changes: If they submit changes to (let's say) Cocoon's sources back to the project you're mentioning. The person modifying those sources can either choose to submit them back to us (the real source) or to the project they downloaded (the distributor). In the first case, we'll accept those modifications only if we can make them our own (copyright is assigned and transfered to the ASF) and will include them (hopefully) in our next release. In the second, those changes will be in the hands of the distributor (and thus GPLed). There are two options, either the copyright of those changes is transfered to the ASF by the distributor (and then we'll follows what's described above) or they'll have to maintain those patches themselves as we're not going to include GPL licensed code in our repository... I hope this clears it a little bit... Hmmm In the real world, the ASF will *NEVER* come after you if you link apache licensed material from a GPL-ed project, neither would the FSF. But the matter of fact is that the apache license has a patent bomb built into it that the GPL doesn't like because it's considered a *further restriction* and the GPL has a very well defined set of 'freedoms' that it gives you and, unfortunately, it also gives people the freedom to sue your ass over IP infringement without any side effects on the licensing part of the software. The ASF is a innovator in this space (and the FSF is going to catch up with the GPL3, hopefully) because it first introduced this you sue my friend, I screw you clause. So, if EvilCocoonCorp sues GoodCocoonCorp over IP infringement of some patent they have and that Cocoon happens to implements, then EvilCocoonCorp can no longer distribute Cocoon's code! It's not a solution to the software patent problem, but given the wild availability of our software, it creates a pretty complicated deadlock scheme (because the counter-lawsuits for illegal AL2.0 distribution would rain like in a tropical forest!) There is nothing like that in the GPLv2. Mixing the two and undergoing an IP lawsuit is going to create all sort of issues, because nowhere in the GPL there is something that says that parts of it are allowed to be licensed under some other license with more strict terms, therefore EvilCocoonCorp could claim that the GPL *shielded* them against that ASF patent bomb. It's a mess, I know, but it's better be safe than sorry in these matters (even if Europe is, so far, a place where the IP problem doesn't count that much so it's a much safer bet) -- Stefano.
Re: (Re)Licensing question
hepabolu wrote: Pier Fumagalli wrote: In the second, those changes will be in the hands of the distributor (and thus GPLed). There are two options, either the copyright of those changes is transfered to the ASF by the distributor (and then we'll follows what's described above) or they'll have to maintain those patches themselves as we're not going to include GPL licensed code in our repository... So this means it could become a Cocoon fork and there's nothing we can do about it? We can't take code that we don't own and that is licensed by some other license and relicense it under different terms. But the apache license states that *if* you contribute anything back, then this would be apache licensed if you don't say anything else. But this has very little to do with the license incompatibility problem. I hope this clears it a little bit... a bit yes. ;-) Bye, Helma -- Stefano.
Re: XTech 2006 Amsterdam, May 16-19th
Daniel Fagerstrom wrote: Stefano Mazzocchi wrote: Arje Cahn wrote: FYI, I'm on the technical review board of that conference. Will you attend too? Don't know, probably not, but I'll have to be in Sweden the week after that to given a keynote speech, so I might be able to stop by ;-) What conference are you giving your keynote speach in? Last year it was called Nordic Sofware Developer Summit 2005 - NorDev 2005, so I suspect it's going to NorDev 2006 this year. -- Stefano.
Re: XTech 2006 Amsterdam, May 16-19th
Arje Cahn wrote: Hi there, XTech 2006 (former XMLEurope) will be held in Amsterdam 16-19 May. They have the option to request a (free?) room for related events - hackton and the likes. Any interest? I could arrange something.. FYI, I'm on the technical review board of that conference. -- Stefano.
Re: XTech 2006 Amsterdam, May 16-19th
Arje Cahn wrote: FYI, I'm on the technical review board of that conference. Will you attend too? Don't know, probably not, but I'll have to be in Sweden the week after that to given a keynote speech, so I might be able to stop by ;-) -- Stefano.
Re: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
Vadim Gritsenko wrote: On Dec 23, 2005, at 9:13 AM, hepabolu wrote: Nathaniel Alfred wrote: Please cast your votes! +1 And here's mine: +1 late, +1 late as well, +1 -- Stefano.
Re: svn commit: r358933 - in /cocoon/trunk: ./ legal/ tools/jetty/ tools/jetty/conf/ tools/jetty/lib/
Giacomo Pati wrote: (I was questioning myself which ideas it was to write such a Loader as the one from jetty look so similar to the one we have). Ehm, well, I think it's simply because I wrote that Loader before they did :-) -- Stefano.
Re: [RF] Chainsaws and Seeds
Mark Lowe wrote: Nice charts.. They assume that the same folk that are there at the start of the start line are the same folk that are end or even perhaps middle. Despite having a lot of respect for stefano's achievements and the contribution that cocoon has made, I think the graphs are wrong, or at least fail to account for iterations of staff turnover. Hmmm, this is a very valid point, I'll have to think about it some more. Hmm... -- Stefano.
Re: [RT] Ditching the environment abstraction
Daniel Fagerstrom wrote: It seem like we all agree about that the Cocoon core need to be simplified, although we have different opinions about how to achieve it. IMO it can be done in steps by refactoring of the trunk. One of the complications with Cocoon is the environment abstraction: o.a.c.environment.Request, Response, Context etc. They are similar but not identical to the javax.servlet and javax.servlet.http interfaces, which means yet another thing to learn for the user. It also means that it becomes more complicated to use externally developed components, as these typically implement the servlet family of interfaces. Furthermore it leads to a more complicated setup process of Cocoon. So, do we need this extra layer of abstraction? It made sense when Cocoon was mainly a publication framework, for publication the servlet family of interfaces has a lot of functionlity that is irrelevant. But now when Cocoon has developed to a webapp framework, it makes much less sense to have an own abstraction of what already has a standardized abstraction. o.a.c.e.Request has expanded so that it is close to identical to HttpRequest. For o.a.c.e.Response and Context there are larger differences to their servlet counterparts, they are subsets. But what is not implemented either could be implemented or just throw an not implemented exception. Another reason for having an own abstraction was to be able to use Cocoon in none servlet environments. This has not happened to any large extent, in addition to the Http environment, we have CLI, Faces and Portal environment. For the Http, Faces and Portal environment, using the servlet interfaces should be a simpilification and improvement. For CLI, I dont see that it would complicate anything either. The main problem with swithing to the servlet interfaces AFAICS, except for that it takes some work, is back incompability. This could be solved to some extent by letting our abstactions extend the servlet interfaces. Nearly all methods have the same names and types. But IMO it would be better to simplify Cocoon and take the back incompability now and just remove our own abstraction, we could have some adapter utilities in some compability block. So in a first step I would like to switch our environment abstraction to their servlet correspondances. In an next step I think we should use Servlet instead of processor for our controllers: Cocoon, Sitemap, Flow and possibly the Pipeline. This would make it simpler to reuse Cocoon functionality, and also to experiment with new kinds of controllers. As discussed before the Processor interface contains a far to much implementation details that are connected to sitemap engine internals for beeing suitable as a general controller interface within Cocoon. I'm considering to reimplement the two controllers in the blocks architecture: the BlocksManager and the BlockManager, as servlets, and thus get rid of a lot of start up complications. Also it would make it possible to let a block contain any servlet with a set of components, instead of hardwiring it to the sitemap controller. WDYT? The real reason why we wanted to keep the environment pluggable was that we envisioned cocoon as a Mailet as well. Needless to say, this never happened. So, yes, I'd be very happy to get rid of yet-another-servlet-API and simplify things. -- Stefano.
Re: [RF] Chainsaws and Seeds
Niclas Hedhman wrote: On Friday 09 December 2005 02:21, Stefano Mazzocchi wrote: And in terms of moving the equi-cost point to the left, there are two fundmentally different variables to consider. for instance, if t y = a * b / x ` \/ total cost of ownership (y) ^ | o |o | | o | |o v | o \ 2. | o\ |o 1. +-- complexity (x) 1. Essential focus on lessening the threshold, i.e. lower a. 2. Increasing the power of the functionality that are required for really complex systems, i.e. increasing the root base. Often, these are also interlinked, and it is important that the lowering of a doesn't make ( b 1 )... I think everyone are at this point focusing on 1. The market talks about quick starters and Cocoon peeps wants to me too in that area. I don't give a flying fart about RubyOnRail as my gut says that it doesn't make it easier to become the next Rembrandt, only providing me with more cryons than the other kids. Good one :-) I think Stefano's RF is great. Thanks. He challenges people's presence and motivations. If you want to do weblog apps - GO. If you want to DB record viewer app - GO. If you want JAWA (Just Another Web Application) - GO. GO - because there are 50 other frameworks out there, all of them with their strengths, weaknesses and hype. I am sure there is some that suits YOU, as well as me. JAWA is not why I keep my interest... The reason to stay, is not to compete with Struts, Tapestry, Wicket, RoR, PHP and every other JAWA framework out there. The orthogonality of Cocoon has died. Noone talks about views. Noone highlights the ability to serve same content to many user agents. Noone is interested in truly useful smaller components. Noone cares about the developer vs designer vs deployer roles. Hmmm, interesting, didn't see it this way. I wonder if it's because the real life forces those role to hybridize over and over, if we didn't make the right choice in separating them or because really nobody cares. If nobody really cares, then I wonder what in hell are we still thinking in terms of SoC! I am predicting that the next round of waves will not be around delivering HTML or XML to web browsers, AJAX or not. It will center around dedicated clients. And not _any_ client - but the Mobile clients. I very strongly disagree. Mobiles are getting richer and richer, and the HTML browser software is becoming more and more commoditized. It might be easier for everybody to deliver XHTML with Ajax-retrieved CSS and content than to do it the other way around. But the important point is not that you can do it, it's all those borderline cases where you *can'* and, therefore, your complexity starts to increase dramatically. Cocoon will help moving stuff back to the server with very reasonable costs and move stuff from the server to the client gradually. *that* is, IMO, the real need: a web framework that is powerful and flexible, yet easy to use, that allows to position your web application on all possible shades between a controller that stays most on the client or most on the server, with the ability to fine-tune that over time with as much ease. And this is a lot more interesting to Cocoon than one first realizes. 1. Cocoon is already equipped to serve mobile clients, both WML and binary formats. No change required. Sure, but that's really not that hard to achieve. 2. The most important aspect is the ability to generate media for different device models. No change required. Pipelines are first class citizens in Cocoon land, but you are talking to one use of it, one that makes you happy. I'm happy if that happens, but there are others. The important part is to keep the pipeline machinery as first class, yet make it easier to use even in other usecases. See Sylvain's proposal for dynamic and scripted pipelines. 3. Americans have no clue about what is about to happen. Europeans are better prepared, and Cocoon is apparently a very European project. That's complete bullshit. It is true that multi-modal appeal appears more in Europe than in the US, but as I said about, you might find that the complexity of multi-modality brings uniformity to the client (as it happens on the web) instead of bringing more complexity in the server side rendering engines, especially now that Mozilla Minimo and stuff like that are emerging and that mobiles (in order to run powerful games) will have more and more RAM and bigger screens. So, all of you who wants JAWA, Cocoon may not be the best tool. I don't think we should even try to become the best. Cocoon is already great in many aspects. We should concentrate on this, and become the defacto standard for mobile backends. I personally don't give a rat's ass
[RF] Chainsaws and Seeds
Prologue I've followed the results of my shaking the tree last month with a mix of worry, amusement, anger, hope and despair, not necessarily in this order. RF stands for random feelings. The web is undergoing a phase transition, from a web of pages to a web of data and services. Those who think ajax and ruby on rails complete such phase transition will hit a wall so tall and thick they will have to reconsider even their names. As the cocoon is obsolete thread showed, the need for a web server framework is not gone, it's just changed. Forces are moving the tectonic plates of the various technologies (and the socio-economies around it) and companies like Google and Yahoo! inject water into the faults, and they don't care if the various earthquakes destroy things around them. At the end of the day, the server side has a unique feature, is more centralized than the client side. Even a massive clusters like Google or Yahoo! work because the uniformity of their infrastructure is incredibly high. By moving code on the client side, you enter an ecosystem with an increasing (and unlikely decreasing from now on) variety. This will increase complexity. One of the places where Cocoon proved to be incredibly successful was the multi-modal market, where the different modes turned out to be tens of not hundreds (here I'm talking about the mobile portal world and the machine2machine world). As much as cocoon is not obsolete, the web 1.0 is not obsolete, because web 2.0 doesn't exist! it's a marketing meme, it's nothing but a step in the direction of a vision of a web of data and services, some of which contains graphical information (therefore is suitable for screen/audio/3d rendering) some doesn't. Some services simply retrieve statically, some other perform complex tasks. Some services don't need activation semantics, some others do. As much I always thought that web services always existed (in fact, one of the first web service integrators was built with cocoon! even before SOAP came along!), this web 2.0 always existed, including all those fancy DHTML things. I've seen a web site that used flash with interactive XML upload/download powered by Cocoon years ago. It was uber-cool graphically, it was also a nightmare to maintain, didn't play well with search engines, didn't perform well in usability tests and so on. As we know very well, bleeding edges have a price: we bet on XML as the data syntax of the web and, guess what?, it happened. Moving forward -- This project became successful and the people around it with it. We got jobs, projects, customers, deadlines. We were on a path and we kept going. Things were patched and hacked to make it work, complexity grew and our component model made it so easy to add things that we forgot when it really made sense and when it didn't. I also lost interest in it. I saw it finished. Uninteresting from a research point of view, so I moved on. Recently, I started designing a new web application/publishing framework for RDF and guess what? I kept coming back wanting cocoon features or things that we implemented or designed or planned, even things I had been against for years. One for all, I love the sitemap and I love pipelines. I love the lego feeling and the 80/20 paradigm: you get 80% from pre-built (and community polished!!!) components and 20% from your own programming glue. The cost of maintenance of your webapp is now 70% less! (20% on your stuff, 10% community tax). Much better than 100%. I also love the RAD features of avoiding to compile stuff. But I also love that eclipse is my syntax co-pilot. I like the concept of continuations although I ended up using it when it was not really necessary and in situations where the parties that participate to the web service are more than two, saving that much state without the ability to move it across servers will hurt more than help. Technically, I think Sylvain hit the nail on the head, even if I personally believe that, no matter what, we'll need a real block system, even if we implement everything he said. Cocoon's biggest pain is deployment/build system. I'm with Daniel that solving that would make a lot of issues go away. But I also agree with others when they say that having a naked core that needs 12Mb of jars is a little off beat. The baby and the bath water --- Cocoon is big and complex. In some parts over-designed, in others over-configurable, but if you want to aim at replacing Struts or PHP or RoR for web sites that are small in complexity and in the number of people that work on it, forget it, you are barking at the wrong tree. Leave, go away, get lost, ciao ciao, au revoir, this is not the place for you. Cocoon is a framework that enables Separation of Concerns. It makes sense *only* when the sites are complex and diversified (or if you know it already, so the learning
Re: [RT][long] Cocoon 3.0: the necessary mutation
Luca Morandini wrote: Stefano Mazzocchi wrote: Luca Morandini wrote: Nevertheless, it is easier to build a tool around a declarative language expressed as XML, than a procedural language expressed as... a procedural programming language. I'm sorry, Luca, but I think that's BS. cut/ For example, do you think that if the java classes were expressed as XML statements that *declarative* describe their methods and variables and inner classes it would be easier to write a tool like Eclipse? That I don't know, I've never seen the inner workings of Eclipse. Let's just say that when something is written in XML (say, an UML model expressed as XMI) I can fire up Xalan and beat the beast into submission easily, if the same mopel was expressed as a set of Java classes... hmmm... time for man yacc ? Maybe it's just that I've worked with XML for too long, but I still like the easy production/validation/transformation of vocabularies that comes with it, and I'm scared a bit by the other approach. Which is fair, but this is due to your experience and knowledge. It's fair and nice that you say that it's easier for *you* to write some code using XML technologies instead of using javacc or yacc or bison or whatever else, but using this is an absolute argument is utterly misleading and one of the sins that, myself included, we, as a community made over the years. -- Stefano.
Re: [RT][long] Cocoon 3.0: the necessary mutation
Sylvain Wallez wrote: [snip] Tell me your thoughts. Am I completely off-track, or do you also want to build this great new thing? Well, I've always been against dynamic pipelines and content-aware selection. But yes, I've changed my mind. scripted sitemap, pull-driven events, dynamic pipelines, yes, it's time for those. Not sure I understand what you mean by flow.sendMultiple() though. can you explain in more detail what you mean there? -- Stefano.
Re: [IMP] End of code freeze
Sylvain Wallez wrote: Carsten Ziegeler wrote: The 2.1.8 release is built and currently uploading. So this is the end of the code freeze. Yeah! Finally! Thanks Carsten! awesome job guys... now let's try to move a little bit faster for the next releases ok? ;-) -- Stefano.
Re: a new cocoon logo?
Torsten Curdt wrote: I agree that the Cocoon website needs a redesign. However, a redesign with the same old content doesn't really makes sense and could do more harm than good. But with the cool new documentation that is coming, we definitely have to change the skin of our website to clearly show people that something new is there. About the logo, however, I really prefer the current one, which is way more readable and is also well-known. +1 to all :) +1 to new skin but only with new content. -1 to the logo, no reason to change a widely recognized one with a new one just for sake of change. -- Stefano.
Re: a new cocoon logo?
Jorg Heymans wrote: Agreed, but a new logo when we release 2.2 or 3.0 would be highly desirable from a marketing point of view. The current one is starting to show its age IMO. Call me old fart, but I'm *strongly* -1 about a logo change. -- Stefano.
Re: Docs now use Daisy-wiki defined URLspace
Ross Gardler wrote: Ross Gardler wrote: Ross Gardler wrote: Ross Gardler wrote: Please check them out, make sure I've not missed anything as I've not been able to get more than about 15 minutes at a time to focus on this so I may well have missed things. The entry URL has obviously changed as well: http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/ The last build seems to have worked OK. No reported broken links and images seem to be appearing. Please test and report any issues. applause/ Can wait until we have it running for our official web site. On a side note, and only marginally related to this work, I find the table of content box in every page to be pretty much useless and annoying. Am I the only one? Could we move it over to the navigation tree instead? (where it belongs?) I've designed this skin many years ago and it's starting to show its age or maybe I am :-) Anyway, those are details, great job anyway. -- Stefano.
Re: Docs now use Daisy-wiki defined URLspace
hepabolu wrote: Ross Gardler wrote: applause/ +1 With respect to skins and themes, wait until you see the new replacement for the skinning system - it's awesome in its configurability and flexibility (and no, I didn't write it ;-) Ross I agree, the TOC could go, either to the menu bar or removed altogether. Ross, I've probably made a mistake in the CSS I sent (wrong class/id I suppose), but the box around the selected menu item is still there. Could you please remove it, it doesn't look good. Maybe changing the font of the selected item to bold white would make it stand out enough. Could you fix it please? On my brand new Powerbook, the background color of the Apache Cocoon logo (left with feather) has a different shade of blue as background, while I can't remember having seen that on my Windows machine. AFAICT colors are identical. Anyone else seeing this? yup. the background should be transparent, not colored. -- Stefano.
Re: Docs now use Daisy-wiki defined URLspace
Ross Gardler wrote: Pier Fumagalli wrote: On 29 Oct 2005, at 17:18, hepabolu wrote: On my brand new Powerbook, the background color of the Apache Cocoon logo (left with feather) has a different shade of blue as background, while I can't remember having seen that on my Windows machine. AFAICT colors are identical. Anyone else seeing this? Yes... I'm seeing it, but I think it's because of the color management done on the Mac... I'm no graphics person, can anyone create a version with a transparent background? http://svn.apache.org/repos/asf/cocoon/whiteboard/daisy-to-docs/src/documentation/content/xdocs/images/cocoon-logo.gif http://svn.apache.org/repos/asf/cocoon/trunk/misc/graphics/cocoon2-naked.gif enjoy wow, I'm committing something on cocoon after years :-) -- Stefano.
Re: [RT] Making the buzz
Sylvain Wallez wrote: Hi all, As you certainly know, Ajax and RAD/scripted frameworks are hot lately. I'm closely following http://www.ajaxian.com/, a blog about all things Ajax. Recently they started talking about continuations [1] and [2], even mentioning our Rhino fork, but without mentioning Cocoon. I think that, along with pinging the Ajaxian guys (which I will do), we should rewrite our home page to make more apparent Cocoon's unique abilities in the changing world of webapp development. A distinguishing feature IMO is that the Cocoon platform sits inbetween hardcore J2EE and scripted frameworks: - it is based on Java and thus has access to everything that's available in Java (huge amount of libraries, enterprise-class systems such as workflow engines, transaction manager, etc) - it is highly scripted, allowing rapid application prototyping and development, - our script language (contrarily to RoR) is JavaScript, which is widespread and gaining a lot of interest because of Ajax, - it doesn't lock development in scripting: prototype quickly with JS, then, if needed, translate to faster but more verbose Java. Add a few cool Ajax demos to the mix and this makes Cocoon a sexy and modern development platform. WDYT? +1 but keep the silly web 2.0 buzz low. The world will get sick of ajax as soon as everybody understands that it's refreshing but really nothing new. Cocoon uses technologies because they are useful, not because they are 'cool'... the danger of overhyping is that you go up very fast with the hype and you go down as fast. -- Stefano.
Re: [RT] Is Cocoon Obsolete?
Peter, thanks so much for this, great plug for me to start. Peter Hunsberger wrote: On 9/30/05, Stefano Mazzocchi [EMAIL PROTECTED] wrote: There was a moment where I could have been one of the first people to respond to this thread, you just happened to ask this question when I was watching the Cocoon mailing list for some reason or other. However, in spite of the fact I've been debating whether we could run our software without Cocoon for the last 6 months or so I honestly didn't know how to answer your central issue: what's next? I've got a gut feeling for what we need, some of it resonates with what you post here, but I've personally grown sort of attached to Cocoon, so first off, I'd have to answer the subject line with a resounding no. :-) Well, I never really expected people on this list to say yeah, it's crap, I moved on because those who did, would not be here to read that message anyway. The real question is: does the cocoon community realize that the tectonic plates of web technologies are shifting and that we might find ourselves in a completely new environment really soon? And if so, do we understand it? do we defend our positions or we attack? Read my comments below. snip/ I do that for my latest web sites and the more I learn how to driven the client, the less I feel the need for advanced server frameworks. Is it just me? Define advanced? For the foreseeable future we need: 1) low cost, robust, legacy system interfaces (canonical form is cheap, distributed clients don't lend themselves to canonical form); 2) high speed, 100% dependable, atomic, global, data transaction management through to the persistence layer (clients != dependable); 3) back end security (in addition to client authentication). I'm sure there are others, but no, I still think we need good solid server side capabilities. One thing that turns me off about cocoon *today* is the pretty steep *perceived* learning curve. If packaged correctly, a naked (no blocks!) cocoon would take no more than an improved Bertrand's SuperSonic Tour. We are getting there. Slowly, painfully, and dragging our userbase with us without abrupt transitions... maybe too slow, I don't know. But I knok that revolutions are hard to manage, so I'm not unhappy about the way we are dealing with day to day evolution. But I think we collective lack a vision for what's coming up next and I feel this as a weakness. Perhaps it's just that you started out mostly server side and now you're discovering that the client is fun? (And that advanced clients are even more fun.) I did that with Linotype... which had more code in javascript than in XSLT... and it felt like a good thing(tm). Between Moz and Cocoon, both have similar problems, good visions and architecturs, but they are hard to explain because novices don't hit those walls until really late in the game. The climb is very steep but the plateau up there very flat and very high. We need to build a way to get people up there quick. Ruby on Rails wrote wizards, we have eclipse plugins (sort-a). We need to do more in that space and we are. It's great. But both moz and cocoon face a similar problem: how are they going to face a future of radical changes around them? The web ecosystem is very solid and inertial, yet completely non-linear, things like del.icio.us are small butterflies that trigger hurricanes somewhere else. Is there anything we can do to watch what's happening and draw conclusions on what we need to prepare for? or enable? or avoid? or deprecate? or influence? or push? or polish? or remove? We are moving forward in many directions: 1) real blocks 2) build system 3) binary distributions 4) CMS for docs 5) IDE (with Lepido) 6) rail-ification and wizards 7) solidification 8) separation and identification of current and legacy features which are all great, but is that enough? snip/ But as a researcher, a scientist and one that likes to push the edge, I sense that cocoon is kinda 'done', not as in finished, passe', but more as in been there, done that. Sure, that makes sense. But, give it a couple of years: there are many fundamental capability enabling patterns embodied in Cocoon (whew): - ack-nak/controller-response - translation/transformation - iterative processing of small increments of work (the true separation of concerns) none of these are going to go away. In 10 or so years you'll be wondering did I really understand what I was doing and/or thinking h*ly shit that's col This is correct. Cocoon should never be done. IMO, the two big problems of generalized graph traversal and graph merge/update will always require some capability to handle orthogonal concerns at run time because pure REST can't map the entire universe. There are always ambiguities remaining to be discovered that can't be named/identified (pick concept de-jure) before hand. Here we go, closing in... I want to processes
Re: forrest config for exporting daisy docs
Upayavira wrote: Stefano Mazzocchi wrote: Ross Gardler wrote: I've just added the Forrest configuration to the whiteboard as daisy-to-docs. I'll now update our forestbot to retrieve it from the Cocoon repo instead of the Forrest one. This way if any changes are made here to the skin, for example, they will be refelected in the next forrest bot build. The forrestbot builds every 3 hours at present. Nags about broken links are currently sent to David and I, does anyone else wnat them? At present it means one every three hours as there are broken links, so I don't really want to send them to the list yet. I'll do that when it works for the first time. You can see the latest build at [1] (will move to [4] on the next build) and the list of broken links are at [2] (will move to [5] on the next build) If you ever forget the urls they are linked from the forrest zone home page [3] Ross [1] http://forrest.zones.apache.org/ft/build/cocoon-docs/653.daisy.html [2] http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml [3] http://forrest.zones.apache.org/ [4] [1] http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/653.daisy.html [5] http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/broken-links.xml Ross, outstanding job. A question: I think it would be just awesome if we could have a link from the published pages back to the daisy page that is responsible for editing that content. An edit this page link would make is *sooo* much better to tie the whole system together and shouldn't be that hard. With one of those 'don't crawl me' request parameters, I assume? And a robots.txt on Daisy. We don't want our daisy content crawled by search engines, do we? why not? showing a login page to a search engine is not going to make that big of a difference -- Stefano.
Re: forrest config for exporting daisy docs
Ross Gardler wrote: I've just added the Forrest configuration to the whiteboard as daisy-to-docs. I'll now update our forestbot to retrieve it from the Cocoon repo instead of the Forrest one. This way if any changes are made here to the skin, for example, they will be refelected in the next forrest bot build. The forrestbot builds every 3 hours at present. Nags about broken links are currently sent to David and I, does anyone else wnat them? At present it means one every three hours as there are broken links, so I don't really want to send them to the list yet. I'll do that when it works for the first time. You can see the latest build at [1] (will move to [4] on the next build) and the list of broken links are at [2] (will move to [5] on the next build) If you ever forget the urls they are linked from the forrest zone home page [3] Ross [1] http://forrest.zones.apache.org/ft/build/cocoon-docs/653.daisy.html [2] http://forrest.zones.apache.org/ft/build/cocoon-docs/broken-links.xml [3] http://forrest.zones.apache.org/ [4] [1] http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/653.daisy.html [5] http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/broken-links.xml Ross, outstanding job. A question: I think it would be just awesome if we could have a link from the published pages back to the daisy page that is responsible for editing that content. An edit this page link would make is *sooo* much better to tie the whole system together and shouldn't be that hard. Thoughts? -- Stefano.
Re: Upgrading Daisy on cocoon.zones.apache.org
Bruno Dumon wrote: OK, done. If you used the Daisy editor recently ( 5 hours), old resources might be cached in your browser, in which case it is best to clear your browser's cache. BTW, this Daisy runs on a Cocoon 2.1.8-dev snapshot from this afternoon. Thanks Bruno! -- Stefano.
Re: svn commit: r312664 - in /cocoon/blocks/portal/trunk/java/org/apache/cocoon/portal/event: ./ aspect/ aspect/impl/ impl/ subscriber/impl/
Carsten Ziegeler wrote: Sylvain Wallez wrote: Isn't 1999-2005 enough? Well, actually yes, and to be honest 1999 is wrong anyway as the code has been written later...but I don't want to touch the old values, I'm just adding the year of the latest change (which is actually not really required). Most of our copyright definitions are totally wrong, as mostly they were just copy/pasted from some other source :( We are going to get rid of copyright definitions anyway, since the ASF does not, in fact, own that copyright, but it remains ownership of the people that wrote it. The ASF owns a license to it. My suggestion, don't spend time on this, as the board will resolve the issue soon and invoke a directive for all the projects to follow (hopefully with some source code cleanup scripts to enable it) -- Stefano.
Re: [Vote] Doc format for release
Upayavira wrote: Pier Fumagalli wrote: On 17 Oct 2005, at 10:52, Carsten Ziegeler wrote: 1) a PDF of the whole doc 2) a set of HTML files 3) Both 2 or 3... Not everywhere there are nice PDF browsers available... 2. HTML Files. PDF can go on website. Otherwise it adds 5Mb to the download, and surely we want to be reducing not increasing? +1 -- Stefano.
Re: Public/Private classification (was Re: javadocs navigation)
Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
Reinhard, how many cocoon users have ever implemented
org.apache.cocoon.xml.XMLPipe?
All users who implemented at least one Transformer.
public interface Transformer extends XMLPipe, SitemapModelComponent {
}
If you are implementing transformer for a first time, you have to have
javadocs (or source code (or IDE with reflection)) to implement it.
I don't think you guys understand what I'm saying.
For each user that needs to write a transformer, there are 20 users that
don't, but if they go all to the same place, only the user that is able
to write transformers will stick around.
which is *exactly* what's happening.
So, we can keep the same attitude, or change it.
I'm for changing it.
--
Stefano.
Re: Public/Private classification (was Re: javadocs navigation)
Reinhard Poetz wrote: Stefano Mazzocchi wrote: Reinhard Poetz wrote: Stefano Mazzocchi wrote: Daniel Fagerstrom wrote: [...] Daniel, let me repeat: I don't care about precision and elegance and completeness, I care about usability. I am thinking at flow users that want to use java components to do their stuff. They should *NOT* care about org.apache.cocoon.xml.XMLPipe. Not all Cocoon users are flow users only ... Reinhard, how many cocoon users have ever implemented org.apache.cocoon.xml.XMLPipe? My point is not about flow, is about brevity over completeness. Stefano, TBH I have no strong opinion whether XMLPipe should be part of the public _documentation_. Of course it is part of the _public API_ because otherwise you're not able to implement e.g. a transformer, but I'm sure that you know this as you're the author of this interface ;-) I only doubt that the proposed way of how to find the classes and interfaces, that should become part of the public documentation, will lead to success. Do you guys really think that many people will start to evaluate ~670 classes and interfaces? And if yes, Daniel, Vadim you and me can't agree whether the interface XMLPipe is public or not. So I'm not really optimistice about the outcome as we have to discuss the other 669 classes and interfaces too. I'm just with Daniel that we should talk about the principles of what is public and private first. After agreeing on them one person can move the public interfaces and classes into a seperate directoy and then we can create a cocoon-api.jar and can create javadocs out of it. If you or others think that the wiki way of tagging classes is more successful (and faster), please go for it. Believe me, it's not my intention to block this, especially as I don't have the time to work on the alternative within the next 3-4 weeks. Boy, this is getting frustrating. I don't give a proverbial f*k on how we do it the fact is that there are many levels of public API and we are not acknoledging that, nowhere something like this can be found. In the past, we wanted FOM to be the only interface between flowscript and the rest of the system but given how many services are embedded in components and how many things were never added to FOM but just expected to be discovered out of getComponent(), which means that you need to know the entire cocoon internals to be able to write a simple flowscript, which is totally ridiculous. You want principles? here they are: 1) script-oriented people, those who don't know java and don't care, those looking for RAD, those coming from the client or from the XML world, should have a reduced API which includes FOM + useful components + environment API and no cocoon internals. 2) for power users, willing to extend cocoon, the cocoon internal APIs (pipelines, caching, input modules, etc..) 3) for cocoon devepers, everything but at least packaged by block. This is what I want. I don't care if we do it by hand or we do it by javadoc or by other means. I don't care if we use wikis or post-its to find out which interface goes in which category(s), or if we use tags or even if we use embedded RDF in the javadoc comments for it. All I want is to help our users stick around... because honestly, I find myself in the very uncomfortable position of suggesting people *NOT*TO* use cocoon, because is such a horrible climb to get to that comfortable plateau of productivity and this is honestly not acceptable today. -- Stefano.
Re: Public/Private classification (was Re: javadocs navigation)
Reinhard Poetz wrote: Stefano Mazzocchi wrote: Daniel Fagerstrom wrote: [...] Daniel, let me repeat: I don't care about precision and elegance and completeness, I care about usability. I am thinking at flow users that want to use java components to do their stuff. They should *NOT* care about org.apache.cocoon.xml.XMLPipe. Not all Cocoon users are flow users only ... Reinhard, how many cocoon users have ever implemented org.apache.cocoon.xml.XMLPipe? My point is not about flow, is about brevity over completeness. -- Stefano.
Re: [EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
Gump wrote: compile-core: [mkdir] Created dir: /x1/gump/public/workspace/cocoon/build/cocoon-12102005/classes [copy] Copying 21 files to /x1/gump/public/workspace/cocoon/build/cocoon-12102005/classes [copy] Copied 75 empty directories to 43 empty directories under /x1/gump/public/workspace/cocoon/build/cocoon-12102005/classes [cocoon.javac] Compiling 680 source files to /x1/gump/public/workspace/cocoon/build/cocoon-12102005/classes [cocoon.javac] /x1/gump/public/workspace/cocoon/src/java/org/apache/cocoon/components/ChainedConfiguration.java:256: cannot resolve symbol [cocoon.javac] symbol : method getAttributeAsDouble (java.lang.String,double) [cocoon.javac] location: interface org.apache.avalon.framework.configuration.Configuration [cocoon.javac] return this.wrappedConfiguration.getAttributeAsDouble(arg0, arg1); [cocoon.javac]^ [cocoon.javac] /x1/gump/public/workspace/cocoon/src/java/org/apache/cocoon/components/ChainedConfiguration.java:263: cannot resolve symbol [cocoon.javac] symbol : method getAttributeAsDouble (java.lang.String) [cocoon.javac] location: interface org.apache.avalon.framework.configuration.Configuration [cocoon.javac] return this.wrappedConfiguration.getAttributeAsDouble(arg0); [cocoon.javac]^ [cocoon.javac] /x1/gump/public/workspace/cocoon/src/java/org/apache/cocoon/components/ChainedConfiguration.java:270: cannot resolve symbol [cocoon.javac] symbol : method getValueAsDouble () [cocoon.javac] location: interface org.apache.avalon.framework.configuration.Configuration [cocoon.javac] return this.wrappedConfiguration.getValueAsDouble(); [cocoon.javac]^ [cocoon.javac] /x1/gump/public/workspace/cocoon/src/java/org/apache/cocoon/components/ChainedConfiguration.java:277: cannot resolve symbol [cocoon.javac] symbol : method getValueAsDouble (double) [cocoon.javac] location: interface org.apache.avalon.framework.configuration.Configuration [cocoon.javac] return this.wrappedConfiguration.getValueAsDouble(arg0); [cocoon.javac]^ [cocoon.javac] 4 errors wo wo wo, what the hell is going on here? is somebody modifying avalon? -- Stefano.
Re: Public/Private classification (was Re: javadocs navigation)
Daniel Fagerstrom wrote: Upayavira wrote: So, I have created a wiki page: http://wiki.apache.org/cocoon/PublicAPIClasses Please go there and mark classes public/private as necessary. As it says at the top of that page, if you disagree with someone, change it to dispute or D for short. Then it becomes an opportunity for some healthy argument! Wow! that's a lot of classes. While I aplaud the initiative, 673 classes are huge amount to classify. I would suggest that we start discussing principles first a bit. Here's my principle: since I write all my business logic in flow, I want to know which ones are the things that I can expect to call from flow. Documenting FOM is one thing, but then we have a bunch of other things (like SourceUtil and excalibur resolver etc) that I use all the time. So, my rationale is not to document XMLPipe (since I'll never use it or implement it in flow) but to have an idea, from the cocoon user point of view, of where are the hooks. So, there are 4 levels: 1) FOM (the javascript objects available to flow) 2) the static java utils + avalon components 3) the cocoon interfaces 4) the cocoon classes we document #1 (badly, if you ask me, it's a pain to find) and the rest is one huge bundled javadoc and our class classification by package does *NOT* induce itself to the classification above (maybe #3 and #4, given that we use impl to indicate what implements an interface, and we use .components even if not all of those are meant to be used in flow) If we want to appeal to the users, we need to tell them loud and clear what are the hooks they can use. Otherwise, it feels like flying without a net. Some people here want to move to javaflow to have eclipse do the work for them, I think we have to do something anyway. -- Stefano.
Re: [docs] test publish from daisy
hepabolu wrote: Ross Gardler wrote: However, as Vadim said (in another mail in this thread) we have to be careful not to break current links and search engine indexing. This can be done by forcing the rewriting of links to mirror the existing structure, but that assumes the existing structure is good. I don't think it is, some of the stuff in user docs, for example, is valuable to developers and vice versa. An alternative would be to create a set of rewrites to maintain the existing links. Both opinions are valid IMO: we need fixed URLs so we can point to them, but the current structure is also not very good/rather outdated. My proposal is: keep the current docs, aka legacydocs in Daisy, as much backward compatible as possible. This will be all the Cocoon 2.1.X documentation we have. Once we start releasing Cocoon 2.2 the 2.1 docs will be frozen, i.e. the current state of cocoon.apache.org is archived (available but not in the loop for automatic updates like 2.0) and all documentation effort will be geared towards 2.2. If this means all links are numerical, so be it, as long as the same number keeps pointing to the same page over time. WDYT? Is there a way to have non-numerical URL in daisy? -- Stefano.
Re: Public/Private classification
Vadim Gritsenko wrote: Reinhard Poetz wrote: --- Daniel Fagerstrom [EMAIL PROTECTED] schrieb: IMO we need to find two set of interfaces/classes: the API of Cocoon, and the set of classes (components) that an application programmer need JavaDoc for. If it ain't public API you ain't need Javadoc for it, period. WDYT? I agree completly with you! I don't. You both miss the point, which is: It is JFDI effort which should bring in results quickly, namely set of public classes which are agreed by *whole community* to be public, which means *everybody* agrees that these classes and interfaces will be supported and carefully evolved. If you don't agree with public denominator on one of the classes, just mark it D (we are looking for consensus here!) and have a healthy lengthy discussion about it, but please don't block this effort to produce *good-enough* results quickly in the sake of ivory tower of perfect API separation and bundles and what not... So, are you on board? Amen. -- Stefano.
Re: ApplesProcessor - a little crazy idea
Ralph Goers wrote: Vadim Gritsenko wrote: Torsten Curdt wrote: We only need a few more people using it to find the corner cases. Stable API != Stable Implementation. If API is stable, you should start vote on marking javaflow stable. Vadim I second that. We really need to find a better term than stable. Mozilla uses 'frozen'. -- Stefano.
Re: [EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
Vadim Gritsenko wrote: Stefano Mazzocchi wrote: Gump wrote: [cocoon.javac] /x1/gump/public/workspace/cocoon/src/java/org/apache/cocoon/components/ChainedConfiguration.java:277: cannot resolve symbol [cocoon.javac] symbol : method getValueAsDouble (double) [cocoon.javac] location: interface org.apache.avalon.framework.configuration.Configuration [cocoon.javac] return this.wrappedConfiguration.getValueAsDouble(arg0); [cocoon.javac]^ [cocoon.javac] 4 errors wo wo wo, what the hell is going on here? is somebody modifying avalon? There were small additions to the avalon Configuration interface (methods for double values), and now Cocoon is in sync with Avalon framework trunk (before it was not). I think Gump descriptor has to be updated to match this, that is... I see in gump.xml: depend project=avalon-framework-api groupId=avalon-framework artifactId=avalon-framework-api version=4.3/ Shall we just remove version= from there and that is it? In Gump you never know, just try, it won't make it worse, that's for sure ;-) -- Stefano.
Re: Public/Private classification (was Re: javadocs navigation)
Daniel Fagerstrom wrote: Daniel Fagerstrom wrote: ... To illustrate what I meant I tried to follow the dependencies for the sitemap component interfaces. Cocoon API == ... So what is the Cocoon API? All interfaces used in cocoon-core-sitemap.xconf are part of the Cocoon API: Generator, Transformer, Serializer, Reader, Matcher, Selector, Action, ProcessingPipeline. Then the interfaces refered to in the Cocoon API must be part of the API as well by transitive closure. So here we get various exceptions, SitemapModelComponent, XMLPipe, XMLProducer and much more. The ObjectModelHelper with dependencies is also part of the API. Starting with: org.apache.cocoon.acting.Action org.apache.cocoon.generation.Generator org.apache.cocoon.matching.Matcher org.apache.cocoon.reading.Reader org.apache.cocoon.selection.Selector org.apache.cocoon.serialization.Serializer org.apache.cocoon.transformation.Transformer (I removed the ProcessingPipeline as it dependencies seem to explode to all kinds of internal classes, we need to polish that interface if it should be considered public) These interfaces depends on: org.apache.avalon.framework.parameters.Parameters org.apache.cocoon.ProcessingException org.apache.cocoon.environment.Redirector org.apache.cocoon.environment.SourceResolver org.apache.cocoon.sitemap.SitemapModelComponent org.apache.cocoon.sitemap.SitemapOutputComponent org.apache.cocoon.sitemap.PatternException org.apache.cocoon.xml.XMLConsumer org.apache.cocoon.xml.XMLPipe org.apache.cocoon.xml.XMLProducer which depends on (skipping the avalon dependencies) org.apache.avalon.framework.CascadingException org.apache.cocoon.util.location.LocatedException (org.apache.cocoon.util.location.LocatedRuntimeException) org.apache.cocoon.util.location.Location org.apache.cocoon.util.location.MultiLocatable and again org.apache.cocoon.util.location.Locatable org.apache.cocoon.util.location.LocatableException org.apache.cocoon.util.location.LocationImpl org.apache.cocoon.util.location.LocationUtils org.apache.commons.lang.exception.NestableException org.apache.commons.lang.exception.ExceptionUtils === The object model helper must also be considered to be part of the Cocoon API, there we get the dependencies: org.apache.cocoon.environment.ObjectModelHelper -- org.apache.cocoon.environment.Context org.apache.cocoon.environment.Request org.apache.cocoon.environment.Response -- org.apache.cocoon.environment.Cookie org.apache.cocoon.environment.Session === This should be a complete list of the public sitemap component API (I did the dependency analysis semi automatically with http://depfind.sourceforge.net/, so I could have done some mistakes). === A similar list for the public component API, starting from cocoon-core.xconf would also be a good idea. But I would need a better tool than depfind for that excercise, any suggestions? === I'm not suggesting that we can find out the Cocoon API automatically. But given that we want a particular set of interfaces in the public API and JavaDoc, I think it would be rather strange if we didn't made all the o.a.c interfaces and classes that these interfaces depends on also part of the public API. Daniel, let me repeat: I don't care about precision and elegance and completeness, I care about usability. I am thinking at flow users that want to use java components to do their stuff. They should *NOT* care about org.apache.cocoon.xml.XMLPipe. -- Stefano.
Re: Releasing 2.1.8
Leszek Gawron wrote: I do not understand... No plate then ? :) Oh, no, you got it :-) -- Stefano.
Re: javadocs navigation
Bertrand Delacretaz wrote: Le 12 oct. 05, à 05:16, Stefano Mazzocchi a écrit : ...I think a better, leaner, cleaner javadoc would go a *LNG* way to make things easier... I was thinking about that recently - does anyone know a tool for tag-based navigation of javadocs? A better *navigation* of the javadocs, like being able to see all classes which have the sitemap generator tags, would help a lot. All right, here's another thing that could help this project: do it hacky now instead of doing it cool later. I'm partially responsible for leading the community to think that hacks don't work (and they don't, in the long run) but in the short run, something as small as having another javadoc, built with just a subset of the code, would be good enough... We have been working on ways to improve stuff forever, but everytime somebody comes up with an idea, somebody comes up with another idea, more elegant, more general, more scalable and harder to implement... and it creates a stall: either somebody implements the more elegant idea or nothing happens at all. I think this is our single most important problem in helping our users: we care too much about them and we want to give them the best experience we can think of. We need to start caring less about that. -- Stefano.
Re: javadocs navigation
Sylvain Wallez wrote: Bertrand Delacretaz wrote: Le 12 oct. 05, à 05:16, Stefano Mazzocchi a écrit : ...I think a better, leaner, cleaner javadoc would go a *LNG* way to make things easier... I was thinking about that recently - does anyone know a tool for tag-based navigation of javadocs? A better *navigation* of the javadocs, like being able to see all classes which have the sitemap generator tags, would help a lot. Or more simpler, and we already talked about this, what about tagging the source files themselves to be able to produce javadocs of a restricted set of classes, i.e. those that are considered public API and that people can safely rely on. There you go! +1 -- Stefano.
Re: Roadmap for Cocoon Blocks
Daniel Fagerstrom wrote: Pier Fumagalli wrote: On 11 Oct 2005, at 20:16, Bertrand Delacretaz wrote: Le 11 oct. 05, à 07:31, Reinhard Poetz a écrit : ...- Cocoon 2.2 will not use OSGi but will support blocks as far as possible:... ...- Cocoon 3.0 will use OSGi -- shielding classloader and hot plugablillity... ...WDOT? +1 to the plan. Just one small nitpicking comment, we should say 3.0 will *most probably* use OSGI - as you said, it's a nice goal to have but I don't think we're 100% positive on that yet, there are still a few unknowns. I agree wholeheartedly... I am not 100% sure that OSGI is the perfect solution. AFAICS it's a little bit too cumbersome for my brain. And I know a lot of others share my concerns (from discussions at the GT). Pier Any specific concerns about OSGi? For me, licensing. As for technical matters, I stopped caring when we killed Avalon. We can't ship until a OSGi R4 implementation is available, which means probably waiting for Felix to finish the implementation *and* exit incubation. That might take some time. -- Stefano.
Re: Removing author tags (again)
Berin Loritsch wrote: Torsten Curdt wrote: What has stopped us is that we need to keep a track of these to give credit. And also show to the world the incredibly large developer group we are :-) But if you give credit without a connection to parts of the code it's just a list of the committers (more or less) If you *have* a connection people will look people up in there... So either remove them or don't. But giving credit besides the community credits does not make much sense to me. *shrug* You know, I still get people emailing me about some code that I wrote well over two years ago just because my name is in the author tags. Make it 8 years for me ;-) -- Stefano.
Re: Removing author tags (again)
hepabolu wrote: Berin Loritsch wrote: Torsten Curdt wrote: So either remove them or don't. But giving credit besides the community credits does not make much sense to me. *shrug* You know, I still get people emailing me about some code that I wrote well over two years ago just because my name is in the author tags. More importantly: do you like that or do you find that a nuisance? Sorry, thought that was obvious: after 8 years, you don't even remembering writing that code, helping them is obviously out of the picture. But more important, sometimes you remember where you put that code when you coded it, but then that projects dies, gets refactored, and thanks to OSS licenses lives somewhere else. Normally, your code ends up be so different that you can't help them even if you wanted to. Since it's a crime, nobody takes down @author tags meaning that your email address will live forever associated with a piece of code that over time might not even have a single line of your code anymore. @author tags are good for one thing only: massaging the ego of the programmer, here is my contribution and here is how I pay myself back, by placing the @author tag. I know this because this is how I started contributing to open source, I felt great to tell them to grep for my email address inside a piece of code they were using and find the owe in their faces. Now this grep for owe factor, although childlish, is incredibly important and no matter what we do, we must not lose it. The grep for owe factor is only second to the grep | wc -l for owe factor, which means that the more files you touched, the more your name appears. For this project, I had it in the license so my grep | wc -l for owe factor was growing even without me doing anything ;-) Smart ass, aren't I? ;-) Seriously, I think the grep for owe factor should be there for anybody that contributed anything, including companies and including people that donate something that is not code (like documentation or marketing efforts). And I also think that the grep | wc -l for owe factor should be 1 for everybody no matter how big their contribution is, as to avoid racing for it. So, in short, credits.txt is the place and we can reconstruct the chronological order of contributions thru SVN and bugzilla. -- Stefano.
Re: [docs] test publish from daisy
Ross Gardler wrote: Vadim Gritsenko wrote: hepabolu wrote: Ross Gardler wrote: See: http://people.apache.org/~rgardler/cocoon-site/653.daisy.html Correct. It looks much slicker than the official site, although my fingers itch to do something about the navigation (CSS wise). Please do :-) Black border around current page is ... strange. :-), easily fixed. Another problem I noticed - all URLs are number.daisy.html - we can't publish these to official website... Which part(s) are you objecting to? The number is because daisy uses numbers rather than names to identify every page. There are ways around this in either Forrest or Daisy but it is quite a bit of work. Related to this is the hierarchical layour of docs. i.e. there is no directory structure. Again this is a feature of Daisy (one that I have grwon to love). Documents are stored in a flat structure. The illusion of hierarchy is created by the navigation documents. Currently the Forrest plugin does not reproduce this (although it could). I'm hesitant to address these two issues right now since I want to explore using Daisy Books for the published docs navigation systems instead. The daisy.html part is used by Forrest to identify the original source. This is the default behaviour of the plugin (which was developed for a site that integrates content from many different sources). however, it is completely configurable, the URL can be any pattern we want (including plain old id.html) I still think a flat URL space for documents is a good thing(tm). See wikipedia. As for non-numeric, well, I personally like numeric, because otherwise it forces you to have a language identifier (again, see wikipedia) and disambiguation pages, but given that we won't have 300K pages, I do agree that makes the user experience a little more comfortable. -- Stefano.
Re: Roadmap for Cocoon Blocks
Upayavira wrote: Stefano Mazzocchi wrote: Daniel Fagerstrom wrote: Pier Fumagalli wrote: On 11 Oct 2005, at 20:16, Bertrand Delacretaz wrote: Le 11 oct. 05, à 07:31, Reinhard Poetz a écrit : ...- Cocoon 2.2 will not use OSGi but will support blocks as far as possible:... ...- Cocoon 3.0 will use OSGi -- shielding classloader and hot plugablillity... ...WDOT? +1 to the plan. Just one small nitpicking comment, we should say 3.0 will *most probably* use OSGI - as you said, it's a nice goal to have but I don't think we're 100% positive on that yet, there are still a few unknowns. I agree wholeheartedly... I am not 100% sure that OSGI is the perfect solution. AFAICS it's a little bit too cumbersome for my brain. And I know a lot of others share my concerns (from discussions at the GT). Pier Any specific concerns about OSGi? For me, licensing. As for technical matters, I stopped caring when we killed Avalon. We can't ship until a OSGi R4 implementation is available, which means probably waiting for Felix to finish the implementation *and* exit incubation. That might take some time. Or use Eclipse, which is R4 already, and then switch to Felix when it matures sufficiently. Ah! didn't know that. Good, I'm happy then. -- Stefano.
Re: javadocs navigation
Upayavira wrote: Stefano Mazzocchi wrote: Sylvain Wallez wrote: Bertrand Delacretaz wrote: Le 12 oct. 05, à 05:16, Stefano Mazzocchi a écrit : ...I think a better, leaner, cleaner javadoc would go a *LNG* way to make things easier... I was thinking about that recently - does anyone know a tool for tag-based navigation of javadocs? A better *navigation* of the javadocs, like being able to see all classes which have the sitemap generator tags, would help a lot. Or more simpler, and we already talked about this, what about tagging the source files themselves to be able to produce javadocs of a restricted set of classes, i.e. those that are considered public API and that people can safely rely on. There you go! +1 So how do we decide what is internal, what is external? The discussion is likely to be fun. Yeah, well, we are reasonable people ( sometimes ;-) We could have a wiki page containing all classes, and mark the ones on that wiki page that we want to be public. Then a script could add the necessary javadoc markup. If that approach sounds okay, I'd happily volunteer to write the script to add the markup, assuming it is a simple enough markup. Thoughts? Sounds good to me. -- Stefano.
Re: javadocs navigation
Niclas Hedhman wrote: On Wednesday 12 October 2005 23:59, Stefano Mazzocchi wrote: I think this is our single most important problem in helping our users: we care too much about them and we want to give them the best experience we can think of. And ironically giving users a harder time :o) well, not a harder time, but harder than giving them something to start with even if not perfect or elegant or not showing how cool we can do things. Very interesting observation I must say. I will indeed place that on my daily reminder section on the whiteboard. Too good to forget. And can be applied to many facets of life. Oh yes, ask my girlfriend about it: she gets nuts when I try so hard to have a solution for a problem she has and all she is looking for is a hug ;-) -- Stefano.
Re: Public/Private classification (was Re: javadocs navigation)
Upayavira wrote: So, I have created a wiki page: http://wiki.apache.org/cocoon/PublicAPIClasses Please go there and mark classes public/private as necessary. As it says at the top of that page, if you disagree with someone, change it to dispute or D for short. Then it becomes an opportunity for some healthy argument! On with the asbestos underwear everyone... I would suggest to start by saying N to every class that is not yet tagged move it from there. I would also suggest to add all the other avalon components we ship by default too (I use the SourceResolver quite a bit and you need to pass this to the SourceUtil.getSource() so you need to get it somewhere) Note: yes, I write all my application logic in javascript these days and I don't care if it's bad or I don't have eclipse for it having a better javadoc would be just enough. -- Stefano.
Re: javadocs navigation
hepabolu wrote: Stefano Mazzocchi wrote: I think this is our single most important problem in helping our users: we care too much about them and we want to give them the best experience we can think of. We need to start caring less about that. In short: Perfect is the enemy of good. and Good is not really a friend of good enough either ;-) -- Stefano.
Re: Roadmap for Cocoon Blocks
Reinhard Poetz wrote: In Amsterdam at the GT Daniel gave a presentation (http://cocoongt.hippo12.castaserver.com/cocoongt/daniel-fagerstrom-blocks-2.pdf) about Cocoon blocks and one of his slides contained a roadmap for Cocoon blocks. This roadmap was discussed in the breaks and AFAICT is was widely accepted. Of course this doesn't mean that this is community consensus as not all have had the chance to comment on this yet. So here is the roadmap and let's discuss it officially on the mailing list: - Cocoon 2.2 will not use OSGi but will support blocks as far as possible: - blocks protocol (= sitemap blocks) - a block gets its own component manager that contains all local components and gets the block component managers of all wired blocks as parent. - we use M2 as build and deployment tool (needs some special M2 plug-ins for the deployment part) - blocks are distributed as binaries - blocks are *not* spread over different directories during deployment - a block can contain classes in [block]/BLOCK-INF/classes that are added to the context classloader -- this means that everything, that real blocks promise, works except the shielding of Java classes. - Cocoon 3.0 will use OSGi -- shielding classloader and hot plugablillity Although Daniel has emphasized this many times I want to repeat it: We don't need to branch trunk for this roadmap. OSGi development can be done in parallel and we can avoid the unsatisfying situation of maintaining two branches. Of course future development can show that this or that is not possible or should be done differently (who knows now, if OSGi will really make it) but IMO it's nice to have a goal and something that we can communicate to other projects that depend on Cocoon so that they have enough time to adapt their design decisions. I'm +1 One thing, though, remember to also have a LinkRewritingTransformer that is block aware so that we can do style src=block:skin:/styles/main.css/ and this gets translated in the right URL (hopefully relative, so that we don't have issues with webapp proxying, or, if absolute, we need a way to configure where is the cocoon mountpoint as seen from the proxy side) I'm currently doing http://simile.mit.edu/repository/linotype/trunk/stylesheets/absolutize.xslt with my latest linotype and I can't wait to get rid of all these hacks :-) -- Stefano.
Re: [GT2005] Presentations and Audio Now Available
Bertrand Delacretaz wrote: Le 10 oct. 05, à 23:04, Agile Jack a écrit : ...Thanks to Arje and others from Hippo for a well-run event, and to the presenters for great content... And big thanks to you for the recordings and quick publishing, this adds a lot of value to the event! Now we need somebody to have the SMIL of the slides synchronized with the audio ;-) JK, awesome job everyone, too bad I was on the other side of the planet (in los angeles)... maybe next year we should have MIT organize it :-) -- Stefano.
Re: [VOTE] new committer: Max Pfingsthorn
Bertrand Delacretaz wrote: Dear community, Several of us share the thought that Max is the perfect example of a GSoC success: apart from great technical work, he's quickly found his place in our community, with regular contributions in code and on the lists. His presentation at last week's GT has shown a high level of understanding of CForms and of Cocoon at large. What he's done with the forms libraries is definitely not just a student work, it is solid stuff. (and besides that, it will be cool to have more people with difficult names to type ;-) So I have the pleasure of proposing Max as our new committer! Please cast your votes, here's mine: +1 +1 -- Stefano.
Re: [Docs] Articles on Cocoon
hepabolu wrote: Hi, this is both a notification and some requests. During the GT I've asked several people in the community to write an article on an aspect of Cocoon. The intention is to get a series of a few articles and have them published in an (online) magazine or other relevant site to promote/expose Cocoon. The intended readers are: - those unfamiliar with Cocoon/those that think Cocoon is only suitable for small, almost static websites. - those that are familiar with Cocoon and run into a similar problem. So the article should not be too technical, but give enough information to help the readers in the second group to find more information. Given the target group the articles should not be too long, certainly not more than 5 pages, probably less. So far I've been promised: - Cocoon and large websites by Pier and Ross McDonald, focus on performance issues - Cocoon and security by Ralph, focus on security issues in internet banking - Cocoon and AJAX by Sylvain, focus on how easy it is in Cocoon - Cocoon and performance by Jack Ivers and Vadim, focus on a comparison of XSLT processors - Cocoon and CMS by Steven, focus on the role/advantages of Cocoon in Daisy Awesome! How about something about Cocoon as a service integration platform? Massimo, Matthew and Gianugo, between the three of you, I'm sure you have something to say. I would like to see the success stories too, like the sites that won awards that are powered by cocoon or the behind-the-scene integrators. Requests: - are there more people willing to contribute articles that could fit this series? I think you should convince our more CTO-ish type of committers that even if they are so overwhelmed and busy these days, it's probably good for their business and cocoon's in general, if we show off a little more what we achieved. More real life case studies and serious stuff can bring a lot of solidity to the question why should I use this stuff? that CTO/CIOs ask. - what would be the most interesting site/magazine to get this series published? I intend to get them up on our documentation site as well, just have to figure out what the most effective publishing schedule is. I think O'Reillynet/xml.com is a good place. O'Reilly has wanted a book on cocoon forever, which I started and dumped, then Steven restarted and dumped (or held), so it didn't happen. Not sure there is enough traction for an entire column on cocoon, but we might well ask, a lot of people in O'Reilly have good respect for Cocoon. -- Stefano.
Re: XULifying CForms (yet another attempt?)
Gianugo Rabellino wrote: On 10/10/05, Stefano Mazzocchi [EMAIL PROTECTED] wrote: I've been working heavily with XUL recently and I have to say, it could be a refreshing experience if you were used to build DHTML applications. At the same time, be aware that XUL is normally used inside the mozilla security sandbox (say, loaded with chrome:// instead of being loaded with http:// or file://), things change rather dramatically when you use remote XUL (as it is called when you load XUL from http:// as opposed to local XUL. From what I reckon, the security sandbox shouldn't be that much of an issue when dealing just with forms with no access to local resources. Things of course would change when it comest to mangling with the user's station, such as writing files or opening socket connections to different hosts, but it shouldn't be different from applets, to say the least. That is the theory. In practice, I heard it's a lot more painful, due to bugs and overconcerned security restrictions. As far as XBL goes, I would suggest to start without and see how far you can keep going without it (which, for me, is pretty far since I'm not developing reusable UI widgets) Then again, a good lot of CForms is about reusable UI widgets, which makes me think that we'll need XBL pretty soon. Is there a reason to be scared though? I don't quite find XBL, in its simplest incarnations, a daunting technology: if you use it as a poor's man XSLT/macro processor it's more or less a piece of cake. I agree, though, on staying away from overcomplication as much as we can. Oh, no, nothing to be really scared off. Just a way to reduce the barrier of entry... but if you think you need it, go for it. As for as XHTML, XUL does *NOT* replace XHTML, in fact, you can consider it as an extension to it. There are things that are, IMO, but better than in XHTML (the vbox/hbox/flex model, for example, *WAY* better than the stinking table/tr/td or even better than the CSS3 column layouts) but some XUL widgets are nothing but reusable XHTML constructs with embedded style and behavior (and that's why XBL is related to CSS, you can think if XBL as an extension to CSS to make behavior portable and isolated.. too bad they got the syntax wrong, the use of the XML for XBL is a total golden hammer instance if you ask me) rant Now, call me an old fart, but I don't quite like the continuous and oh-so-fashionable XML bashing I see nowadays. Clearly, writing angle brackets all over the place isn't the most comfortable way of working, but as long as I will be able to (per)use transformations so that I will be able to generate an application using just an XSL stylesheet from a model, I'll be an happy puppy. I just wish we had a (successful) alternate syntax to avoid the carpal tunnel syndrome, yet XSLT/XPath/validations and friends are just too powerful technologies that make me easily fogive input verbosity. /rant all right, all right. look, it can be worse, I work with people that want everything to be RDF ;-) As far as roundtripping, Ajax all over the place is the only reasonable answer, IMO... be aware that this makes browser history and bookmarking an interesting problem. Yup, my point exactly. One of the first problems to dissect is how CForms can go from a navigation based framework to a real GUI, where navigation happens locally and it's calculated (mostly) on the client. This is my first and foremost concern and at times I have the feeling that Xul in CForms will have to remain a pure translation of html interfaces (as in s/\.html/\.xul/g). Not a big deal after all. Would be nice to work with other types of interaction too, though, like wizards and decks, but that's another story. At the same time, browsers are *NOT* build with that in mind and remote XUL cannot prevent the users from clicking the back button Well, this is where continuation should help us. At least possibly. :-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/) -- Stefano.
Re: [Docs] Articles on Cocoon
Torsten Curdt wrote: - what would be the most interesting site/magazine to get this series published? I intend to get them up on our documentation site as well, just have to figure out what the most effective publishing schedule is. I think O'Reillynet/xml.com is a good place. O'Reilly has wanted a book on cocoon forever, which I started and dumped, then Steven restarted and dumped (or held), so it didn't happen. Not sure there is enough traction for an entire column on cocoon, but we might well ask, a lot of people in O'Reilly have good respect for Cocoon. Actually I had this idea a while ago. The Cocoon bible. Written by the people who wrote it. Having a couple more authors to split the huge task. We could even make it an Open Source book. Available as a pdf or in print for the ones who want to hold something in there hands. I would love that... How about a wikibook? -- Stefano.
Re: svn commit: r312973 - /cocoon/trunk/tools/src/blocks-build.xsl
[EMAIL PROTECTED] wrote: Author: lgawron Date: Tue Oct 11 16:00:10 2005 New Revision: 312973 URL: http://svn.apache.org/viewcvs?rev=312973view=rev Log: support for compact blocks.properties: exclude.all.blocks=true include.block.template=true include.block.forms=true the opposite also works: include.all.blocks=true exclude.block.bsf=true include.block.ajax=false You rock. Can we have it in 2.1.8 too, pretty pleezeee :-) -- Stefano.
Re: branch vs trunk
Mark Lundquist wrote: On Oct 11, 2005, at 4:12 PM, Ralph Goers wrote: Hopefully, then 2.1.9 could be the final release on the branch. It has to be, since we will have run out of digits! :-) :-) :-) FYI, Apache JServ 1.0b was preceeded by 0.9.12a, which, BTW, ran the e-commerce part of starwars.com in 1997 ;-) -- Stefano.
Re: Releasing 2.1.8
Leszek Gawron wrote: Stefano Mazzocchi wrote: Carsten Ziegeler wrote: We wanted to release 2.1.8 as soon as possible after the GT. Now the question is, are there any open issues? I'm currently aware of two problems: 1) Documentation - 2.1.8 does not contain the docs anymore, so we should find a way to add them in the distribution. I think a directory containing just the html docs (or pdf?) should be fine. In addition I think we should remove the targets for adding the docs and the api docs to the webapp. 2) Logging of exceptions - currently correct stacktraces are tied to our own logkit formatter (if I'm not mistaken), so as soon as you're not using logkit or not using this formatter, you don't get the correct stacktraces. Is there anything else? making the include.block = true overload exclude.block.all = true would go a long way to make things easier for users, IMO and should not but such a big change. want it - got it. Stefano's Hero Plate of October goes to Leszek :-) check the trunk - if it's ok - I'll port it back to 2.1. Sorry, should have read this first. I looked at the code and should be ok, I say move it to 2.1.x already. one simple gotcha: if there is a conflict on the same level of granularity: include.block.template=true vs. exclude.block.template=true, include.all.blocks=true vs. exclude.all.blocks=true it is always resolved in favour of include.* properties. Yeah, makes perfect sense. -- Stefano.
Re: Releasing 2.1.8
Carsten Ziegeler wrote: We wanted to release 2.1.8 as soon as possible after the GT. Now the question is, are there any open issues? I'm currently aware of two problems: 1) Documentation - 2.1.8 does not contain the docs anymore, so we should find a way to add them in the distribution. I think a directory containing just the html docs (or pdf?) should be fine. In addition I think we should remove the targets for adding the docs and the api docs to the webapp. 2) Logging of exceptions - currently correct stacktraces are tied to our own logkit formatter (if I'm not mistaken), so as soon as you're not using logkit or not using this formatter, you don't get the correct stacktraces. Is there anything else? making the include.block = true overload exclude.block.all = true would go a long way to make things easier for users, IMO and should not but such a big change. -- Stefano.
Re: XULifying CForms (yet another attempt?)
Gianugo Rabellino wrote: I've been playing quite a bit these days with Xul, after a few years' hyatus which made me appreciate the comeback even more. :) I'm more and more inclined in devoting some of my Copious Free Time to a Xul CForms renderer, and I wanted to catch up with other fellow members and see what's going on. I understand from http://issues.apache.org/bugzilla/show_bug.cgi?id=25295 that Jorg is already doing something, so before reinventing wheels I'd love to know what the current status is and if/how I might help. So far, I have identified a few points on my radar: 1. server roundtrip model: Xul doesn't really fit in a request-response model where all data travel at once upon hitting a submit button. This might lead to two different alternatives: (a) ajax all over the place, where more or less every widget submits events to a Cocoon server or (b) server roundtrips being avoided whenever possible thanks to the richest functionalities of a Xul frontend (think repeaters). Convergence with the new Ajax model of CForms somewhat blurs the line, yet I feel that a mere translation of CForms widgets to Xul without a rethink of the roundtrip model might be somewhat limiting (as in uh, ok, so what?). Actually, I might go as far as saying that the whole Xul/CForms marriage might not have that much sense now that we have Ajax and all the Web 2.0 yadda-yadda. That is, unless we figure out some real advantage in server interaction. 2. the role of XBL. I feel XBL (xul binding/extension language) might play an important role in producing advanced widgets (again, think repeaters, calendar popups, double selection lists... well, you name it). Still, XBL is tightly coupled with CSS, and I'm not sure how to manage the CSS-XBL relationship within Cocoon. 3. HTML orientation of CForms: despite a clear intention to stay as neutral as possibile, CForms has a strong bias towards HTML in its most advanced widgets (well, think HTMLarea to see my point). I'm not sure if it's entirely possible to get rid of the HTML heritage, and I kinda feel that in some cases it even doesn't make much sense (hey, after all Xul is happy with xhtml snippets). Well, these are just a few initial thoughts, which don't even deserve the status of [RT]: let's say I'm just trying to break the ice and see what's going on in Xul/Cocoonland. Awaiting for your comments! I've been working heavily with XUL recently and I have to say, it could be a refreshing experience if you were used to build DHTML applications. At the same time, be aware that XUL is normally used inside the mozilla security sandbox (say, loaded with chrome:// instead of being loaded with http:// or file://), things change rather dramatically when you use remote XUL (as it is called when you load XUL from http:// as opposed to local XUL. Not many people publish their content directly in XUL not even the most advanced web mails publish their content in XUL. In theory, there is no reason why a web mail should not look and feel *EXACTLY* like thunderbird... but it never happened and I suspect not for lack of trying but for bugs or architectural limitations. So, be aware that weird behavior might be due to that. (a way to know for sure is to load your xul directly from chrome:// or by passing it as a parameter to the moz command line) As far as XBL goes, I would suggest to start without and see how far you can keep going without it (which, for me, is pretty far since I'm not developing reusable UI widgets) As for as XHTML, XUL does *NOT* replace XHTML, in fact, you can consider it as an extension to it. There are things that are, IMO, but better than in XHTML (the vbox/hbox/flex model, for example, *WAY* better than the stinking table/tr/td or even better than the CSS3 column layouts) but some XUL widgets are nothing but reusable XHTML constructs with embedded style and behavior (and that's why XBL is related to CSS, you can think if XBL as an extension to CSS to make behavior portable and isolated.. too bad they got the syntax wrong, the use of the XML for XBL is a total golden hammer instance if you ask me) As far as roundtripping, Ajax all over the place is the only reasonable answer, IMO... be aware that this makes browser history and bookmarking an interesting problem. XUL is not going to change the way you interact with the server if not to make it more obvious that there is no need to refresh a page if the content changing is just marginal and there is no need to bookmark. At the same time, browsers are *NOT* build with that in mind and remote XUL cannot prevent the users from clicking the back button (and I'm not sure if moz itself keeps the state in the remote xul fields... but I see no reason why it shouldn't, being form fields in XUL the same XHTML dom elements, just wrapped with more style and behavior) Anyway, using XHTML/XUL multichanneling for CForms would indeed be nice. -- Stefano.
Re: how do you get the directory where the current flow is running?
Sylvain Wallez wrote: Stefano Mazzocchi wrote: I'm in a flow.js and I want to know where it is located on disk. You can have the current sitemap's location using cocoon.getComponent(SourceResolver.ROLE).resolveURI(.); D'oh! I was doing cocoon.getComponent(SourceResolver.ROLE).resolveURI(context:/.); Sometimes it's even too easy :-) Thx. -- Stefano.
Re: Cocoon Fat Test
Leszek Gawron wrote: Carsten Ziegeler wrote: And I agree, not having the jx transformer/generator in the core anymore is really annoying. If you forget to include the template block it breaks your application immediately. But I hope we will fix this, as well. I do not get it. It's like saying if you forget to tank your car will stop - how annoying :). What I mean is that the same problem applies to any block (i.e. forms). It's just jx and forms tend to be most core ones. I think it was a good decision to move jx from core to it's own block. It's a stupid work to customize cocoon blocks - this is the biggest problem. I agree with Stefano. My local.blocks.properties should state: exclude.all.blocks=true include.block.forms=true include.block.template=true that's all. Someone said some time ago to use :s/#include/include. Try to merge your customized local.blocks.properties with updated main blocks.properties file. Agreed. I never said it was annoying to move stuff out, I don't mind to have to specify what blocks to add, but I want this to be easy not a PITA like it is today. My local.blocks.properties should look like Leszek wrote above. Easy and simple. That would make us go a long way forward. -- Stefano.
how do you get the directory where the current flow is running?
I'm in a flow.js and I want to know where it is located on disk. Any idea anyone? -- Stefano.
Cocoon Fat Test
Carsten hates me when I just talk, so here is some action: let's measure cocoon's fat. Follow me and type the following in your terminal svn co http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/ \ cocoon svn co http://simile.mit.edu/repository/linotype/trunk/ linotype export COCOON_HOME=../cocoon/ cd linotype ant install ant run then point your browser at http://127.0.0.1:/linotype/ you should see an empty linotype running. Now, ctrl-break the above, and do zip -r linotype.war dist/ the resulting WAR is 12263572 bytes. How much of this is linotype? zip -r linotype.zip dist/linotype/ results in a 129673 bytes. Cocoon has a platform overhead of 11Mb. *compressed* Now let's see where the things are: cd dist du -d1 returns 1152./linotype 144 ./resources 128 ./stylesheets 27472 ./WEB-INF 29000 . so cd WEB-INF du -d1 returns 8 ./classes 1544./entities 25776 ./lib 27472 . So, it's clear that cocoon weight is in the jars. NOTE: the linotype build system builds cocoon from source with the most stripped-down version as Linotype does not depend on any blocks. This is the minimal 2.1.x cocoon possible right now. Let's see the list of jars cd lib ls -AlS (with some little hand cleaning) 2941481 jdtcore-3.0.2.jar 2730442 xalan-2.7.0.jar 1395202 cocoon-2.1.8-dev.jar 1203860 xercesImpl-2.7.1.jar 607235 rhino1.5r4-continuations-R26.jar 552263 commons-collections-3.1.jar 522143 jakarta-bcel-20040329.jar 394671 jcs-1.2.5-dev-20050313.jar 358085 log4j-1.2.12.jar 285104 commons-jxpath-1.2.jar 225375 commons-httpclient-2.0.2.jar 207723 commons-lang-2.1.jar 194205 xml-apis-1.3.02.jar 189284 util.concurrent-1.3.4.jar 131458 commons-jexl-1.0.jar 115506 excalibur-instrument-mgr-http-2.1.jar 89145 excalibur-logger-2.1.jar 86665 excalibur-xmlutil-2.1.jar 83582 avalon-logkit-2.1.jar 80572 excalibur-component-1.2.jar 78599 excalibur-sourceresolve-2.1.jar 65948 excalibur-naming-1.0.jar 60047 xml-commons-resolver-1.1.jar 59645 avalon-framework-impl-4.3.jar 57548 excalibur-instrument-mgr-impl-2.1.jar 47531 ehcache-1.1.jar 42137 excalibur-store-2.1.jar 40737 excalibur-io-1.1.jar 38015 commons-logging-1.0.4.jar 32112 avalon-framework-api-4.3.jar 30117 commons-cli-1.0.jar 28584 jakarta-regexp-1.4.jar 27833 excalibur-pool-impl-2.1.jar 21028 javacImpl-0.9.jar 20640 excalibur-instrument-mgr-api-2.1.jar 20328 excalibur-instrument-api-2.1.jar 18329 excalibur-pool-instrumented-2.1.jar 14728 excalibur-pool-api-2.1.jar 8238 excalibur-i18n-1.1.jar 3565 javacApi-0.9.jar now, let's take a look 1) I don't use XSP nor javaflow, therefore I wouldn't need JDTcore, nor BCEL, nor javacImpl and javacAPI, a total of several Mb. 2) I don't use the avalon instrumentation 3) I use logkit, so I don't need log4j 4) I put the latest xalan and xerces in my app server, no need to have it here too here is the slimmed down cocoon 1395202 cocoon-2.1.8-dev.jar 607235 rhino1.5r4-continuations-R26.jar 552263 commons-collections-3.1.jar 285104 commons-jxpath-1.2.jar 225375 commons-httpclient-2.0.2.jar 207723 commons-lang-2.1.jar 194205 xml-apis-1.3.02.jar 189284 util.concurrent-1.3.4.jar 131458 commons-jexl-1.0.jar 89145 excalibur-logger-2.1.jar 86665 excalibur-xmlutil-2.1.jar 83582 avalon-logkit-2.1.jar 80572 excalibur-component-1.2.jar 78599 excalibur-sourceresolve-2.1.jar 65948 excalibur-naming-1.0.jar 60047 xml-commons-resolver-1.1.jar 59645 avalon-framework-impl-4.3.jar 47531 ehcache-1.1.jar 42137 excalibur-store-2.1.jar 40737 excalibur-io-1.1.jar 38015 commons-logging-1.0.4.jar 32112 avalon-framework-api-4.3.jar 30117 commons-cli-1.0.jar 28584 jakarta-regexp-1.4.jar 27833 excalibur-pool-impl-2.1.jar 18329 excalibur-pool-instrumented-2.1.jar 14728 excalibur-pool-api-2.1.jar 8238 excalibur-i18n-1.1.jar which now yields a war file of 4Mb, still a lot but much better than before. Anyway, I know some of this has been discussed at lenght on the mail list already, so I tried cocoon 2.2.x to see if things are improving, let's redo the little dance: svn co http://svn.apache.org/repos/asf/cocoon/trunk/ cocoon svn co http://simile.mit.edu/repository/linotype/trunk/ linotype export COCOON_HOME=../cocoon/ cd linotype ant war results in a 11516061 file, which is better than before, well, let's see if it works ant run does cocoon work? [open http://127.0.0.1:/] yes it does. does linotype work? [open http://127.0.0.1:/linotype/] nope Type 'jx' does not exist for 'map:transform' at, let's see the sitemap map:components !-- include some additional components -- map:include dir=context://WEB-INF/sitemap-additions pattern=*.xconf/ /map:components ah, ok, cool, now the components are located somewhere else, let's see the sitemap-additions map:components xmlns:map=http://apache.org/cocoon/sitemap/1.0; map:generators map:generator
Re: [vote] Ross Gardler as a new Cocoon committer
Daniel Fagerstrom wrote: Hi all! I'd like to propose Ross Gardler as a Cocoon committer. He is one of the driving forces in the Forrest project, he has been quite active in our documentation efforts and in integrating Forrest, Lenya and Cocoon. Becoming a Cocoon committer will simplify his work and bring our communities closer. Please cast you votes. +1 -- Stefano.
Re: [RT] Is Cocoon Obsolete?
Daniel Fagerstrom wrote: Steven Noels wrote: ... The same kind of wonder I had when this thread started - as in oh no, this is sooo easy and self-centered!. Yes self-centered and irresponsible. LOL Steven and Daniel, I'm sorry, but your comments prove my point. Sylvain was the only one understanding what this was all about [1]: a wake up call. [1] http://www.anyware-tech.com/blogs/sylvain/archives/000217.html --- o0o --- Stefano, We are a large number of people who got inspired of your visions and have spent years on develop and implement them. Some have even built companies around Cocoon. Now everyone who want to start using Cocoon in a project, sell products based on it or services have to fight: The founder of Cocoon find it obsolete. Read http://www.betaversion.org/~stefano/linotype/news/94/ before putting words in my mouth. You really don't help us. Nobody is more blind than who doesn't want to see. -- Stefano.
Re: [RT] Is Cocoon Obsolete?
Ross Gardler wrote: ... a rich client requires higher bandwidth. This argument absolutely bogus. Google Maps, for example, is a way richer client than, say, MapQuest but consumes a fraction of the bandwidth, because using the web in a more architecturally consistent way, it can take advantage of the browser (or local proxy) caches. If you were to deliver a mapping applications to, say, schools in africa, which one would you use, MapQuest (where every click is a new 120Kb gif file) or GMaps (where there is virtually no traffic generated at all after the initial load... which, for normally, can be consumed by a local transparent proxy)? -- Stefano.
Re: Fwd: [jetty-discuss] Microsoft IE7 compromise of session security
Pier Fumagalli wrote: I found this on the Jetty list, and thought it was relevant as in the examples we tend to encode the continuation ID into the URL... This is f***ing scary!!! Wow, this will kill either kill urlencoding or IE. Seems like good news for firefox, though. Pier Begin forwarded message: From: Chris Haynes [EMAIL PROTECTED] Date: 28 September 2005 13:04:53 BDT To: Jetty Discuss [EMAIL PROTECTED] Subject: [jetty-discuss] Microsoft IE7 compromise of session security Reply-To: [EMAIL PROTECTED] List-Id: Discussion for Jetty development. jetty-discuss.lists.sourceforge.net Everyone concerned with data security and privacy should read the Microsoft developer Blog describing their IE7 anti-phishing feature: http://blogs.msdn.com/ie/archive/2005/09/09/463204.aspx With this browser feature enabled, Microsoft sends a copy of the URL + path of every accessed page back to their HQ - even if you have HTTPS/SSL/TLS enabled! Note the posts I have added to the blog on and since 26 Sept, and the Microsoft response confirming the compromise of HTTPS. It is possible that beta browsers with this feature are already available in the wild. There is one particular aspect that Servlet developers / security managers should be aware of... If using URL-rewriting for session management, Microsoft will be sent a copy of the Session ID while that session is still open (whether or not TLS is involved) , as this sessionID is contained within the path. There is nothing technical preventing, say, a Microsoft employee or contractor from joining that session. Jetty might need to add a site-selectable option which detects the IE7 agent and throws an Exception if URL-rewriting is invoked - to prevent session IDs being sent to a compromised browser. Views, anyone? The other security / privacy concerns with this feature are of a broader nature, and probably OT for this list. Chris Haynes --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ jetty-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jetty-discuss -- Stefano.
Re: Fwd: [jetty-discuss] Microsoft IE7 compromise of session security
Tony Collen wrote: Pier Fumagalli wrote: I found this on the Jetty list, and thought it was relevant as in the examples we tend to encode the continuation ID into the URL... This is f***ing scary!!! Pier Maybe it's time we make Cocoon automatically pull the continuation ID from a session tied to a cookie. That would prevent us from the ability to have (or detect!) multiple browser windows, as a cookie is not per-window, but per-browser. -- Stefano.
Re: [GT2005] Jotspot?
Nicola Ken Barozzi wrote: Ugo Cei wrote: Il giorno 03/ott/05, alle 10:38, Arje Cahn ha scritto: Stefano was talking about JotSpot in his RT; did anyone try this? JotSpot Live [1] seems to be the SubEthaEdit-for-those-without-a-Mac (indeed, I'm talking purely for myself ;-) ). Another product in this area is Writeboard http://www.writeboard.com. JotSpot is sold as a real-time collaborative environment, while Writeboard is not. OTOH, Writeboard is free, while JotSpot Live is free for max. 5 pages, which should be enough for the GT. I haven't tried any of them yet, but i read a couple reviews on www.solutionwatch.com Gobby http://socialsoftware.weblogsinc.com/entry/1234000410060570/ http://gobby.0x539.de/ Which I can't even understand how to compile on a mac. If somebody manages to get it working on a mac, please, send it over. -- Stefano, who wishes the SubEthaEdit people submitted an internet-draft with their protocol so that Gobby would not implement their own.
Re: [RT] Is Cocoon Obsolete?
I won't reply to this thread until I let more people verbalize their feelings, but this is OT enough for me to reply now. Niclas Hedhman wrote: (Not the mentioning of 'What happened to the RDF promise in Cocoon??') Are you mentioning the ability to add RDF metadata to our real blocks (as, ehm, mozilla does) or about the ability to deal and manage RDF data directly in cocoon? For the first, well, it all depends on the real block implementation (and honestly, not that important since strongly structured markup can be RDFized with very little effort). For the second, there are huge problems: processing RDF thru its RDF/XML representation is hell. Read Ian's post for more http://internetalchemy.org/2005/09/the-sixteen-faces-of-eve Ian and I are thinking about writing a note to W3C (my employer is a member...ehm, *IS* W3C :-) about a canonical RDF/XML representation that makes it easier to use XML technologies on top of RDF data serialized as with an XML model. But then again, I must warn you, it will still be a massive hack. There is a lot of work to do to bring the RDF and the XML world closer... unfortunately, there is resistance in both. -- Stefano.
[RT] Is Cocoon Obsolete?
My life regarding software goes thru phases. A phase transition is when you strongly believe in something, then you strongly change your mind. Others call it a 'revelation', others think you lost your mind. I wrote Cocoon as a way to help achieving a more coherent look and feel for the apache web sites. It was way overdesigned for that, so much that we created another project for that (Forrest) which is still overdesigned (even if it got a lot done). Having one coherent look and feel was more of a social issue than a technological one, here I was right and the way to design for SoC was something that didn't have much to do with XML, yet SoC turned out to be a key in a lot of aspects (and here I was right too, even if I don't believe my mathematical simulation of degradation of SoC, done in my master thesis, makes working group productivity saturate have any scientific meaning whatsoever, in fact, I truly believe it to be correct but I would need a lot more resources to prove it scientifically and I don't have the time/will at this point) Another thing that I got right was the assumption that in order to create glue between systems, you can't transform everything into everything else: a common ground, a low level lingua franca, helps establish a foundation for SoC work to take place for real. The use of XML as such a lingua franca was a ridiculous bet in 1998, now it's pretty much a given. People thought that forcing everything into a SAX pipe would have been too limiting for those binary formats... but the 80/20 rule worked very well, for those 20% cases where you need, for example, to transform, say, AVI into MPEG4, well, use something else :-) Cocoon is a lot different than it wanted to be when I started. In fact, I didn't even release it when I wrote it, I thought nobody would have been interested in it, but then I mentioned it once and people wanted to take a look at it. And the rest is a lot of incremental (and not so incremental) evolution. - o - Over the last 6 months, I worked pretty heavily on Mozilla as a platform. Read more here if you are not up-to-date with it: http://www-128.ibm.com/developerworks/xml/library/x-ffox15.html Weird as it might seem, Mozilla and Cocoon have a lot in common: 1) a polymorphic component model (xpcom for mozilla, avalon for cocoon) 2) are not afraid of using the right language for the right thing, even if this means an explosion of different things that you have to learn 3) the understanding that in media stat virtus (virtue is in the middle) in regarding to compilation vs. interpretation, static vs. dynamic and strongly typed vs. weakly typed languages (javascript + C++ for moz, javascript + java for cocoon) and other scripting languages might follow 4) a vibrant, loyal and open development community 5) due to #1 + #4, a very strong and diverse collection of components 6) due to #6, a need for a simple to use extension deployment mechanism (and metadata description to automate it) but most important, is that pretty much everything that cocoon was born to do, you can now do it in firefox directly. Things like cinclude can be done with ajax-driven client side include, even if this requires XSLT transformations (even multiple ones!) The fact that it runs on a client, avoids the problem of having to use SAX events instead of using DOM, which is much simpler to work with. SVG is supported natively and SVG, XHTML and canvas can belong in the same DOM and react to the same scripting environment, mix ajax and you drastically reduce the need to go back to the server, even for the most complex UI scenarios. Because of that, you don't need continuations anyway: a wizard-type page will have a continuation that is simply a state stored in your client... and you go back to the server only to save state.. just use data-driven web services a few, highly dynamic, XHTML templates. I do that for my latest web sites and the more I learn how to driven the client, the less I feel the need for advanced server frameworks. Is it just me? Is client side advancement making cocoon and all its machinery to compensate for advanced web client obsolete and archaic? Don't get me wrong, firefox's market share is minimal and firefox 1.5 is not even out there, but the direction is set and things like Google Maps, Flickr, Google Mail, the new Yahoo Mail and JotSpot show very well where we are heading: richer and richer web UIs, requiring more web services and less publishing engines. Cocoon already moves in this direction, I'm fully aware of it and before xforms make it into the browser, CForms are already out there and working pretty damn well. Cocoon was and still is instrumental as a bridge between old and new, but in a new world, would one need to learn all this stuff? or, on the other hand, once somebody knows how to work and build rich web UIs would it find it
Re: [EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
Daniel Fagerstrom wrote: Any idea about what is wrong? I added the lacking dependencies (knopflerfish-framework and knopflerfish-log) to the cocoon module in gump.xml, but it doesn't seem to help. Is the used gump file for Cocoon stored somewhere else as Stefano suggested (and in that case where)? Or did I defined the dependecies in a flawed way? ehm, gump uses a *different* descriptor, in its svn module. Upayavira volunteered to find a way to synchronize the two, moving the descriptor into a directory and then svn externalize that from gump but never did. Bad boy, no donut for you! -- Stefano.
Re: svn commit: r279762 - in /cocoon/branches/BRANCH_2_1_X: legal/msv-20030225.jar.license.txt lib/optional/msv-20030225.jar src/blocks/validation/java/org/apache/cocoon/components/validation/Validator.java
David Crossley wrote: Pier Fumagalli wrote: Antonio Gallardo wrote: Ralph Goers wrote: Ralph Goers wrote: I seem to remember reading on legal-discuss that the nuclear clause is incompatible with the ASL. If true, any components with such a license can not be disctributed with our code or reside in SVN. Ralph Faulty memory. The only reference I could find was at http:// wiki.apache.org/jakarta/LicenceIssues which, of course, is not official ASF policy. I found it! http://www.mail-archive.com/dev@cocoon.apache.org/msg18202.html Darn... I wish you found that when I posted the license before committing... http://www.mail-archive.com/dev@cocoon.apache.org/msg34406.html The License that Pier shows in msg34406 is not the same one as was commented on in msg18202. The main comments do not match, only the nuclear thing still remains. We are not lawyers, so someone should clear this up with the ASF license-discuss list. We have a Legal VP now :-) Pier, if you want to use that code, send a comment to Cliff. Also, we could also tell sun to remove that clause or to relicense under CDDL. -- Stefano.
Re: [vote] Arje Cahn as a new Cocoon committer
Sylvain Wallez wrote: Hi all, I'd like to be the voice of a general opinion among Cocoon developers that Arjé Cahn should be made a Cocoon committer. Arjé has been using Cocoon for years and has taken the responsibility of organizing the upcoming GetTogether, which shows how much he cares for Cocoon and its community. And we value this a lot. This isn't the usual committer vote, since Arjé hasn't provided a lot of code patches. But quoting Stefano, committer means 'being committed to the project' rather than being able to commit code. There are some precendents for this: Matthew Langham and Andrew Savory were made committers, because we felt they were important citizens of the Cocoon community. The same applies to Arjé today. Please cast your votes! I'm very proud of a community that is able to attract contributions that do not translate directly into code. +1 -- Stefano.
[RT] flowscript in jruby anyone?
http://jruby.sourceforge.net/ -- Stefano.
Re: [EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
Gump wrote:
-
[cocoon.javac] location: class
org.apache.cocoon.core.osgi.OSGiLoggerManager.OSGiLogger
[cocoon.javac]return isLevelEnabled(LogService.LOG_ERROR);
[cocoon.javac] ^
[cocoon.javac]
/x1/gump/public/workspace/cocoon/src/java/org/apache/cocoon/core/osgi/OSGiServiceManager.java:57:
cannot resolve symbol
[cocoon.javac] symbol : class ServiceReference
[cocoon.javac] location: class org.apache.cocoon.core.osgi.OSGiServiceManager
[cocoon.javac] ServiceReference ref;
[cocoon.javac] ^
[cocoon.javac]
/x1/gump/public/workspace/cocoon/src/java/org/apache/cocoon/core/osgi/OSGiServiceManager.java:60:
cannot resolve symbol
[cocoon.javac] symbol : class InvalidSyntaxException
[cocoon.javac] location: class org.apache.cocoon.core.osgi.OSGiServiceManager
[cocoon.javac] } catch (InvalidSyntaxException e) {
[cocoon.javac] ^
[cocoon.javac]
/x1/gump/public/workspace/cocoon/src/java/org/apache/cocoon/core/osgi/OSGiServiceManager.java:84:
cannot resolve symbol
[cocoon.javac] symbol : class InvalidSyntaxException
[cocoon.javac] location: class org.apache.cocoon.core.osgi.OSGiServiceManager
[cocoon.javac] } catch (InvalidSyntaxException e) {
[cocoon.javac] ^
[cocoon.javac]
/x1/gump/public/workspace/cocoon/src/java/org/apache/cocoon/core/osgi/OSGiServiceManager.java:90:
cannot resolve symbol
[cocoon.javac] symbol : class ServiceReference
[cocoon.javac] location: class org.apache.cocoon.core.osgi.OSGiServiceManager
[cocoon.javac] ServiceReference ref =
(ServiceReference)this.serviceReferences.get(obj);
[cocoon.javac] ^
[cocoon.javac]
/x1/gump/public/workspace/cocoon/src/java/org/apache/cocoon/core/osgi/OSGiServiceManager.java:90:
cannot resolve symbol
[cocoon.javac] symbol : class ServiceReference
[cocoon.javac] location: class org.apache.cocoon.core.osgi.OSGiServiceManager
[cocoon.javac] ServiceReference ref =
(ServiceReference)this.serviceReferences.get(obj);
[cocoon.javac] ^
[cocoon.javac]
/x1/gump/public/workspace/cocoon/src/java/org/apache/cocoon/core/osgi/OSGiServiceManager.java:106:
cannot resolve symbol
[cocoon.javac] symbol : class ServiceReference
[cocoon.javac] location: class org.apache.cocoon.core.osgi.OSGiServiceManager
[cocoon.javac] ServiceReference result;
[cocoon.javac] ^
[cocoon.javac]
/x1/gump/public/workspace/cocoon/src/java/org/apache/cocoon/core/osgi/OSGiServiceManager.java:117:
cannot resolve symbol
[cocoon.javac] symbol : class ServiceReference
[cocoon.javac] location: class org.apache.cocoon.core.osgi.OSGiServiceManager
[cocoon.javac] ServiceReference[] results =
ctx.getServiceReferences(itf, query);
[cocoon.javac] ^
[cocoon.javac]
/x1/gump/public/workspace/cocoon/src/java/org/apache/cocoon/core/osgi/ServiceManagerActivator.java:41:
cannot resolve symbol
[cocoon.javac] symbol : variable LogService
[cocoon.javac] location: class org.apache.cocoon.core.osgi.ServiceManagerActivator
[cocoon.javac] LoggerManager logManager = new OSGiLoggerManager(ctx,
LogService.LOG_DEBUG);
[cocoon.javac] ^
[cocoon.javac] 74 errors
Looks like OSGi hooks are missing in the gump descriptor.
Anybody with OSGi inclinations willing to help the poor gump?
--
Stefano.
Re: [EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
Daniel Fagerstrom wrote: Done, hopefully. Any comments on the Gump and Maven2 discussion? http://marc.theaimsgroup.com/?t=11255200745r=1w=2 is that the descriptor that gump uses? wasn't it moved over to the gump repository? Upayavira, did you volunteer to make sure that the two became one or I dreamt of it? -- Stefano.
Re: svn commit: r278641 - /cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPExpressionParser.java
David Crossley wrote: Pier Fumagalli wrote: Nah, I'm pretty confident that on this little nag, I'm right... Does anyone have a pier2doc transformer? Why do you think this projet was started? :-) -- Stefano.
Re: svn commit: r278641 - /cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPExpressionParser.java
Niclas Hedhman wrote: On Monday 05 September 2005 14:43, Antonio Gallardo wrote: Of course that I am aware that both codesets (Shift-JIS and ISO-8859-1) are different UNICODE subset. This is same as you stated. No. Pier doesn't mix the difference between Unicode (sequence of characters) and the mapping of those characters to fixed or variable length encoded bytestreams. The fact that character 65 in Unicode is in many encodings mapped to the byte value 65 is for convenience only, and that fact should be ignored. Our SVN uses UTF-8 as the default charset (or encoding) or not? Subversion uses binary data, and is agnostic to any encodings in the data (or so they say). AFAIU, marking files as text only deals with the line endings and how the diff mails are generated. The --encoding argument applies to commit messages. Paths, URLs/URIs has additional encoding requirements. Correct. And is also worth noting that SVN before 1.2 and CVS2SVN create a pretty broken combination when the commit message in CVS used an encoding that was not UTF-8. As an example, try to get svn log of the apache repository and the svn client will fail, because we have three commit messages in latin-1 placed, as binary, by cvs2svn into svn (and prior to 1.2 there was no encoding validation checking in svn) that get moved into the XML file that is passed between the svn server and client, which is using UTF-8 as the encoding. I've asked infra@ to fix this, but being not really high priority (only data archeologist like myself care about those things) it is unlikely to get fixed. Anyhow, I agree with Pier, we should *only* use ASCII and escape unicode characters explicitly the \u way. -- Stefano.
cocoon 2 speech?
came across http://freetts.sourceforge.net/ the first demo of cocoon that I ever did in public was a hello world page in html, pdf, svg and voicexml, with the little merlin dude speaking 'hello world' to the audience (got a standing ovation for that!) It always bugged me that I needed an external tool for that that worked only on windows... but I found this. Have no time, but it would be cool if somebody could write a voicexml-wav serializer using that (it's BSD). -- Stefano.
Re: [2.2] Past, present and future of the maven build
Nicola Ken Barozzi wrote: Joerg Heinicke wrote: On 30.08.2005 17:31, Ralph Goers wrote: ... So to summarize, I would suggest that it would be a good idea for each component - be it core or a block - to have api, impl, test and samples projects. Did I mention that I hate tools needing changes in the subject they should work on to make them work? The above scenario and the other mentioned necessary restructurings were the reason why I ever were against a change of the build system to Maven. Ok, we really have a problem with our current build system. Nobody (me included) started with another solution like Ant 1.6 or similar. The Maven fraction started now to address the problem and I'm ok with it. The above rant probably just shows I'm a smart-ass ;-) If you, or me, or anyone would have really gone deep in fixing the Ant build system, we would have been forced to do the same restructuring. FYI, i wrote considerable chunks of ant with my desire to have a build system that could stand the complexity of cocoon. For a long time, you could build cocoon only with the version of ant that shipped with it. I wouldn't be against shipping maven2 with cocoon 2.2 for the time being. Wherever cocoon uses, it will stretch it and maybe break it. We are one of the most complex (in terms of dependency and use of different technologies/languages) software systems in the java world. So, let's not be afraid to taste a little blood on the bleeding edge. -- Stefano.
Re: [2.2] Using includes in the sitemap for components?
Sylvain Wallez wrote: Carsten Ziegeler wrote: Carsten Ziegeler wrote: Daniel Fagerstrom wrote: Can't this be handled by wildcard inclusion from component configurations in some catalog, so that we get rid of the snippet insertions. SNIP/ We can use wildcard inclusion in the main sitemap as well. So what do others think? Do we want to get away of patching the main sitemap? I think we should add an include statement for the main sitemap that includes additional sitemap components from some directory in the WEB-INF dir, like WEB-INF/sitemap-components/*.xconf Oh yes, for sure! The more we can avoid xpatch the better IMO. +1 -- Stefano.
Re: Using Maven to build Cocoon
Niclas Hedhman wrote: I didn't mean going with Maven 1 first, but just hang in there with Ant and await a final release. We are doing this with 2.1.x. For 2.2, I think we should not be afraid of innovate and remember: the maven people are friends (just like the ant people were) and they will certainly love our patches in case we find something that breaks. As for moving target, what isn't when you have 210 libraries you depend on? :-) -- Stefano.
Re: 2.1.8 (Was: Re: JING Transformer...)
Vadim Gritsenko wrote: Ralph Goers wrote: My opinion is that a community that releases software that it won't stand behind has a significant problem. I think you just mis-interpreted semantics of the 'unstable flag'. See, actual meaning is: unstable: Supported by the community, many people are working on it, expect frequent interface and implementation changes, new features and bugs. stable: Solid code with 3-years-old bugs and patches in bugzilla, nobody is working on it, interface and implementation won't change for foreseeable future. deprecated: stable code which stinks. Once you grog this, you'd get that more often Cocoon releases will lead to greater user community participation, more ideas will float, and active developers move on to other blocks or features (such as OSGi and RealBlocks(tm)) sooner, which will result in abandoning of cforms and marking it as stable... :-P Then I think Ralph's employer perception could be altered if we modified how we flag blocks and avoid labelling something as 'unstable' when, in fact, several people use it for their commercial offerings and have done so for a while. The first version of cocoon was 1.0 not 0.01alpha as it should have been if I looked at how many lines of code and how much of the planned functionality was there. Perception *is* reality ;-) And seriously, I'd argue that your -1 on releases actually *delays* maturity of cforms. I wholeheartly agree with this, we should release now and set a deadline for the next release as soon as we release one and stick to it unless major showstoppers come up. -- Stefano.
Re: 2.1.8 (Was: Re: JING Transformer...)
Ralph Goers wrote: So while you can argue about frequent releases or whatever, I still want a forms framework that this community is willing to call stable. A few things: 1) the simple fact of calling something stable doesn't make it stable, but it *does* in fact alter the perception of those using it. Commercial companies ship software as final when they know it's not. Some distros ship x.0 and people know it's really a beta. We don't do betas anymore because we know people stay away from those and you need the real-life test to find the real bugs. 2) this is open source. you get what you pay for. And, yes, I foresee that companies that will do regression tests on projects that, for one reason or another, fail to do that property or extensively, will make a good living out of that... but their developer's lifes will be miserable and their burn out cycle might kill them before the profit margins start to kick in (not to mention the continuous friction with the community, if they keep those regression tests for themselves). 3) blocks are not properly versioned, because we need real blocks for that. If we had real blocks, we could have two branches: a bugfix one and a development one, just like we do for the trunk, and backport stuff when it makes sense. In this scenario, Ralph will happily use the bugfix branch and Sylvain will happily hack ajax into the development branch and everybody is happy, as CForms have their its own release cycle and version control. 4) software stability is a myth, it's never there, but continue to call something 'unstable' to avoid justifying lack of back compatibility is not a good excuse, not after so many years of being there and being used. So, here is what I suggest: 1) we attach a label to a 'branch' of a block, not to the block itself. 2) labels should not be 'stable', 'unstable' but 'bugfix' and 'development', or something equivalently neutral in respect of stability which is normally perceived as a measure of how well it remains working in real life rather than how solid its contracts are (not everybody thinks in terms of SoC like we do, especially not their managers and CTOs, anyway). Or we could use the linux style of using odd/even numbers to signify taht without having to find an appropriate name for it. 3) start having two branches for the blocks that require it (cforms is a good candidate), then decide what branch to ship with what version. Comments? -- Stefano.
Re: [Proposal] Switch to Maven NOW
Carsten Ziegeler wrote: Actually I'm a little bit tired of the ongoing Maven discussion. Why can't we just switch the trunk to Maven NOW? Who really cares if trunk is not buildable/working for the next days until the switch is finished? So I propose to: - Completly remove the lib directory - Create a sub project core in the trunk directory I think we will use several (sub) projects, one for the core, one for the webapp etc. and use Mavens multiproject feature. - Move src/java to core/src/java - Create a Maven project description with all dependencies for core Et voila, we will get a cocoon.jar hopefully. Then we create a webapp subproject, move the webapp there and build a webapp with just the core. And then we continue from there, moving test, moving samples etc. On thing at a time. And we can always ask the maven guys for assistence and hints. Ah, and finally, I think we should start right away with m2. Go for it. -- Stefano.
Re: [VOTE] Switch to Maven NOW
Carsten Ziegeler wrote: So far the response was positiv, so I think we should just vote about it and then do it. If you have any questions, please use the proposal thread. So please cast your votes for switching to Maven2 NOW as outlined/discussed in the proposal thread. +1 one more thing, though, don't lose gump! doesn't have to work right away, but keep it in mind. -- Stefano.
Re: Cocoon stack traces
Sylvain Wallez wrote: Conclusion -- The Cocoon stacktrace gives some very valuable information about what problem happened, and more importantly where it happened. We now need to progressively add location information to important places in the code to make these Cocoon stacktraces more and more useful! Tell me what you think! big +1! -- Stefano.
Re: [VOTE] Jorg Heymans as new committer
Tony Collen wrote: Antonio Gallardo wrote: So, I'm pleased to propose Jorg Heymans, as a committer. Please cast your votes: here's my +1! :-) +1 here.. welcome!! +1 -- Stefano.
