Slashdot Mirror

The fine folks at Jakarta (the Apache-related server-side Java group) have a product called Watchdog that is an automated test library to verify conformance with the Java Servlet and JSP specs.

Watchdog doesn't define compliance; only the spec does that. But I understand that Watchdog is a great way to check an implementation. At JavaOne today, the Tomcat developers say that they regularly run Watchdog against their implementations to make sure that they don't break anything.

The fine folks at Jakarta (the Apache-related server-side Java group) have a product called Watchdog that is an automated test library to verify conformance with the Java Servlet and JSP specs.

Watchdog doesn't define compliance; only the spec does that. But I understand that Watchdog is a great way to check an implementation. At JavaOne today, the Tomcat developers say that they regularly run Watchdog against their implementations to make sure that they don't break anything.

People seem to think that we need some radical new paradigm in the way we're doing things in order to indicate progress; Microsoft is all too eager to jump in with a spiffy new standard and a handful of TLAs to placate this crowd and keep us all on the frequent-upgrade track. This is not good innovation (and while I'm talking about Microsoft, this isn't either). Sometimes different and more complex doesn't beat tried-and-true. Can't innovation be combining yesterday's solutions with today's needs to make a new product? Why are people so willing to attach the label of innovation on things that are new but not better?

I work in a Microsoft NT / IBM AS/400 / Linux environment. The AS/400 feels archaic, but does what we need it to. Linux feels archaic, but does what we need it to. Microsoft NT looks good.

---

Only without the years of development, the thousands of freely available modules, the extreme flexibility, the massive cross-platform portability (you can configure perl for your toaster), integration with Apache, Database support, tens of thousands of existing experts and freely available sample scripts, a huge set of some of the world's best programming language documentation, and (let's not forget) its own poetry (what other language can claim that?), having the core built by one of the coolest people on earth (read and laugh!).

Maybe Pike is amusing, but next to a language like Perl, is it really needed? And can you really claim that Pike has "character" when you can't even write poetry? (Yes, I am a Perl bigot.)

BTW, Hello world in perl? perl -e 'print "hello, world\n";' on the command line will do the trick. Ha!

David E. Weekly

But remember, they also have released stuff as true open source, like http://jakarta.apache.org which they donated to the Apache Software Foundation. There are quite a few projects springing up on there, actually, but the orginal ones they donated were jakarta-tomcat (implementation of the servlet spec), jakarta-tools, and Ant (cool build tool, much easier to use than Make!). That alone deserves some kudos IMO.

Right on! Every true free software monk knows that money is the root of all evil. Let's break down how the evil has grown over the years.

Linus Torvalds, cute, cuddley, penguin-looking fellow. What does he want? World domination. What does he wish have said domination? Linux[tm]. What's that "tm" stand for? Transmeta, which is a company. World domination will only benefit Transmeta. Linus is but a pawn. Boycott Linux.

Richard Stallman, a lovely character with a front as high priest of the Order of Free Software. He has been known to take donations. What do donations consist of? Money. What is the most evil substance on this planet? Money. This high priest is a charleton, I say! He is as evil as the rest!

Apache, everybody's favorite open source web server. What is the Apache Software Foundation? According to their FAQ, a "not-for-profit corporation." What do they d? Take donations. Another group whose purpose is not to make quality free software, but to create DonateWare. This, my friends, we do not need. With 60+ percent of the web server market, I fear them more than Transmeta.

Sendmail, the ever popular mail transport agent with an odd name. Right on their front page, it says "sendmail[tm]." (Sorry, Slashdot doesn't allow the SUP tags like the page has.) Obviously they are in cohorts with Linus and his merry band of power-mad mind controllers. What do they do on the side? Sendmail Pro. Which this create to bring in what? Money. Tell me once again what is the most evil substance on this planet? Money.

Can I get an "Amen!?"

Miguel de Icaza, creator, dictator, and zoo keeper of many GNOMEs (you know who you are). Why did he create them? Hatred for KDE/Qt. What's he turned the crusade into? Helix Code. (What's up with the first sentance on that page, "leading open source desktop company?" I'd like to see the study that concluded that. Why does ever company have to declare themselves the leader of a one-contestent contest? I'm the leading free software development specialization operation in my apartment, who the heck cares?) What did he create Helix Code for? So people would "Buy Helix GNOME".

I could go on and on. But my point is all software we once thought would be pure has gone the way of the dollar. It truely saddens me to see this happen. Therefore, I call upon all true free software artisans to join me on a tiny desert isle to be named shortly where we will grow our own food, choke our own chickens, and code pure free software. You see, living in places like the United States, Europe, Germany, there are just too many temptations that require money, houses, cars, beer, women. Therefore we will do away with all these in the name of pure free software. Only then can we be one with the computer. Who's with me?

Right on! Every true free software monk knows that money is the root of all evil. Let's break down how the evil has grown over the years.

Linus Torvalds, cute, cuddley, penguin-looking fellow. What does he want? World domination. What does he wish have said domination? Linux[tm]. What's that "tm" stand for? Transmeta, which is a company. World domination will only benefit Transmeta. Linus is but a pawn. Boycott Linux.

