Granted, things should always be tested. But if I insult someone for the purposes of seeing if their dancing ability or basketball skill (as examples) get worse, is this supposed to be front page news? There is no real need to publically report common sense. By definition, everyone already knows. Why not limit our public dissemination (as opposed to actual research) to things that are contrary to many people's common sense?
This is the category of item that supposed to go into an academic journal with little fanfare. Good for getting a graduate student (or undergrad) published but little earth-shattering insight that "otherwise intelligent people" would find interesting. On the contrary, it is fodder such as this that folks will cling to when they try to create an artificial environment without any rejection. After all, rejection is bad for you. "Think of the kids!"...and all that tripe.
Let's say you're about to take a test (math test, IQ test, art history test, doesn't matter). Just before you take the test, I show you a relatively current picture of your father diddling himself with ben wa balls. Wups! You don't do as well on the test as you would have. Your apparent IQ has gone down.
Just before you take the test, I stomp on your foot. Wups! You don't do as well on the test as you would have. Your apparent IQ gone down.
Just before taking the test, your boyfriend/girlfriend breaks up with you. Wups! You don't do as well on the test as you would have. Your apparent IQ gone down.
Anyone know why there are so many psychology students in US colleges? Because a large portion of college students are too stupid to handle a real major. Unfortunately, those psych majors eventually graduate and publish studies such as these.
String foo = "This is"; String bar = "intuitive"; System.out.println( foo + " more " + bar );
%s? What does 's' stand for? String? Why is the variable a char* then? That's the C version of a string? Sheesh! It's a good thing C isn't complex or anything...
Of cource, there's always C++
std::string foo = "this is"; std::string bar = "intuitive"; std::cout << foo << " also more " << bar;
C coders really need to take a step back and look at their "simple" language and try to remember all of the arcana necessary to memorize to use it. And what about those string manipulation functions? strcmp, strcat, strstr, strtok... Why were they only six letters long and cryptic? Oh! Those limited-functionality computers from >30 years ago that had only a few K of memory and symbol tables couldn't handle long names. It's 2002 for god's sake! Long names don't matter in processing time and modern editors (if you can call emacs modern) can do variable and function name completion for you. It's not a time issue, it's not a performance issue, and it's not simpler.
<bio>I code in C for a living along with a few other languages and I'm tired of constantly writing a new linked list structure or binary tree or any other data structure reminiscent of the wheel.</bio>
Once again, there is far more variance in programmer ability (judicious use of algorithms and patterns) than is inherently demonstrated by language choice.
Now with regard to Java, its standard library is much cleaner than that of Perl (for example). Perl objects were an afterthought and it shows. Its socket APIs are not intuitive. Couple this with the fact that you can't enforce by interface that a particular variable is an int vs. a string vs. anything else without extra runtime checks like regular expressions. This can add unecessarily to the runtime of a program. Large-scale Perl is a nightmare compared to language that doesn't just pay lip service to a component-based architecture. So right off the bat, this is what I get from servlets that I can't do with mod_perl.
Comparing VMs, Java's is noticeably faster than both Perl's and Python's for computationally intensive programs and is not quite so bad against C or C++ as you assert. Combine this with the fact that Java can be compiled natively with a variety of tools today (although modern JVMs do a more than adequate job). Speed approaches that of C and C++ code without core dumps, buffer-overflow exploits, etc. Add to this excellent i18n and l10n support, standard networking, threading, database, directory services, distributed programming, ABI, etc., I consider it a good trade.
A lot of development is going into Jython. Why? Because a lot of Python developers recognize the value of the Java platform....and the JVM is faster than the Python VM.
Now let's examine the proprietary manuevers. Sun has not released Java to a standards body. ECMAScript *has* been released to a standards body and yet the programming models are not uniform on all platforms. Perl is the shining star apparently...but how many have tried to access CPAN modules directly from Perl on Windows? As it turns out, quite a few modules are programmed with C and a UNIX model in mind (or just Linux/BSD). Don't believe me, check out the graphics modules (dynamic creation of web images for example), RPC, mail handling, etc. So much for write once run anywhere with a "standard" language.
Are there issues like a logger that was put in even though there was an arguably better one out there?...and a regular expression engine? Sure. Do I like everything Sun has done? No. But then, I don't like everything the Perl, and C++ communities have done either.
Now let's examine the J2EE issue. If Sun tested JBoss for free, what does that say to IBM, BEA et all who paid a lot of money to get tested? You'll lose partners that way. But also notice that Sun has not tried to bully JBoss out of the market. When you look closely at the Lutris (Enhydra) J2EE stink, you'll note that they were worried because they used Sun J2EE libraries to produce a product. Couple this with the fact that Sun never issued a cease and desist; Lutris pulled back on their own.
As long as JBoss (and libre software in general) stays competitive, it is in Sun's best interest to leave it alone. Can you imagine what would happen if Sun suddenly decided to deny access to the Sun platform to anyone but licensed vendors? It would destroy the Solaris server market. The same holds true for Java. After all, it's just another platform, and there is far too much code out there to simply cut them off.
This is like saying that maybe tomorrow Microsoft may announce that all compilers except for Visual Studio are not allowed to be used on Windows OSes. Aside from the anti-trust issues, there is simply too much code out there that has been written with a Borland, GNU, Intel, Metrowerks, etc. compiler.
Someone's already pissed in the pool. You can't get it out now without draining all the water out first. Developers are in far more danger from DCMA, SSSCA, and other similar items than Java suddenly becoming unavailable.
Algorithms are fast or slow -- not so much the languages in which they are written. A for-loop in Java is just as fast as a for-loop in C. An O(log n) operation in BASIC will probably run faster than a O(n^2) operation in assembly. In most cases, if your standard library is complete and reasonably efficient, most programmer errors are avoided simply by helping them avoid reinvention of the wheel.
That being said, as compared to C or C++, Java is a faster language in which to code -- standard library that includes networking, i/o, threading, enterprise components, directory services, database access, etc.
That being said, Java is a more complete language for handling networking, i/o, threading, enterprise components, directory services, database access, etc. than any scripting language I know.
That being said, for numerics, low-memory usage GUIs, kernels, and those applications that need the absolute last squeeze of performance (0.01% of all programs), use some language other than Java. Hell, use whatever works best for you. But a properly written program (badly written programs and inefficient algorithms can occur in any language) are speed-wise quite similar to one another despite the choice of language. There is a far greater variance in programmer ability than the inherent speed traits of a particular language.
For the record, I don't own any Sun hardware, don't have $2 million to spare, and my servlets and EJBs run just fine thank you.
My only point of skepticism with a scriptable C and C++ is that the languages weren't designed to be scriptable -- they were designed with compile-time inefficiency so that runtime efficiency could be maximized. This is in direct contrast to scripting languages that are meant to be loaded and run in a single pass with no linking steps, best guess, general optimizations, and ease of coding. If it works for Carrot, good for them. If it helps primarily C and C++ coders get their jobs done, good for them. Will it give the same type of benefits that languages such as Python can give, probably not.
Use the right tool for the job and use that tool correctly. Everything else (including language-bashing) is waste of energy.
With the exception of Python (I think...I'm not sure) I know of no commonly used scripting languages that allow for simple and consistent object serialization/deserialization. I know of no scripting languages that have the equivalent functionality to EJBs. Combine those with the fact that strong typing (it's a int, it's a String) can be an invaluable asset in interface-based programs -- especially when talking to other languages or over a distributed model such as CORBA.
While there is definite overlap, Java has a different problem space from most scripting languages (and from C or C++). Use the right tool for the job.
As long as you write standard C++ (std::string instead of char*, cin/cout instead of scanf/printf, etc.) buffer overflows and format string errors go away. Core dumps are still a danger though...
I agree though... All of the power of a scripting language with the ease of use and simplicity of C++. Makes me pine for the days where assembly was the dominant language.
I'll be watching this thread closely. If nothing else, it may lead to some interesting ideas for both camps.
Re:You really should provide more info ....
on
Zope or Cocoon 2?
·
· Score: 2
Be sure to try a newer version of Tomcat. Version 3 was the reference code given to the ASF by Sun and was quite inefficient. Version 4 was a complete refactoring and it shows.
If you still have issue with the speed of Tomcat 4 or don't want to try again with Tomcat in general, there's always Resin.
With regard to EJB, now you've met someone who's used them, likes them, and has found that, implemented correctly, many EJB engines do quite well.
And Cocoon is no longer just a presentation layer. Unfortunately this hasn't been advertised enough and there is still work to be done in the area. But yes, one way of working with Cocoon is through an EJB backend although this is not necessary.
First of all, I would like to apologize for the inflammatory remark relating to communication from certain orifices. It was totally uncalled for.
The original poster was asking for a comparison between Cocoon and Zope. To introduce a third option - to forget them both and try JSP/Servlets/MySQL - is hardly a cardinal sin.
No, it is not a cardinal sin, but I don't see how it adds flexibility in this case. The generation of data in Cocoon (through raw generators or via XSP) have full access to the JVM and its tools as well. In this case, the sky is the limit. I neglected to mention this due to lack of forethought on the matter and because I tend to forget that not everyone knows how Cocoon works yet.
And while I could go into fire and brimstone about how MySQL is not an ACID database, I'll leave that for another discussion.;-)
Perhaps XML really is wonderful, but I find the mantras of XML such as separation of content/logic, language-independence etc. often achievable with less effort elsewhere; hence such mantras ruin the credibility of XML in my view. I have worked on XML-based projects and find that very often the XML side of things was really superfluous.
Could you please be more specific? I'm always curious about better processes. If, indeed, there is a clean, efficient, and better way of getting the job done that does not sacrifice maintainability, I would love to hear about it. I simply endorse the use of Cocoon because it is the best/most promising that I have see thus far. XML is a means, not an end.
You say that Cocoon can handle JSPs - can it handle servlets too? Can it offer the full functionality of, say, Tomcat?
This is a topic of much length on the Cocoon development list. Basically, JSPs can be used to generate XML data (Cocoon doesn't really care much where its data originally comes from), but JSPs are tailored to HTML/presentational views. This doesn't mean to imply that I think that JSPs are a terrible piece of technology, but when generating XML, it doesn't assist the developer in making sure that the output is well-formed XML. Different tools for different jobs and all that.
XSP is the closest equivalent to JSP in this case, and XSP allows full use of the JVM, access to request parameters from the client (what is normally seen in the servlet API).
Cocoon is not on the same level as Tomcat for a couple of reasons. The first, and most obvious, is that Cocoon does not implement an HTTP-compliant server. It has no open sockets waiting for a client to access. This is what it uses Tomcat (or many other servlet containers) for. However, there is a case for Cocoon to allow subcomponents just as servlets are a subcomponent of the servlet container. This is only on the drawing board for now and should not be considered a real feature of Cocoon for the moment.
And also note that the use of Cocoon absolutely does not mean that the use of other servlets is forbidden. It can indeed be used as "one more piece in the puzzle." I simply find that it's an increasingly large portion of the overall pie. But, as always, your mileage may vary.
And you'll note that most of these threads have to do with the performance of Xalan and not specifically Cocoon. If someone rolled their own implementation using Xalan, they'd run into the same issues. Cocoon supports more XSLT implementations than just Xalan. And with current work going on to integrate XSLTC, the transformation speed issues should be brought to reasonable levels soon.
The developers were talking about including native code because some parts (Xalan!) were too slow. It was a random thought and a thread-starter to foster coversation. The URL that I posted is Stefano pulling back from his beliefs that native code should be used. This was because an extremely fast solution (that does not affect end user sites - internal optimization) was found in an all-Java XSLT processor. This refutes your last and second-to-last links as simply being stale info.
Some of your other links were authored by outside individuals, not core developers, and many of them are a few months old (and thus out of date with the rate of development in Cocoon). And if you follow the above links to their conclusion, you will see that (a) a configuration change solves the issue, (b) it's an issue that has been resolved, or (c) it's an issue that has been discussed and a plan of attack is well underway and close to completion.
For example, XSP has had known performance issues and this I acknowlege. The developers know what is causing the slowdown and are either working on or have already fixed many of its speed issues. One such issue is the speed at which XSPs are processed. The generation of bytecodes from XSP (much like the concept of servlet bytecode generation from JSPs) is bottlenecked by Xalan.
If you say, "yeah, that's all well and good, but it's too slow now -- I don't care about how fast it's gonna be," I can sympathize. Yes, perhaps I went overboard, but then I tend to believe that you make your interfaces and processes correct first and then focus completely on speed later. This means that over time, your apps get faster just by upgrading the framework in much the same way that native programs get faster when the compiler is updated or with optimizations to a dependant library. As long as your contract is respected (in this case, the contracts are interfaces), this is possible. Here, the contracts are XML, XSLT, XHTML, SVG, the sitemap, etc.
I see the issues with Cocoon 2 today as the same as the issues with C vs. assembly years ago. If someone coded in C when C was functionally complete but not fully optimized, they would run slower than the equivalent assembly (minus development time). On the other hand, when it came time to maintain and/or extend the code, C was easier. And as time went on, the C code "magically" became comparable in speed to assembly with little to no effort (comparatively) with the upgrade of a compiler. Then the machine for which it was originally written falls into disuse. With C, you begin porting. With assembly, you effectively start over again.
In short, if you really can't wait, then your decision is made for you: roll your own (like assembly in the above analogy) or use something else that fits your current needs. If the speed/scalability concerns are not as pressing and you can think about the long haul, Cocoon 2 makes sense (like C in the above analogy).
-----------
Note that my original post was solely with regard to comparisons of Cocoon 2 with Cocoon 1 and roll-your-owns. I explicitly excluded comparisons with Zope or any of its ilk due to my lack of knowledge about them. Right now -- today -- Cocoon 1 is slower than Cocoon 2, and rolling your own will most likely put you on the path that the Cocoon project started walking a few years ago.
My advocacy is not blind. What I said, in a nutshell, was that Cocoon 2.x is currently faster than Cocoon 1.x and probably a better choice than roll-your-own.
And last but not least, if those of you out there go through and read the mailing list archives, you'll find some exciting discussions that rarely (if ever) say that performance is bad and they've hit a brick wall. Or that performance is bad and they don't have a plan to fix it. It is a very active mailing list full of people with ideas and implementations that show Cocoon speeding up by leaps and bounds on a weekly basis.
Most of the posted links that talked about problems are merely that beginning of threads. I encourage people to read the threads in their entirety.
Sorry, but FUD is never rational. Skepticism (close, critical examination) and FUD (denegration without reference to established facts) are two very different things. "I'm not convinced if Cocoon 2 can handle the loads my site sees everyday" is an example of skepticism. Contrast this with the FUD statement "Cocoon 2 could never handle the loads my site sees everyday." I would consider it a sign of intelligence to say, "Cocoon2 could never handle the loads my site sees because of [valid technical reason X], [valid technical reason Y], etc." I would not consider the latter to be an example of FUD.
it seems to be targeted at XML fans rather than giving clear business benefits
Fair enough. While there is some information on the homepage that addresses your concerns (check the section titled "Management Considerations"), it can seem this way. I guess you only have my word for it when I say that XML is a means for Cocoon, not an end. Without XML, Cocoon no longer exists, but this is like saying that without C, UNIX wouldn't exist. The principles are sound and XML simply enables the implementation of said principles.
Following your list,
1. XML/XSLT is supported by many vendors - so if one implementation sucks, the others may not. Note: Don't fool yourself. There are implementation quirks in the various J2EE engines. Coupled with the fact that they each encourage use of their own components (many times the reason to choose a particular vendor: their bundled tools), this can be problematic.
2. Servlets are a small part of J2EE. The corralary to Cocoon 2 would be that SAX pipelines are a lightweight framework and XSPs (compiled into generators: the start of a SAX pipeline) offer full, unrestricted access to the Java API.
3. XSLT stylesheets can be written by anyone who knows XSLT. Everyone in my developer network has written an XSLT stylesheet. (Note how subjective this one is)
4. There is a large community of XML and XSLT developers - evidence that it is a sound technology. (I have to take exception to this argument; far more subjective than the last one)
5. As someone who actually develops too, applications through Cocoon *are* a sound technology. (And the opinions continue...)
--------------
Believe it or not, I try to remain pragmatic in my daily dealings with technology. If there were an article with everyone touting the all-powerful qualities of Cocoon 2, please believe that I would be among those trying to assert some reality into the discussion.
And thanks for the vote of confidence, but Cocoon has enough spokespeople in my opinion. The reason you haven't heard from them is that, until recently, they didn't want general distribution. They wanted only the technically-inclined due to the fact that it was a work in progress. Now that 2.0 has been released, I'm sure that you will be seeing a lot more from them.
I agree with your thoughts about business decisions. It is a new technology to a lot of people. I will have bumps in the road. I forget that I've been following their progress for years now and know how to avoid certain pitfalls. Lifelong geek syndrome: knowing a problem set for so long that the solution, no matter how obscure, seems totally obvious. I tend to forget that most people haven't heard of a Cocoon sitemap or what it is used for or (most important) what problems it's supposed to solve.
To me, Cocoon seems solid in much the same way that Linux 2.4.x is solid. It's had its bumps, but lately it's been pretty damed good! But unfortunately, you cannot prove a new platform. Only old(er) platforms can be considered proven. But then, Zope is in the same boat, but maybe only slightly less so.
As for "reinventing the wheel", it's a bad analogy.
On the contrary, just about any "roll-your-own" is reinventing the wheel when existing implementations exist. Even at the library level, by your line of reasoning, you wouldn't be reinventing the wheel because you're using the JVM. And on and on until you hit the hardware. Then it's about VLSI vs. aggregate chipsets.
My point is that if you are worried about the maturity of a project, I doubt that a recent roll-your-own is somehow going to be more mature or inherently less of a headache especially when considering open source software and the ability to debug/patch yourself. Is debug/patch of an outside project difficult? Sure, but any in-house project of sufficient size will have its maintainability issues as well. Check out the Cocoon source. It's surprisingly clean considering its size -- they have strongly enforced coding guidelines.
but at the moment it inspires little confidence - hence the understandable Fear, Uncertainty, and Doubt.
No, not FUD. Just some good, clean, healthy caution.
Copy cocoon.war to Tomcat's webapp directory. Got to http://[tomcatserver]/cocoon. That's a difficult installation? The only other thing you would have to do is turn debug logging off (or to warn).
I think the installation problems are very overstated.
Re:Tomcat + FOP is all you need
on
Zope or Cocoon 2?
·
· Score: 3, Informative
You assume that you can't use Cocoon 2 with J2EE. This is false. I myself have made it run on WebLogic and JBoss.
And Cocoon 1 is NOT faster than Cocoon 2. Not only does Cocoon 2 use less memory (SAX vs. Cocoon 1 using nothing but DOM) to get things done, but it passed Cocoon 1 in speed a while ago. Perhaps the comparisons you made were with Cocoon 2's cache turned off.;-)
This combined with the fact that Cocoon 1 relies on processing instructions with each XML file to get the job done. Believe me, Cocoon 2 is definitely a step up.
we can tell our SQL server to output XML and all we have to do is tell FOP to render it with appropriate XSL. Rendering HTML is simple also - we just transform it on the fly with xalan/xerces.
Hmmm... Sounds like you're reimplementing Cocoon only badly. Cocoon uses xalan (or saxon or xt or soon xsltc) and xerces (or crimson). It uses FOP to do PDF, Postscript, and PCL output. And they've implemented a kick ass, configurable caching model to boot. But rather than using what others have written that do exactly what you propose, you advocate rewriting from scratch!?! Yeah, good choice.
Re:You really should provide more info ....
on
Zope or Cocoon 2?
·
· Score: 2
I don't have any experience with Cocoon, but for any project I've been involved with I'd take Zope to JSP/Servlets any day.
Once again, the "I haven't used it but I assume it sucks" argument. Cocoon is a servlet in name only at this point. And you don't have to use JSPs with Cocoon. In fact, unless you are migrating from a JSP solution, you shouldn't use JSPs with Cocoon.
I've yet to see any of these claims substantiated, but some people claim Java scales (I'm still awaiting conclusive proof, btw, that it's the J2EE framework that makes scalability easy).
Note that you (a) admit to never having even seen it run and (b) confuse it with J2EE. You can use Cocoon with EJBs or you can use it with just a servlet container. It doesn't take very long to install Tomcat, Cocoon, fire up a web browser. Hmm... let me see: Download a JDK, download Cocoon 2 and Tomcat 4, untar Tomcat in some directory, uncompress Cocoon and copy cocoon.war into Tomcat's webapp directory, start Tomcat ($TOMCAT_HOME/bin/startup.sh), and go to http://localhost:8080/cocoon/. Bear in mind that debug-level logging is turned on so performance will suffer somewhat until it's turned down a notch (editing $TOMCAT_HOME/webapp/cocoon/WEB-INF/logkit.xconf and changing every DEBUG to WARN after you get Cocoon running at least once -- then restart Tomcat). But even with debug-level logging, I doubt you will be that disappointed.
and because all of the transformation (XSLT) happens in C (using libxml/libxslt from the Gnome project) it's fast too.
Has anyone found Cocoon 2 to be unusually slow? I haven't. All the best to AxKit, but they are cloning Cocoon. They were not doing the same thing as Cocoon. They were trying to clone Cocoon. Cocoon is ahead of the development curve here.
Having said that, always consider what your programmer's skills are. If they're happy using Java they may not be too thrilled by a Perl or Python based framework.
I can't speak to AxKit, but you have to be doing a fair amount of stuff off the beaten trail to even have to code Java with Cocoon. This is not to mention that you can also use JavaScript, Python, Velocity, and PHP in addition to just Java with Cocoon. You can talk to a database without using any of them.
And sometimes hardware is cheaper than pissing off your developers
Why are you developers worrying about what language it's in rather than getting the job done? If the job calls for Python, use Python. If it calls for Scheme, use Scheme. If your developers will only use C (for example), then you have a problem far greater than your choice of framework.
And they're just trying to clone Cocoon. Most of the time when people use AxKit, they've never actually used Cocoon. They just hear "Java" and whine without seeing if there is indeed a disadvantage/advantage in performance.
I have little evidence that Cocoon is a viable framework, much of the talk surrounding it seems like XML rhetoric.
And thus you've never tried it, never used it yourself, and are quite content talking out of your ass. The "XML rhetoric" as you put it is the separation of content from presentation and management.
Cocoon 2 has been very well designed and I have little reason to complain about being "boxed in." But at the same time, I don't have to work very hard for it.
Also bear in mind that Cocoon 2 does not remove the ability to use JSPs outside of Cocoon to do CM. You could even use JSPs within Cocoon if you wanted to.
I have not really found a need for something like Cocoon at all as yet
Sounds very much like someone saying "I wrote my own web server and I don't see the need for something like Apache." Who knows? Your own server may work fine for your purposes, but isn't it worth it just to see for yourself and compare before making a final judgement? Which would you rather spend time on: the framework for your site, or your actual site? The more time you spend on infrastructure is the less time you get productive work done.
with Java we have so many tools at our disposal to begin with.
And those tools are still at your disposal when using Cocoon.
Stop the FUD surrounding Cocoon 2
on
Zope or Cocoon 2?
·
· Score: 4, Informative
First off, Cocoon 2 is NOT slower than Cocoon 1. Cocoon 2 passed version 1 a while ago. Cocoon 1 with caching is only faster than Cocoon 2 with its cache turned off -- and then Cocoon 1 barely beats Cocoon 2.
Second, Cocoon 1 works by putting processing instructions in every XML document pointing it to an associated XSLT stylesheet or other secondary processor. So what happens when you want to switch stylesheets for every document in a directory (or a site!). Do you write a script to do it? And what if you want multiple views of the same document? Say on one page, you want a certain subset of data from a XML document dedicated to the band U2, and on another page you want a different subset. Do you split up your document into two pieces? Do you make a copy of the document and worry about redundancy? What if you change your mind later and want to have a different information snippet? This is precisely the sort of thing that Cocoon 2 solves.
With regard to folks claiming that they don't want to use a JSP/Servlet solution, I have a couple of points to bring up. While Cocoon can use JSPs, they were only included so that there would be a migration path. In normal installations, Cocoon does not use JSPs at all. Then again, if you really have a hard-on for PHP, Cocoon can use that as a language for generating XML. It's up to you. In fact, you can write XML generators in PHP, Velocity, JSP, Python, and JavaScript (and of course, Java). You can mix and match. Or you can pull information out dynamically through a relational or XML database. You can generate XML from a directory listing. All without writing a single line of Java code.
And no, just by using Xerces, Xalan, and FOP, you are not going to make something just as good as Cocoon. What if you want to make multiple transformations in the same pipeline (transforming the source XML more than once before it hits the client)? Will you write the code to handle every different case you come across during the lifetime of the site? Or would you rather not reinvent the wheel and just use Cocoon (which handles it very well indeed).
Download it (and a servlet engine like Tomcat) and give it a try. The worst that happens is that you find that you don't like it (Note that it comes with debug logging turned on and will be slower than if you turned it off or to "warn" instead). The best that may happen is that you see how powerful a real publishing and XML processing engine can be.
You can even run it from the command line to pre-generate your site! You don't need the servlet running if that's your preference!
----------
That said, I can't speak to Zope. I've heard good things about it so I'll leave it at that. But don't denegrate Cocoon when you haven't even tried it (which most of the folks who've posted have done). It's not just an XML parser, an XSLT processor and some duct tape. It's much much more! The sitemap alone should be enough to get you to try it. What's a sitemap you ask? Go to the site and find out!;-)
And no, I am not a member of the Apache Software Foundation, nor do I have any affiliation with it other than as a user.
I disagree. No two programs have the same set of configuration needs. Two web servers can have very different configuration options depending upon their focus. While I agree that DTDs are a pain in the ass (DTD entities == XML preprocessor == pain), using something like XML Schema or RELAX-NG would give all the necessary metadata a configuration manager would need. Far more so than some one size fits all or (only slightly better) five sizes fit all.
If the UI can see that you need parameters A, B, and C, there is sufficient description data for the parameter (relatively simple with judicious use of XML namespaces), and can tell that A is supposed to be an integer from 0-100, B is supposed to me a valid email address, and C is an enumerated list of possible values (all possible with existing XML technology -- no need to reinvent the wheel), you will have your UI while allowing a sufficient amount of individualism by the programmer.
And you don't need pre-defined schemas to make object mappings. There is previous work in this area already for the generation of object definitions from XML metadata. Of course this is of most use to the actual programs. The config manager needs to process the metadata in addition to the instance document (the config file).
Come to think of it, a schema document describing UI manager "hints" might not be such a bad idea. It wouldn't tell it what each config entails, but could provide info on how that is to be presented. Nice idea!
Re: LDAP. LDAP is an interface, nothing more. The LDAP spec says nothing about how the datastore should be implemented. In short, you could have your config data in any form you wanted and, as long as it was consistent and documented, publish the information through an LDAP-compliant gateway process.
I stand corrected. I haven't tried Mandrake since I got burned by v6.1.
However, compare it to WinXP and not Win98. Comparing to Win98 is like saying Mandrake 8.1 is better than RedHat 4.2. While accurate, it's hardly fair.
Note: I don't use WinXP either. The whole licensing issues surrounding that OS scare the shit out of me.
I meant Ximian and RedHat with regard to Red Carpet. Yes, I'm well aware that apt was (originally) a Debian animal.
Read this message board as part of my job? Only if you consider me trying to get people to standardize so that my job becomes easier because I don't need to learn config file formats in a 1:1 ratio to the programs I use. If that's what you mean, then yes, I posted for my job.
Is someone paying me to browse these boards? Of course not. Most sane employers have better things to do with their money.
Slashdot Mirror
Granted, things should always be tested. But if I insult someone for the purposes of seeing if their dancing ability or basketball skill (as examples) get worse, is this supposed to be front page news? There is no real need to publically report common sense. By definition, everyone already knows. Why not limit our public dissemination (as opposed to actual research) to things that are contrary to many people's common sense?
...and all that tripe.
This is the category of item that supposed to go into an academic journal with little fanfare. Good for getting a graduate student (or undergrad) published but little earth-shattering insight that "otherwise intelligent people" would find interesting. On the contrary, it is fodder such as this that folks will cling to when they try to create an artificial environment without any rejection. After all, rejection is bad for you. "Think of the kids!"
Let's say you're about to take a test (math test, IQ test, art history test, doesn't matter). Just before you take the test, I show you a relatively current picture of your father diddling himself with ben wa balls. Wups! You don't do as well on the test as you would have. Your apparent IQ has gone down.
Just before you take the test, I stomp on your foot. Wups! You don't do as well on the test as you would have. Your apparent IQ gone down.
Just before taking the test, your boyfriend/girlfriend breaks up with you. Wups! You don't do as well on the test as you would have. Your apparent IQ gone down.
Anyone know why there are so many psychology students in US colleges? Because a large portion of college students are too stupid to handle a real major. Unfortunately, those psych majors eventually graduate and publish studies such as these.
Iterative algorithms are usually faster anyway (and won't fill the stack on large inputs).
:)
Have a nice day.
For *very* simple cases like string literals, yes. But what about when you start wanting to actually wanting to have dynamic values?
const char *foo = "This is";
const char *bar = "intuitive";
printf( "%s %s?", foo, bar );
Oh yeah, very intuitive... Compare with
String foo = "This is";
String bar = "intuitive";
System.out.println( foo + " more " + bar );
%s? What does 's' stand for? String? Why is the variable a char* then? That's the C version of a string? Sheesh! It's a good thing C isn't complex or anything...
Of cource, there's always C++
std::string foo = "this is";
std::string bar = "intuitive";
std::cout << foo << " also more " << bar;
C coders really need to take a step back and look at their "simple" language and try to remember all of the arcana necessary to memorize to use it. And what about those string manipulation functions? strcmp, strcat, strstr, strtok... Why were they only six letters long and cryptic? Oh! Those limited-functionality computers from >30 years ago that had only a few K of memory and symbol tables couldn't handle long names. It's 2002 for god's sake! Long names don't matter in processing time and modern editors (if you can call emacs modern) can do variable and function name completion for you. It's not a time issue, it's not a performance issue, and it's not simpler.
<bio>I code in C for a living along with a few other languages and I'm tired of constantly writing a new linked list structure or binary tree or any other data structure reminiscent of the wheel.</bio>
Once again, there is far more variance in programmer ability (judicious use of algorithms and patterns) than is inherently demonstrated by language choice.
...and the JVM is faster than the Python VM.
...and a regular expression engine? Sure. Do I like everything Sun has done? No. But then, I don't like everything the Perl, and C++ communities have done either.
Now with regard to Java, its standard library is much cleaner than that of Perl (for example). Perl objects were an afterthought and it shows. Its socket APIs are not intuitive. Couple this with the fact that you can't enforce by interface that a particular variable is an int vs. a string vs. anything else without extra runtime checks like regular expressions. This can add unecessarily to the runtime of a program. Large-scale Perl is a nightmare compared to language that doesn't just pay lip service to a component-based architecture. So right off the bat, this is what I get from servlets that I can't do with mod_perl.
Comparing VMs, Java's is noticeably faster than both Perl's and Python's for computationally intensive programs and is not quite so bad against C or C++ as you assert. Combine this with the fact that Java can be compiled natively with a variety of tools today (although modern JVMs do a more than adequate job). Speed approaches that of C and C++ code without core dumps, buffer-overflow exploits, etc. Add to this excellent i18n and l10n support, standard networking, threading, database, directory services, distributed programming, ABI, etc., I consider it a good trade.
A lot of development is going into Jython. Why? Because a lot of Python developers recognize the value of the Java platform.
Now let's examine the proprietary manuevers. Sun has not released Java to a standards body. ECMAScript *has* been released to a standards body and yet the programming models are not uniform on all platforms. Perl is the shining star apparently...but how many have tried to access CPAN modules directly from Perl on Windows? As it turns out, quite a few modules are programmed with C and a UNIX model in mind (or just Linux/BSD). Don't believe me, check out the graphics modules (dynamic creation of web images for example), RPC, mail handling, etc. So much for write once run anywhere with a "standard" language.
Are there issues like a logger that was put in even though there was an arguably better one out there?
Now let's examine the J2EE issue. If Sun tested JBoss for free, what does that say to IBM, BEA et all who paid a lot of money to get tested? You'll lose partners that way. But also notice that Sun has not tried to bully JBoss out of the market. When you look closely at the Lutris (Enhydra) J2EE stink, you'll note that they were worried because they used Sun J2EE libraries to produce a product. Couple this with the fact that Sun never issued a cease and desist; Lutris pulled back on their own.
As long as JBoss (and libre software in general) stays competitive, it is in Sun's best interest to leave it alone. Can you imagine what would happen if Sun suddenly decided to deny access to the Sun platform to anyone but licensed vendors? It would destroy the Solaris server market. The same holds true for Java. After all, it's just another platform, and there is far too much code out there to simply cut them off.
This is like saying that maybe tomorrow Microsoft may announce that all compilers except for Visual Studio are not allowed to be used on Windows OSes. Aside from the anti-trust issues, there is simply too much code out there that has been written with a Borland, GNU, Intel, Metrowerks, etc. compiler.
Someone's already pissed in the pool. You can't get it out now without draining all the water out first. Developers are in far more danger from DCMA, SSSCA, and other similar items than Java suddenly becoming unavailable.
Algorithms are fast or slow -- not so much the languages in which they are written. A for-loop in Java is just as fast as a for-loop in C. An O(log n) operation in BASIC will probably run faster than a O(n^2) operation in assembly. In most cases, if your standard library is complete and reasonably efficient, most programmer errors are avoided simply by helping them avoid reinvention of the wheel.
That being said, as compared to C or C++, Java is a faster language in which to code -- standard library that includes networking, i/o, threading, enterprise components, directory services, database access, etc.
That being said, Java is a more complete language for handling networking, i/o, threading, enterprise components, directory services, database access, etc. than any scripting language I know.
That being said, for numerics, low-memory usage GUIs, kernels, and those applications that need the absolute last squeeze of performance (0.01% of all programs), use some language other than Java. Hell, use whatever works best for you. But a properly written program (badly written programs and inefficient algorithms can occur in any language) are speed-wise quite similar to one another despite the choice of language. There is a far greater variance in programmer ability than the inherent speed traits of a particular language.
For the record, I don't own any Sun hardware, don't have $2 million to spare, and my servlets and EJBs run just fine thank you.
My only point of skepticism with a scriptable C and C++ is that the languages weren't designed to be scriptable -- they were designed with compile-time inefficiency so that runtime efficiency could be maximized. This is in direct contrast to scripting languages that are meant to be loaded and run in a single pass with no linking steps, best guess, general optimizations, and ease of coding. If it works for Carrot, good for them. If it helps primarily C and C++ coders get their jobs done, good for them. Will it give the same type of benefits that languages such as Python can give, probably not.
Use the right tool for the job and use that tool correctly. Everything else (including language-bashing) is waste of energy.
With the exception of Python (I think...I'm not sure) I know of no commonly used scripting languages that allow for simple and consistent object serialization/deserialization. I know of no scripting languages that have the equivalent functionality to EJBs. Combine those with the fact that strong typing (it's a int, it's a String) can be an invaluable asset in interface-based programs -- especially when talking to other languages or over a distributed model such as CORBA.
While there is definite overlap, Java has a different problem space from most scripting languages (and from C or C++). Use the right tool for the job.
As long as you write standard C++ (std::string instead of char*, cin/cout instead of scanf/printf, etc.) buffer overflows and format string errors go away. Core dumps are still a danger though...
I agree though... All of the power of a scripting language with the ease of use and simplicity of C++. Makes me pine for the days where assembly was the dominant language.
And more fuel for the fire:
a debate between a core developer of Cocoon and the author of the above article
I'll be watching this thread closely. If nothing else, it may lead to some interesting ideas for both camps.
Be sure to try a newer version of Tomcat. Version 3 was the reference code given to the ASF by Sun and was quite inefficient. Version 4 was a complete refactoring and it shows.
If you still have issue with the speed of Tomcat 4 or don't want to try again with Tomcat in general, there's always Resin.
With regard to EJB, now you've met someone who's used them, likes them, and has found that, implemented correctly, many EJB engines do quite well.
And Cocoon is no longer just a presentation layer. Unfortunately this hasn't been advertised enough and there is still work to be done in the area. But yes, one way of working with Cocoon is through an EJB backend although this is not necessary.
My mistake. I apologize for the opening of my mouth without corresponding opening of my mind.
A closed mouth gathers no feet and all that...
No, it is not a cardinal sin, but I don't see how it adds flexibility in this case. The generation of data in Cocoon (through raw generators or via XSP) have full access to the JVM and its tools as well. In this case, the sky is the limit. I neglected to mention this due to lack of forethought on the matter and because I tend to forget that not everyone knows how Cocoon works yet.
And while I could go into fire and brimstone about how MySQL is not an ACID database, I'll leave that for another discussion.
Could you please be more specific? I'm always curious about better processes. If, indeed, there is a clean, efficient, and better way of getting the job done that does not sacrifice maintainability, I would love to hear about it. I simply endorse the use of Cocoon because it is the best/most promising that I have see thus far. XML is a means, not an end.
This is a topic of much length on the Cocoon development list. Basically, JSPs can be used to generate XML data (Cocoon doesn't really care much where its data originally comes from), but JSPs are tailored to HTML/presentational views. This doesn't mean to imply that I think that JSPs are a terrible piece of technology, but when generating XML, it doesn't assist the developer in making sure that the output is well-formed XML. Different tools for different jobs and all that.
XSP is the closest equivalent to JSP in this case, and XSP allows full use of the JVM, access to request parameters from the client (what is normally seen in the servlet API).
Cocoon is not on the same level as Tomcat for a couple of reasons. The first, and most obvious, is that Cocoon does not implement an HTTP-compliant server. It has no open sockets waiting for a client to access. This is what it uses Tomcat (or many other servlet containers) for. However, there is a case for Cocoon to allow subcomponents just as servlets are a subcomponent of the servlet container. This is only on the drawing board for now and should not be considered a real feature of Cocoon for the moment.
And also note that the use of Cocoon absolutely does not mean that the use of other servlets is forbidden. It can indeed be used as "one more piece in the puzzle." I simply find that it's an increasingly large portion of the overall pie. But, as always, your mileage may vary.
And you'll note that most of these threads have to do with the performance of Xalan and not specifically Cocoon. If someone rolled their own implementation using Xalan, they'd run into the same issues. Cocoon supports more XSLT implementations than just Xalan. And with current work going on to integrate XSLTC, the transformation speed issues should be brought to reasonable levels soon.
1 01458195902683&w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=
The developers were talking about including native code because some parts (Xalan!) were too slow. It was a random thought and a thread-starter to foster coversation. The URL that I posted is Stefano pulling back from his beliefs that native code should be used. This was because an extremely fast solution (that does not affect end user sites - internal optimization) was found in an all-Java XSLT processor. This refutes your last and second-to-last links as simply being stale info.
Some of your other links were authored by outside individuals, not core developers, and many of them are a few months old (and thus out of date with the rate of development in Cocoon). And if you follow the above links to their conclusion, you will see that (a) a configuration change solves the issue, (b) it's an issue that has been resolved, or (c) it's an issue that has been discussed and a plan of attack is well underway and close to completion.
For example, XSP has had known performance issues and this I acknowlege. The developers know what is causing the slowdown and are either working on or have already fixed many of its speed issues. One such issue is the speed at which XSPs are processed. The generation of bytecodes from XSP (much like the concept of servlet bytecode generation from JSPs) is bottlenecked by Xalan.
If you say, "yeah, that's all well and good, but it's too slow now -- I don't care about how fast it's gonna be," I can sympathize. Yes, perhaps I went overboard, but then I tend to believe that you make your interfaces and processes correct first and then focus completely on speed later. This means that over time, your apps get faster just by upgrading the framework in much the same way that native programs get faster when the compiler is updated or with optimizations to a dependant library. As long as your contract is respected (in this case, the contracts are interfaces), this is possible. Here, the contracts are XML, XSLT, XHTML, SVG, the sitemap, etc.
I see the issues with Cocoon 2 today as the same as the issues with C vs. assembly years ago. If someone coded in C when C was functionally complete but not fully optimized, they would run slower than the equivalent assembly (minus development time). On the other hand, when it came time to maintain and/or extend the code, C was easier. And as time went on, the C code "magically" became comparable in speed to assembly with little to no effort (comparatively) with the upgrade of a compiler. Then the machine for which it was originally written falls into disuse. With C, you begin porting. With assembly, you effectively start over again.
In short, if you really can't wait, then your decision is made for you: roll your own (like assembly in the above analogy) or use something else that fits your current needs. If the speed/scalability concerns are not as pressing and you can think about the long haul, Cocoon 2 makes sense (like C in the above analogy).
-----------
Note that my original post was solely with regard to comparisons of Cocoon 2 with Cocoon 1 and roll-your-owns. I explicitly excluded comparisons with Zope or any of its ilk due to my lack of knowledge about them. Right now -- today -- Cocoon 1 is slower than Cocoon 2, and rolling your own will most likely put you on the path that the Cocoon project started walking a few years ago.
My advocacy is not blind. What I said, in a nutshell, was that Cocoon 2.x is currently faster than Cocoon 1.x and probably a better choice than roll-your-own.
And last but not least, if those of you out there go through and read the mailing list archives, you'll find some exciting discussions that rarely (if ever) say that performance is bad and they've hit a brick wall. Or that performance is bad and they don't have a plan to fix it. It is a very active mailing list full of people with ideas and implementations that show Cocoon speeding up by leaps and bounds on a weekly basis.
Most of the posted links that talked about problems are merely that beginning of threads. I encourage people to read the threads in their entirety.
Fair enough. While there is some information on the homepage that addresses your concerns (check the section titled "Management Considerations"), it can seem this way. I guess you only have my word for it when I say that XML is a means for Cocoon, not an end. Without XML, Cocoon no longer exists, but this is like saying that without C, UNIX wouldn't exist. The principles are sound and XML simply enables the implementation of said principles.
Following your list,
1. XML/XSLT is supported by many vendors - so if one implementation sucks, the others may not.
Note: Don't fool yourself. There are implementation quirks in the various J2EE engines. Coupled with the fact that they each encourage use of their own components (many times the reason to choose a particular vendor: their bundled tools), this can be problematic.
2. Servlets are a small part of J2EE. The corralary to Cocoon 2 would be that SAX pipelines are a lightweight framework and XSPs (compiled into generators: the start of a SAX pipeline) offer full, unrestricted access to the Java API.
3. XSLT stylesheets can be written by anyone who knows XSLT. Everyone in my developer network has written an XSLT stylesheet. (Note how subjective this one is)
4. There is a large community of XML and XSLT developers - evidence that it is a sound technology. (I have to take exception to this argument; far more subjective than the last one)
5. As someone who actually develops too, applications through Cocoon *are* a sound technology. (And the opinions continue...)
--------------
Believe it or not, I try to remain pragmatic in my daily dealings with technology. If there were an article with everyone touting the all-powerful qualities of Cocoon 2, please believe that I would be among those trying to assert some reality into the discussion.
And thanks for the vote of confidence, but Cocoon has enough spokespeople in my opinion. The reason you haven't heard from them is that, until recently, they didn't want general distribution. They wanted only the technically-inclined due to the fact that it was a work in progress. Now that 2.0 has been released, I'm sure that you will be seeing a lot more from them.
I agree with your thoughts about business decisions. It is a new technology to a lot of people. I will have bumps in the road. I forget that I've been following their progress for years now and know how to avoid certain pitfalls. Lifelong geek syndrome: knowing a problem set for so long that the solution, no matter how obscure, seems totally obvious. I tend to forget that most people haven't heard of a Cocoon sitemap or what it is used for or (most important) what problems it's supposed to solve.
To me, Cocoon seems solid in much the same way that Linux 2.4.x is solid. It's had its bumps, but lately it's been pretty damed good! But unfortunately, you cannot prove a new platform. Only old(er) platforms can be considered proven. But then, Zope is in the same boat, but maybe only slightly less so.
On the contrary, just about any "roll-your-own" is reinventing the wheel when existing implementations exist. Even at the library level, by your line of reasoning, you wouldn't be reinventing the wheel because you're using the JVM. And on and on until you hit the hardware. Then it's about VLSI vs. aggregate chipsets.
My point is that if you are worried about the maturity of a project, I doubt that a recent roll-your-own is somehow going to be more mature or inherently less of a headache especially when considering open source software and the ability to debug/patch yourself. Is debug/patch of an outside project difficult? Sure, but any in-house project of sufficient size will have its maintainability issues as well. Check out the Cocoon source. It's surprisingly clean considering its size -- they have strongly enforced coding guidelines.
No, not FUD. Just some good, clean, healthy caution.
Do you realize how funny that is? The name of the project did indeed come from the movie "Cocoon." Truth can be stranger than fiction.
Copy cocoon.war to Tomcat's webapp directory. Got to http://[tomcatserver]/cocoon. That's a difficult installation? The only other thing you would have to do is turn debug logging off (or to warn).
I think the installation problems are very overstated.
And Cocoon 1 is NOT faster than Cocoon 2. Not only does Cocoon 2 use less memory (SAX vs. Cocoon 1 using nothing but DOM) to get things done, but it passed Cocoon 1 in speed a while ago. Perhaps the comparisons you made were with Cocoon 2's cache turned off.
This combined with the fact that Cocoon 1 relies on processing instructions with each XML file to get the job done. Believe me, Cocoon 2 is definitely a step up.
Hmmm... Sounds like you're reimplementing Cocoon only badly. Cocoon uses xalan (or saxon or xt or soon xsltc) and xerces (or crimson). It uses FOP to do PDF, Postscript, and PCL output. And they've implemented a kick ass, configurable caching model to boot. But rather than using what others have written that do exactly what you propose, you advocate rewriting from scratch!?! Yeah, good choice.
Once again, the "I haven't used it but I assume it sucks" argument. Cocoon is a servlet in name only at this point. And you don't have to use JSPs with Cocoon. In fact, unless you are migrating from a JSP solution, you shouldn't use JSPs with Cocoon.
Note that you (a) admit to never having even seen it run and (b) confuse it with J2EE. You can use Cocoon with EJBs or you can use it with just a servlet container. It doesn't take very long to install Tomcat, Cocoon, fire up a web browser. Hmm... let me see: Download a JDK, download Cocoon 2 and Tomcat 4, untar Tomcat in some directory, uncompress Cocoon and copy cocoon.war into Tomcat's webapp directory, start Tomcat ($TOMCAT_HOME/bin/startup.sh), and go to http://localhost:8080/cocoon/. Bear in mind that debug-level logging is turned on so performance will suffer somewhat until it's turned down a notch (editing $TOMCAT_HOME/webapp/cocoon/WEB-INF/logkit.xconf and changing every DEBUG to WARN after you get Cocoon running at least once -- then restart Tomcat). But even with debug-level logging, I doubt you will be that disappointed.
But at least try it before saying it sucks.
Has anyone found Cocoon 2 to be unusually slow? I haven't. All the best to AxKit, but they are cloning Cocoon. They were not doing the same thing as Cocoon. They were trying to clone Cocoon. Cocoon is ahead of the development curve here.
I can't speak to AxKit, but you have to be doing a fair amount of stuff off the beaten trail to even have to code Java with Cocoon. This is not to mention that you can also use JavaScript, Python, Velocity, and PHP in addition to just Java with Cocoon. You can talk to a database without using any of them.
Why are you developers worrying about what language it's in rather than getting the job done? If the job calls for Python, use Python. If it calls for Scheme, use Scheme. If your developers will only use C (for example), then you have a problem far greater than your choice of framework.
And they're just trying to clone Cocoon. Most of the time when people use AxKit, they've never actually used Cocoon. They just hear "Java" and whine without seeing if there is indeed a disadvantage/advantage in performance.
And thus you've never tried it, never used it yourself, and are quite content talking out of your ass. The "XML rhetoric" as you put it is the separation of content from presentation and management.
Cocoon 2 has been very well designed and I have little reason to complain about being "boxed in." But at the same time, I don't have to work very hard for it.
Also bear in mind that Cocoon 2 does not remove the ability to use JSPs outside of Cocoon to do CM. You could even use JSPs within Cocoon if you wanted to.
Sounds very much like someone saying "I wrote my own web server and I don't see the need for something like Apache." Who knows? Your own server may work fine for your purposes, but isn't it worth it just to see for yourself and compare before making a final judgement? Which would you rather spend time on: the framework for your site, or your actual site? The more time you spend on infrastructure is the less time you get productive work done.
And those tools are still at your disposal when using Cocoon.
First off, Cocoon 2 is NOT slower than Cocoon 1. Cocoon 2 passed version 1 a while ago. Cocoon 1 with caching is only faster than Cocoon 2 with its cache turned off -- and then Cocoon 1 barely beats Cocoon 2.
;-)
Second, Cocoon 1 works by putting processing instructions in every XML document pointing it to an associated XSLT stylesheet or other secondary processor. So what happens when you want to switch stylesheets for every document in a directory (or a site!). Do you write a script to do it? And what if you want multiple views of the same document? Say on one page, you want a certain subset of data from a XML document dedicated to the band U2, and on another page you want a different subset. Do you split up your document into two pieces? Do you make a copy of the document and worry about redundancy? What if you change your mind later and want to have a different information snippet? This is precisely the sort of thing that Cocoon 2 solves.
With regard to folks claiming that they don't want to use a JSP/Servlet solution, I have a couple of points to bring up. While Cocoon can use JSPs, they were only included so that there would be a migration path. In normal installations, Cocoon does not use JSPs at all. Then again, if you really have a hard-on for PHP, Cocoon can use that as a language for generating XML. It's up to you. In fact, you can write XML generators in PHP, Velocity, JSP, Python, and JavaScript (and of course, Java). You can mix and match. Or you can pull information out dynamically through a relational or XML database. You can generate XML from a directory listing. All without writing a single line of Java code.
And no, just by using Xerces, Xalan, and FOP, you are not going to make something just as good as Cocoon. What if you want to make multiple transformations in the same pipeline (transforming the source XML more than once before it hits the client)? Will you write the code to handle every different case you come across during the lifetime of the site? Or would you rather not reinvent the wheel and just use Cocoon (which handles it very well indeed).
Download it (and a servlet engine like Tomcat) and give it a try. The worst that happens is that you find that you don't like it (Note that it comes with debug logging turned on and will be slower than if you turned it off or to "warn" instead). The best that may happen is that you see how powerful a real publishing and XML processing engine can be.
You can even run it from the command line to pre-generate your site! You don't need the servlet running if that's your preference!
----------
That said, I can't speak to Zope. I've heard good things about it so I'll leave it at that. But don't denegrate Cocoon when you haven't even tried it (which most of the folks who've posted have done). It's not just an XML parser, an XSLT processor and some duct tape. It's much much more! The sitemap alone should be enough to get you to try it. What's a sitemap you ask? Go to the site and find out!
And no, I am not a member of the Apache Software Foundation, nor do I have any affiliation with it other than as a user.
I disagree. No two programs have the same set of configuration needs. Two web servers can have very different configuration options depending upon their focus. While I agree that DTDs are a pain in the ass (DTD entities == XML preprocessor == pain), using something like XML Schema or RELAX-NG would give all the necessary metadata a configuration manager would need. Far more so than some one size fits all or (only slightly better) five sizes fit all.
If the UI can see that you need parameters A, B, and C, there is sufficient description data for the parameter (relatively simple with judicious use of XML namespaces), and can tell that A is supposed to be an integer from 0-100, B is supposed to me a valid email address, and C is an enumerated list of possible values (all possible with existing XML technology -- no need to reinvent the wheel), you will have your UI while allowing a sufficient amount of individualism by the programmer.
And you don't need pre-defined schemas to make object mappings. There is previous work in this area already for the generation of object definitions from XML metadata. Of course this is of most use to the actual programs. The config manager needs to process the metadata in addition to the instance document (the config file).
Come to think of it, a schema document describing UI manager "hints" might not be such a bad idea. It wouldn't tell it what each config entails, but could provide info on how that is to be presented. Nice idea!
Re: LDAP. LDAP is an interface, nothing more. The LDAP spec says nothing about how the datastore should be implemented. In short, you could have your config data in any form you wanted and, as long as it was consistent and documented, publish the information through an LDAP-compliant gateway process.
** mouth waters at the possibilities **
I stand corrected. I haven't tried Mandrake since I got burned by v6.1.
However, compare it to WinXP and not Win98. Comparing to Win98 is like saying Mandrake 8.1 is better than RedHat 4.2. While accurate, it's hardly fair.
Note: I don't use WinXP either. The whole licensing issues surrounding that OS scare the shit out of me.
I meant Ximian and RedHat with regard to Red Carpet. Yes, I'm well aware that apt was (originally) a Debian animal.
Read this message board as part of my job? Only if you consider me trying to get people to standardize so that my job becomes easier because I don't need to learn config file formats in a 1:1 ratio to the programs I use. If that's what you mean, then yes, I posted for my job.
Is someone paying me to browse these boards? Of course not. Most sane employers have better things to do with their money.