Richard Stallman, a lovely character with a front as high priest of the Order of Free Software. He has been known to take donations. What do donations consist of? Money. What is the most evil substance on this planet? Money. This high priest is a charleton, I say! He is as evil as the rest!

Apache, everybody's favorite open source web server. What is the Apache Software Foundation? According to their FAQ, a "not-for-profit corporation." What do they d? Take donations. Another group whose purpose is not to make quality free software, but to create DonateWare. This, my friends, we do not need. With 60+ percent of the web server market, I fear them more than Transmeta.

Sendmail, the ever popular mail transport agent with an odd name. Right on their front page, it says "sendmail[tm]." (Sorry, Slashdot doesn't allow the SUP tags like the page has.) Obviously they are in cohorts with Linus and his merry band of power-mad mind controllers. What do they do on the side? Sendmail Pro. Which this create to bring in what? Money. Tell me once again what is the most evil substance on this planet? Money.

Can I get an "Amen!?"

Miguel de Icaza, creator, dictator, and zoo keeper of many GNOMEs (you know who you are). Why did he create them? Hatred for KDE/Qt. What's he turned the crusade into? Helix Code. (What's up with the first sentance on that page, "leading open source desktop company?" I'd like to see the study that concluded that. Why does ever company have to declare themselves the leader of a one-contestent contest? I'm the leading free software development specialization operation in my apartment, who the heck cares?) What did he create Helix Code for? So people would "Buy Helix GNOME".

I could go on and on. But my point is all software we once thought would be pure has gone the way of the dollar. It truely saddens me to see this happen. Therefore, I call upon all true free software artisans to join me on a tiny desert isle to be named shortly where we will grow our own food, choke our own chickens, and code pure free software. You see, living in places like the United States, Europe, Germany, there are just too many temptations that require money, houses, cars, beer, women. Therefore we will do away with all these in the name of pure free software. Only then can we be one with the computer. Who's with me?

Everything you need is at High Availability Linux.

I too am/have built a B2B exchange on the linux platform and found JServ to be *INCREDIABLE* at HA/Failover safe features.

As for the 2 network cards for each machine, that too is a *VERY GOOD* thing. It allows you to partition out your network traffic to achieve much better response time. For example our network has 2 NICs in each machine. There is "Web Server to Database" network, There is a firewall to webserver network, and we have a seperate network for office web surfing and misc stuff like that. Access to the "WebServer to Firewall" network is handled across the router.

One thing to keep in mind when dealing with DB aware web applications is that unless your code is *VERY POORLY* written the biggest bottleneck will be in network latentcy.

The point in question was whether open-source software meets the hype about reliabilty. Any piece of software in which known bugs go unfixed, does not provide the level of reliability he seeks.
I am force to assume that he avoids Visual C (currently on release 6, with 7 in the pipeline) and MS Office then (now on release NINE!). Any large non-critical project will have bugs. OSS doesn't expect you to pay for them, and will often respond to bug reports with patches and/or workarounds in days - not usually the case for CSS manufacturers, who would prefer you purchased the "upgrade".

If I need to hire a C-compiler developer everytime I find a bug in gcc, then it's probably not a worthwhile investment for me, if I can simply buy a licence for a (non-free) compiler that suits my needs.
You don't - but you don't get to expect fixes to magically appear overnight, either. The whole point is that core-team bugfixes take about as long as a commercial development team does - quick fixes rely on someone hitting that bug, writing together a patch, and folding that back into the pool - the Core team may need to tidy it to avoid it breaking something else, but most of the hard work is done already.

In his mind a working piece of proprietry software is a better choice than an almost-working piece of free software.
and he is right - it is. Users will have to balance out their needs - they can pay money out to purchase a copy of software that has no known bugs (but will have little benefit if they are the ones that find it) or get free software that has known bugs, and either work around them or actively help the fixing process. A big development team shouldn't take the risk of working with known-buggy software, if they can't afford the extra man-days of workarounds and/or bughunting - it is a gamble that the cost of the workarounds will be less than the cost of the expensive commercial software. If he couldn't afford to lose that gamble, he shouldn't have made it.

ESR needs to separate his OSS "work" and his personal web-site more. When he hosts the much praised "The Cathedral and the Bazzar" on the same site as his gun pages, he links them into the same package in the eyes of the reader.
I suspect you are half-right - ESR's "random writings" page were originally just that - ESR's Advocacy of Guns, mixed with ESR's advocacy of OSS and his experiences with meditation, strange languages, and the Hacker Lore. Now that he is "officially" an OSS spokesman, they could well do with their own page. The choice to host them all together was good when they WERE just a bundle of his interests, but now the OSS is his "official" designation, he should consider it "work" not "play".

Apache proves his point. The original basis for Apache was Free Software written at Uni of Illinois (I think)
Pretty close - The apache group started out by collecting together the patches for a Public Domain HTTP server written there; the very first version called "apache" was simply a patched-to-date version. However, it was quickly re-written from scratch, and as far as I know, the current version does not contain code from the original. I will quote (slightly edited - you may wish to look at the Original):

In February of 1995, the most popular server software on the Web was the public domain HTTP daemon developed by Rob McCool at the National Center for Supercomputing Applications, University of Illinois, Urbana-Champaign. However, development of that httpd had stalled after Rob left NCSA in mid-1994, and many webmasters had developed their own extensions and bug fixes that were in need of a common distribution. A small group of these webmasters, contacted via private e-mail, gathered together for the purpose of coordinating their changes (in the form of "patches").
Using NCSA httpd 1.3 as a base, we added all of the published bug fixes and worthwhile enhancements we could find, tested the result on our own servers, and made the first official public release (0.6.2) of the Apache server in April 1995. The early Apache server was a big hit, but we all knew that the codebase needed a general overhaul and redesign. During May-June 1995, Robert Thau designed a new server architecture (code-named Shambhala) which included a modular structure and API for better extensibility, pool-based memory allocation, and an adaptive pre-forking process model. The group switched to this new server base in July and added the features from 0.7.x, resulting in Apache 0.8.8 (and its brethren) in August.
After extensive beta testing, many ports to obscure platforms, a new set of documentation (by David Robinson), and the addition of many features in the form of our standard modules, Apache 1.0 was released on December 1, 1995.

That's it. That's the point. Someone's time/resources went into the patch. Whose? Why? The FSF/OSI/SPI (etc) suggest that the fruit of the funder's resources should be able to be used freely by everyone. Why is that the case? Justify your answer.
It's the same one that ESR gives - if you contribute a single patch to the shared pool, and receive just ONE patch in return, you have broken even; if you get TWO, you have made a profit. If your patch is so wonderful that you could make more from selling it than it would cost you to reproduce every patch you have received for free, then you have lost by adding it to the pool - the whole system only works on the basis that patches you contribute are worthless compared to the whole. What the FSF and kin say is, if you add a small increment of value to what you have received for free, then you should not profit from that portion of the work that you DIDN'T do - if you can make your own work function standing alone, then fine - but if it depends on the work of others and THEY gave freely, why should you profit?

Regardless, you just accepted his point. If such software existed, would you be willing to give up your "freedom" (the source) in order to use it? If so, then your value system is NOT the same as RMS's.
you are right - I am *not* the sort of zealot that RMS is. OSS is *potentially* better than CSS - If there is a OSS alternative, I will gladly work on it, contribute as much of my time as I feel is right, in the hope that it will eventually surpass the CSS product. But I will still be using the CSS product in the meantime - because it is BETTER.

That's because RMS and ESR set themselves up as straw-men.
I would argue the point about ESR - RMS was attacked because he can't consider any other position but Free software - to an extreme few other members of the OSS community would agree with. ESR was attacked for being Pro-Guns - What the hell has that got to do with it?

If OSS is so reliable, why do I get these bugs?
Because it isn't finished - OSS is a work in progress, released to the public. Mind you, I sometimes think MS products are the same, with the distinction you have to pay for them :+)

then does that mean a free product without warranty is morally better than a closed product with warranty?
No, if you think you will suffer losses on the failure of a piece of code, you had better either have 100% confidence in that code, or a legal right to sue for compensation. Problem is, most CSS explicitly denies you that right in shrinkwrap, no-liability-beyond-purchase-price licences that, now you have the DMCA, even restrict you from warning other users that a bug might destroy their businesses too. I invite you to demonstrate to me the morality in that....

>I would be ashamed to have a piece of this quality on my own website
And yet you posted this to slashdot.
Yes I did - if I make a public statement in a forum where there is little or no chance of user dissent (as Bertrand Meyer did in a national paper-based publication) then I am unaccountable; if I post my beliefs in a forum such as this, where you can immediately give your own opinions, prove me wrong publicly if you can, and the very next reader sees not just MY writings, but yours as well - that is a completely different matter. If BM had posted this to Slashdot, I would have disputed his points - but not disputed his morality in making them a pronouncement from the pulpit, as he has done.
--

A better approach is to statically do the base XML to HTML conversion, with JSP (or PHP, mod_perl, whatever) to introduce the final dynamic content. (I.e. convert the XML to a JSP with scriptlet tags for the true run time dynamic content.) Caching algorithms would alleviate this, but I don't see the advantage of doing it runtime, when it works just as well doing it statically. Even with caching, your performance will clearly be better.
----------

I don't know the particulars of your application, but by decoupling the content from the presentation, you gain an enormous amount of flexibility and power.

By creating content as XML, you can now create XSLT scripts to transform that pure content into an arbitrary presentation form. So you can write an XSLT script that transforms your XML content into XHTML or into WAP. This is powerful because now you can serve multiple different requestors with the same content.

There is a project called Cocoon (from the Apache Software Foundation) that does this exact thing. Cocoon itself is a servlet, so it gives you a choice of what servlet engine to run it on. It provides good caching, XSLT transformations, and even a "sitemap", which is a central location for binding look&feels to content.

There is an open source servlet engine that has built in XSLT processing, XPath processing, and XML parsing. It is extremely fast and has a lot of features. It is Resin. I recommend this one. Because this is a full blown servlet engine, you have JSP processing, session support, and it is even a small web server.

Red Hat and a whole other bunch of companies are not aiming at getting paid for the software (which is open source, and thus free), but they do want to get paid for the support and consulting. This model is being adapted at a lot of companies nowadays...
IBM for example, has decided to drop their own webserver development in favor of Apache, because it is far more worthwile selling consultancy and support services and putting resources in that, than it is to invest a lot of money in developing their own webserver, while there is something as apache as the alternative.

Services will become the next cash cow, not software.
--
Okay... I'll do the stupid things first, then you shy people follow.

Here's the correct URL

emulator is, namely, that which emulates (tries to act like, but is not) an origial product.

So the second system to implement an API is the emulator? All X11 servers but the first implementation (incl. XF86) are emulators, right? And all Java VMs other than the first are emulators, right? And the GNU system is a UNIX® system emulator, right? Microsoft IIS is an NCSA-httpd (now Apache Server) emulator?

--

Is it just me, or have these stats left out some fairly large projects suck as Jakarta and Mozilla?

Admittedly I didn't look through everything, but I don't see Jakarta mentioned under the apache author page, nor do I see mozilla under jwz or Netscape's author pages. Am I blind, or are they? :)

And if they did miss these two, (Mozilla alone is a somewhat massive sum of source code) what else are they leaving out?

EJBoss (by Telkel) is one of the OSS EJB container developments that I know of. Others are the efforts at the Apache Foundation and Enhydra.

Hope this helps...

And in other news, following their glowing success in their suits against MP3 dot Com and Napstar dot Com RIAA has decided to "let it ride!", filling suits against Washington University, Necmer Soft, Inc.,The Apache Group, Netscape, and Microsoft. Only Microsoft was available for comment saying, "... this is no different than STAC...", making reference to the buyout and dissolution of STAC by Microsoft a number of years ago.

Gez. Fuck it! Let's sue the whole damned country. (*whisper*) Oh, Metallica is already doing that...

[And people say Communism and Socialism are Evil (tm).]

I'd think it would be even better to separate content, logic (code) and layout? I think it's very bad in current WWW publishing practices that layout and content tend to be mixed.

XML.Apache.Org provides very good solution for this kind of stuff - Cocoon. Except for some performances issues, I've been very content to it. It e. g. offers XSP processor which is similar, but clearly superior approach compared to JSP. They're on way to Cocoon 2 and that should remove most of performance problems.

I'd think it would be even better to separate content, logic (code) and layout? I think it's very bad in current WWW publishing practices that layout and content tend to be mixed.

XML.Apache.Org provides very good solution for this kind of stuff - Cocoon. Except for some performances issues, I've been very content to it. It e. g. offers XSP processor which is similar, but clearly superior approach compared to JSP. They're on way to Cocoon 2 and that should remove most of performance problems.

I'd think it would be even better to separate content, logic (code) and layout? I think it's very bad in current WWW publishing practices that layout and content tend to be mixed.

XML.Apache.Org provides very good solution for this kind of stuff - Cocoon. Except for some performances issues, I've been very content to it. It e. g. offers XSP processor which is similar, but clearly superior approach compared to JSP. They're on way to Cocoon 2 and that should remove most of performance problems.

...and they are both integrated into Turbine, which is an excellent Java framework for building web applications produced by the Java Apache Project. I'm bang into its elegant MVC based architecture and rich utility services. If you're looking at building a servlet based application, look at this before you start or you'll end up rewriting half the code that's in there anyway (except not as elegantly :-)

I completely adhere to build my web-stuff in java servlets or JSP (depends on time and needs, raw coding or hard stuff is sometimes faster to do in servlets), but as they say on servlet central and as my experience (and that of my company is) the seperation of code (logic), content (data) and presentation (style) is not only a desirable feature is greatly improves and optimizes the site.
Take this example: you get telegrams as data, but want them to be put on the site without human intervention, you put them on into a database and use logic and styling to get the data and present it. But now what if the site needs to change be redesigned. Do you recode all the scripts (be they PERL, ASP ,PHP or even (this hurts to write) JSP) using expensive developers or do you just leave it to the slightly cheaper and often faster (not that they are better, just that they work in prepared RAD enviroment) Webdesign department (who can do the redesign directly in the stylesheet).
This is the way to go and it can be acheived already using the brilliant project Cocoon. This is great stuff, based in XML/XSL and even gives availability of scripting using the XSP and the Bean Scripting Framework from IBM`s AlphaWorks. It`s capable of using SQL/LDAP/... data as XML and format it into correct HTML (or whatever) using XSLT (the XSL:FO support is still sketchy) and logic in XSP and BSF.

I'd like to see a persistent scripting language which is a first-class peer of the server process. Yes, I know you can do this with Apache if you load enough modules, but I view that as cruft. Has anyone started over again to create a threaded server which can hold a database connection open without the complexity of, say, Zope, or mod_perl?
-russ

SGML's "takeoff" is pretty well established, friend. You would be hard pressed to find a professional, hot-type emulating typesetting system which does not speak SGML. And as a basis for solid, enterprise level document management system, it's fundamental constructs (and by extension XML's) are unparalleled.
...
The balance of your critique is specific to the desktop platforms and Linux in particular, where the demand for professional-quality type layout and DMS are somewhat limited and, as you say, the popularity and quality of the TeX tools have discouraged innovation.

I think it would be fair to say that all of my critique is specific to desktop platforms, and not just to Linux, either. SGML and XML clearly have a role to play in the world of professional publishing and ``enterprise-level document management systems'', and I acknowledged that role up front. But the specific question asked by Cactvs142 dealt with whether he should write his lab reports using DocBook or TEI, which hardly falls into the areas you describe.

In the world of professional publishing, I suspect that you have either proprietary (and expensive!) software to make creating SGML/XML content not much more complex than writing with a standard word processor (I'm thinking of tools such as Frame, or newspaper systems that provide the user with a terminal complete with specialized function keys to apply styles, etc.) or professionals who are both well versed in and happy to use the raw interfaces. I imagine the same is true for people who have to work with ``enterprise-level document management systems''.

But working with SGML and XML on desktop systems today means working with their raw forms: what tools there are require users to get intimately involved with the internal structures of the systems -- applying tags by hand in a text editor and running obscure command-line tools to generate usable output.

In the world of the average user (corporate or home), however, even command-line interfaces can be scary. People want (and rightly so) an interface like Word's. Users don't want to (or can't) remember obscure tags; they want to write their memos, letters, essays, or lab reports and have the look the way they want; and to not have to do anything more complicated than click on a few buttons and choose some menu items.

Even in the world of the hacker, the current tools for SGML and XML make it harder to use than it needs to be (for instance, it would be nice if psgml-mode switched to a DocBook mode when the DTD in use is DocBook, with a menu containing DocBook tags).

The only tool I'm aware of for editing XML that looks like it might be heading in the right direction (based on the screenshot alone -- the demo isn't much different, given that it doesn't allow you to actually change a document you're viewing) is Conglomerate, and it isn't even close to being ready for public release. If you know of other user-friendly tools, please tell us -- the tools I see at xml.apache.org are all server-oriented, not authoring tools by any stretch of the imagination, and the same seems to be true after a quick search on freshmeat.

When it comes to separating content from appearance, I'm all for it. I do so with both my HTML and LaTeX code. But if SGML/XML editors are rare, tools for creating and editing the style sheets that govern the appearance of those SGML/XML documents don't even seem to be on the drawing board. (Editing text files doesn't count as a user-friendly interface.)

Finally, as for the existence of ``professional, hot-type emulating typesetting systems [that] speak SGML'', it's great that those systems are out there, but just because such systems are available doesn't mean they're universally (or even commonly) used. I'm wrapping up the editing of a book to be published by a fairly well-known technical publisher (a division of a very well-known publisher). The book was written using LaTeX, but the publisher doesn't even want to see PostScript, let alone the LaTeX source; instead, they want the author to print the book out and send them the printed copy. For his last book, the author only had access to a 600 dpi printer, and the quality of the finished book shows that lack. This book will, at least, be printed using a 1200 dpi printer. If a major publishing house is still publishing commercial books in this primitive way, can anyone seriously expect the average business or home user to switch to using SGML or XML for managing far less complex documents?

Initially it is a steep learning curve - but the rewards are worth it. You can have your web designer make up the XSL stylesheets which are then applied to the static or dynamic XML, thus keeping content and design entirely separate.

XML is here to stay: this is how the web should have been from the start.

SGML's "takeoff" is pretty well established, friend. You would be hard pressed to find a professional, hot-type emulating typsetting system which does not speak SGML. And as a basis for solid, enterprise level document management system, it's fundamental constructs (and by extension XML's) are unparalleled. Largely thanks to SGML's age (20+ years), these tools are typically proprietary and originally written for mini's. Ports to current hardware are thin on the ground thanks to the advent of "desktop publishing" and the triumph of the "good-enough" school of page-layout. You may have noticed the diminishing quality of type layout in major magazines and newspapers in the last decade, or perhaps its just I and the other old dogs of the typesetting trade. I digress. The fact is that outside of scientific publishing, where TeX and its children rightfully rule, tools for generating Postscript all speak SGML fluently.

...it would be fairly trivial to create a standard set of such commands (with a new document class or package), and using them consistently...

This is the trivial point of markup languages in general. Agreed that for the exercise of personal writing the overhead of XML/SGML validating and processing is absurd, but in any environment requiring the repurposing of content and/or extensive, multi-authored revisions, the structure/style distinction is vital.

The balance of your critique is specific to the desktop platforms and Linux in particular, where the demand for professional-quality type layout and DMS are somewhat limited and, as you say, the popularity and quality of the TeX tools have discouraged innovation. As to the general transformation of arbitrary SGML/XML, have a look at the W3C's XSLT specification and particularly its implementation at xml.apache.org.

I can't quite see how this system is much different, let alone better, than having to use a TeX system to translate LaTeX source code into other formats.

Neither more nor less, but for LaTeX file formats being proprietary to a particular layout/pagination engine. The dearth of quality free editors should remedy itself shortly. AUCTeX exists thanks to the desire to simplify TeX/LaTeX.

Lastly, it is not that appearance is unimportant, quite the contrary. It is important enough to deserve treatment separate from the management of content. The last time you opened a trade publication of almost any sort, including your O'Reilly books, a financial prospectus, any printed material not devoted to marketing or enslaved by graphic content (which sadly includes most newspapers and magazines, it seems) you saw a document whose content was managed with SGML. Interestingly, many of the latter types of publications which rushed to tools like Quark are now clamoring for XML compliance from these vendors in order to manage their content and streamline its repurposing for the Web.

• are there any other ASP solutions for Apache? I've yet to find one

Hey, there sure are. Joshua Chamas' Apache::ASP, which runs under mod_perl, is probably the best solution. It runs exactly as IIS' ASP does, using the same constructs. It would probably be worth your while to check out.

The full Apache::ASP home page is at http://www.nodeworks.com/asp/, and there is tons of support for it on the mod_perl mailing list (including the author himself).

darren

• are there any other ASP solutions for Apache? I've yet to find one

Hey, there sure are. Joshua Chamas' Apache::ASP, which runs under mod_perl, is probably the best solution. It runs exactly as IIS' ASP does, using the same constructs. It would probably be worth your while to check out.

The full Apache::ASP home page is at http://www.nodeworks.com/asp/, and there is tons of support for it on the mod_perl mailing list (including the author himself).

darren

• It is good when you start the project, you can easily show screens to the customer and start code easily.
• Projects are hard to come to an end. The last part of the project always has a long way to walk. IT's not easy to finish the project.
• It can be very hard to install your finished project in the customer. DLL conflicts all the way with older access or other MS and not-MS apps installed, you have to remove everything before install your own software.
• If you want to upgrade to the latest and newest VB you have to code a lot. If you want to code in two or more different versions of VB you can't . You need to have removable disks, each one with a different VB version.

  It does suck.

  I have made an application for 14 different locations of the same customer and have to install it there. It was a pain and sometimes I must go there because nobody did nothing and the thingie starts having conflicts or because someone installed outlook and it hangs.

  If I had to do it now I'd do a web application in perl

> 2.I can use it from perl, so from Apache and mod_perl

I'm really sorry, I missed the preview and wrote the link wrong: mod_perl

I apologize

What is the fascination with Perl in the *nix world?

What is the fascination with automation, quick development in the *nix world? I can do everything from send mail automatically, to parse my log files at 4:00 in the morning with a couple small scripts and crontab. Compared to other OS, *nix with perl/shell scripts can automate and build bigger applications from smaller ones in a quick and effective manner.

For example, say I want to dial-in to the Internet, download slashdot every morning at 4:00, parse out the crap, format it into latex and send it to my other computer and post it into an sql database. This could be done with *nix and perl in about 3 cans of jolt cola. Name one other OS/launage that could do it in that short of time, and have it work well.

Try that in .bat VB or VC++ and see how many cans of jolt cola it would take you.

I can't fathom it - after all it adds little to what awk and sed have been doing for years.

Uh, have you check out modules in Perl? Can awk or sed interact with a database? Can awk and sed combined send/get email/news? Also if I remeber correctly you can't do basic logic in awk+sed, like 'while' loops and 'if' statements. Also I think awk+sed lack support of things like OOP, arrays, hashes, sub routines, etc..

Perl is ALOT more then a word parser

For more complex tasks than a simple CGI script Perl seems unwieldly, and even now technologies such as ASP and JSP are taking over the server-side processing domain.

Yea Perl is hard, especailly if you look at C, C++, ASM, Java, Perl seems extremely difficult to use. (sacarism).

.ASP, now there is a winner, with it being all open and everything and not controlled by some greedy company, let me get on that bus (sacarism again).

I haven't check .jsp yet, so I won't make any comments on it

Perl is portable, can run Perl on %99.99 of all CGI enabled web servers, what does ASP run on, like 2 maybe 3 servers? Perl can do a hell of a lot more then ASP will ever be able to do, my freind once created a cgi interface to his coffee maker, not really usefull (to anyone but him), but I would have doubts of trying to do that in .ASP. Again, Perl is a REAL programming launage, that can interact with everything from C programs, other perl programs, other perl cgi scripts, coffee makers, databases, network sockets, other Internet services (smtp, pop3, nntp, irc, etc, etc), encrypted data (des, triple des, blow fish, etc, etc) and about any other thing you could possiablly think of

IMHO Perl has no real domain in which it is better than everything else - so why is it so popular? Can someone please tell me?

Have you even use Perl?

1) It is open source

2) It is Free software (as both in beer and speech)

3) You can quickly develop programs/scripts

4) It can "glue" together seemly random and unrelated compounds (ie. sql server and a pop3 email CLIENT, ie. coffee maker and the http protocol)

5) You can choose your "programming sytle". Hate OOPing? Don't use it. Love OOPing? Your in luck. Like OOPing but hate the rules and interactive between objects? Break the rules.

6) Does it have words in it? Does it need to be parse?

7) Does it need to be portable?

8) Does it have to be working before your jolt cola can goes empty?

9) Does it have to be fast?

10) Does it make you laugh when you have more or less "replaced" yourself as a system admin though the use of Perl/crontab?

11) Is it fun to randomly "glue" odd, unrelated and obsecure things together using perl?

12)Sometimes a 5 minute Perl script can save you 120 minutes of boring, manual work

as the saying goes (in the voice of the comic book store owner in the simpsons)

NOW GO AWAY OR I SHALL REPLACE YOU WITH A 10 LINE PERL SCRIPT USING THE ENGLISH MODULE

:)

While you support stable technology such as AOLServer with TCL scripting, under what circumstances would you consider a fancy XML, Java, 3 tiered, buzzword compliant solution such as Cocoon?

Tomcat, from The Apache Group, is really the 100% Java reference implementation of Java Server Pages and servlets. The included web server is very simple but effective, since you can throw in just about any logic in a servlet or JSP to customize the processing.

Getting to my real point...Program in an object orientated fashion. It makes your life much easier. Every program should be built of layers of other smaller files (modules, classes, call it what you will). By doing this you give yourself the ability to work with small files with very specific purposes and because of this you have the ability to create more and more modules (perl) based on the earlier core versions. The Core module all your programs can use (have one that takes care of all your DBI calls). Then to customize your program just write another module (perhaps based on an existing one, or a brandnew one). I don't do much other programming for the web outside of Perl and JavaScript, but I do know that everything can be programmed in an object orientated fashion which makes everyone's lives easier.

yes Perl does have that overhead, but all you need to do it throw in mod_perl and bam...perl caching can be enabled. Dont use CGI, put everything in modules. This way you don't have to execute a CGI everytime, but rather called the cached modules.
And while you're at it, take a look at Gereld Richters Embperl over on perl.apache.org Using HTML::Embperl is great. It makes so many things so much easier. Tables are done for you dynamically, and since it all gets cached, the site can perform optimally

Some techniques that are essential to web development are:

• Write clean code. Straigtforward code that doesn't pull in a lot of extre libraries and functions will run better than spaghetti code.
• Use persistent database connections whenever you can, or use a small fast rdbms like MySQL.
• Caching, caching, caching!
• Turn buffering off whenever possible (e.g., $|++ in perl).
• Use compiled modules/languages whenever possible. Languages and environments like Perl (CGI, not mod_perl), PHP, ASP, and the like are *slow* in comparison to compiled C modules and things like mod_perl, mod_pyapache, and mod_dtcl. As much as people like embedded scripting languages, the fact is the page has to be parsed every time it is run (PHP folks, I mean you!) This makes for fast development (which is definitely important), but not so great for running.
• No JavaScript, no DHTML, no animated GIFs. Yeah, this goes against what a lot of people have been taught about the web, but they slow it the fuck down. A browser having to parse 300 lines of JavaScript (half of which is "if(userAgent == "Mozilla")" crap anyway) is going to be very slow, even on a BFM.
• And, dammit, write good HTML. In fact, don't write HTML, write XHTML. Nothing ruins the effect of a well-thought-out dynamic page than HTML that the browser has to re-render 6 times to lay out correctly. You may think this is not a big deal, but it is, it really is. Take the time to learn XHTML, and your pages will be better for it.

Often, the speed of the web is, in reality, how fast the pages appear to be. This is the most important thing to remember when designing pages that are supposed to be fast.

darren

Some techniques that are essential to web development are:

• Write clean code. Straigtforward code that doesn't pull in a lot of extre libraries and functions will run better than spaghetti code.
• Use persistent database connections whenever you can, or use a small fast rdbms like MySQL.
• Caching, caching, caching!
• Turn buffering off whenever possible (e.g., $|++ in perl).
• Use compiled modules/languages whenever possible. Languages and environments like Perl (CGI, not mod_perl), PHP, ASP, and the like are *slow* in comparison to compiled C modules and things like mod_perl, mod_pyapache, and mod_dtcl. As much as people like embedded scripting languages, the fact is the page has to be parsed every time it is run (PHP folks, I mean you!) This makes for fast development (which is definitely important), but not so great for running.
• No JavaScript, no DHTML, no animated GIFs. Yeah, this goes against what a lot of people have been taught about the web, but they slow it the fuck down. A browser having to parse 300 lines of JavaScript (half of which is "if(userAgent == "Mozilla")" crap anyway) is going to be very slow, even on a BFM.
• And, dammit, write good HTML. In fact, don't write HTML, write XHTML. Nothing ruins the effect of a well-thought-out dynamic page than HTML that the browser has to re-render 6 times to lay out correctly. You may think this is not a big deal, but it is, it really is. Take the time to learn XHTML, and your pages will be better for it.

Often, the speed of the web is, in reality, how fast the pages appear to be. This is the most important thing to remember when designing pages that are supposed to be fast.

darren

Some techniques that are essential to web development are:

• Write clean code. Straigtforward code that doesn't pull in a lot of extre libraries and functions will run better than spaghetti code.
• Use persistent database connections whenever you can, or use a small fast rdbms like MySQL.
• Caching, caching, caching!
• Turn buffering off whenever possible (e.g., $|++ in perl).
• Use compiled modules/languages whenever possible. Languages and environments like Perl (CGI, not mod_perl), PHP, ASP, and the like are *slow* in comparison to compiled C modules and things like mod_perl, mod_pyapache, and mod_dtcl. As much as people like embedded scripting languages, the fact is the page has to be parsed every time it is run (PHP folks, I mean you!) This makes for fast development (which is definitely important), but not so great for running.
• No JavaScript, no DHTML, no animated GIFs. Yeah, this goes against what a lot of people have been taught about the web, but they slow it the fuck down. A browser having to parse 300 lines of JavaScript (half of which is "if(userAgent == "Mozilla")" crap anyway) is going to be very slow, even on a BFM.
• And, dammit, write good HTML. In fact, don't write HTML, write XHTML. Nothing ruins the effect of a well-thought-out dynamic page than HTML that the browser has to re-render 6 times to lay out correctly. You may think this is not a big deal, but it is, it really is. Take the time to learn XHTML, and your pages will be better for it.

Often, the speed of the web is, in reality, how fast the pages appear to be. This is the most important thing to remember when designing pages that are supposed to be fast.

darren

Apache is much better featured web sever thant any other , even for application development is better than domino and IIS.

The thread stuff will allow people run it inside WinNT, in places where linux is banned by policy.

Microsoft kind of had a monopoly as of late WRT performance-wise USABLE XSLT parsers. Now this is about to change with Apache's Xalan-C. IT should be quite fast. See Apache-XML's site.

The best way I found for creating multilingual web sites is with apache + mod_perl + HTML::Mason

1. First, this module helps you a lot to separate content from formatting.
2. Next you put people write content and have a file per language: index_es.html index_uk.html
3. Then when index.html is requested, the default handler reads the browser language preferences and loads the most appropiate.

I have to agree. I have been using PHP for a while and love it, but when I went to work on a site that was optimized for several platforms using HTML, lighweight HTML, WML and HDML I found the same problems you discuss. I have been playing around with Apache Cocoon for a while and though the current version is not there it looks like the next release will. Short of that you might read the cocoon white paper and try to impliment their model using php. (and the publish the libraries for the rest of the world!:)

That document refers to a couple of RFCs:

• RFC 2295: Transparent Content Negotiation in HTTP
• RFC 2296: HTTP Remote Variant Selection Algorithm -- RVSA/1.0

Uhm...moderators, hello?

That post, was in fact, informative. But wasn't its parent even more so? Afterall, as opposed to pointing out the RFC, it pointed to practical information on an implementation of that RFC, in this case, Apache, undoubtably the Web server that Jens is using.

The RFC is for people implementing a Web server. Apache's content negotiation is for people providing resources in multiple languages (among other things). Which of those do you think Jens is? Yes, that's right, the latter. Making the RFCs slightly off-topic.

You may want to check out Apache's MultiViews Option. It's a very handy, little used feature that lets your users chose their preferred language(s) once for all websites, right in their browser. If you enable this option, you have documents with the ISO language code appended to the filename, like index.html.en and index.html.it or banner.gif.en and banner.gif.it (for english and italian, respectively).
The links in the web pages are then without the trailing ISO code:
<IMG SRC=banner.gif>
Very handy indeed. Makes it extra easy to add support for more languages, even after project launch.

I don't like when I ask a question in the context of a certain programming language and get an answer about how I should use a different language, so please understnd I am not advocating one over the other.

I believe it would be a clean approach to use a Java Application server such as JServ or Websphere and take advantage of the multi-lingual capabilities of JAVA on the server-side.

...Or I'll beat you. No kidding.

Seriously, check out Mozilla's approach with XUL and I18N. They separate out the text using entity substitution, and the rest using CSS. And that's a very basic, moderately unsafe way to go about things. A more intelligent way would be to have one XML doctype for your basic document, an XML doctype for your content (of which you would have n instances for each of your n languages), and XHTML for your formatted result. You would also have two XSLT transformations: one to merge in the I18N, and another to merge in the HTML design.

The next release of Apache Cocoon is expected to be very efficient in terms of XML/XSLT processing, but I don't know how it racks up in comparison to hardcoded PHP.

yeah. i think the proper filenames would be index.html.en, index.html.de, etc. Apache will read the appropriate HTTP 1.1 headers and serve the corresponding page. see the Apache documentation on Content Negotiation for more info.

Those looking for multilingual solutions for sites might want to look into making some use of Apache's content negotiation. See http://www.apache.org/docs/cont ent-negotiation.html for more information.

No matter what license code comes under, as long as all of the source code is available (even if it's look but don't touch), problems like this will be prevented by simple code auditing and peer review.

And that's why I'd never trust a piece of Microsoft server software over Apache or Qmail for example. A lot of Microsoft software is relatively stable now (my win2k install hasnt needed rebooting in a month), but so closed and opaque that there's no way whatsoever to audit or confirm that a million backdoors aren't present. One has been found, how many others?!