Slashdot Mirror

Thus, the FreeBSD ports system, now as a cross-platform, globally distributed, cooperative development and distribution system could form a nexus of user freedom and empowerment. What possible significance could .NET have in such a world, where thousands of free software applications can be readily downloaded and configured especially for you, especially for a computer that is optimized according to your own personal needs and desires and none other?

As the Semantic Web is a layered framework, the actual vocabularies you use to describe things are applications of the framework rather than the framework itself.

One such application that might prove useful in what you're tackling is RSS. What you seem to be looking for is a taxonomy against which you can classify things. These are expensive to develop and hence rare, the ODP being one of the few that are public. My advice is, if the ODP doesn't fit, classify by topic yourself (but avoid the mistake of struggling to produce a hierarchical system, this is rarely appropriate). At a later stage you can express equivalences to other folks' categories. Folks on the RSS-DEV mailing list would be happy to share experience of categorization.

Anyone seeking more information as to what the Semantic Web actually is and how it fits together might be interested in some of the articles I've written on the topic, which give an overview both of the vision and of ways you can get started with tools:

• Building the Semantic Web
• Berners-Lee and the Semantic Web Vision
• The Semantic Web: A Primer

-- Edd Dumbill, Editor, XML.com.

As the Semantic Web is a layered framework, the actual vocabularies you use to describe things are applications of the framework rather than the framework itself.

One such application that might prove useful in what you're tackling is RSS. What you seem to be looking for is a taxonomy against which you can classify things. These are expensive to develop and hence rare, the ODP being one of the few that are public. My advice is, if the ODP doesn't fit, classify by topic yourself (but avoid the mistake of struggling to produce a hierarchical system, this is rarely appropriate). At a later stage you can express equivalences to other folks' categories. Folks on the RSS-DEV mailing list would be happy to share experience of categorization.

Anyone seeking more information as to what the Semantic Web actually is and how it fits together might be interested in some of the articles I've written on the topic, which give an overview both of the vision and of ways you can get started with tools:

• Building the Semantic Web
• Berners-Lee and the Semantic Web Vision
• The Semantic Web: A Primer

-- Edd Dumbill, Editor, XML.com.

As the Semantic Web is a layered framework, the actual vocabularies you use to describe things are applications of the framework rather than the framework itself.

One such application that might prove useful in what you're tackling is RSS. What you seem to be looking for is a taxonomy against which you can classify things. These are expensive to develop and hence rare, the ODP being one of the few that are public. My advice is, if the ODP doesn't fit, classify by topic yourself (but avoid the mistake of struggling to produce a hierarchical system, this is rarely appropriate). At a later stage you can express equivalences to other folks' categories. Folks on the RSS-DEV mailing list would be happy to share experience of categorization.

Anyone seeking more information as to what the Semantic Web actually is and how it fits together might be interested in some of the articles I've written on the topic, which give an overview both of the vision and of ways you can get started with tools:

• Building the Semantic Web
• Berners-Lee and the Semantic Web Vision
• The Semantic Web: A Primer

-- Edd Dumbill, Editor, XML.com.

As the Semantic Web is a layered framework, the actual vocabularies you use to describe things are applications of the framework rather than the framework itself.

One such application that might prove useful in what you're tackling is RSS. What you seem to be looking for is a taxonomy against which you can classify things. These are expensive to develop and hence rare, the ODP being one of the few that are public. My advice is, if the ODP doesn't fit, classify by topic yourself (but avoid the mistake of struggling to produce a hierarchical system, this is rarely appropriate). At a later stage you can express equivalences to other folks' categories. Folks on the RSS-DEV mailing list would be happy to share experience of categorization.

Anyone seeking more information as to what the Semantic Web actually is and how it fits together might be interested in some of the articles I've written on the topic, which give an overview both of the vision and of ways you can get started with tools:

• Building the Semantic Web
• Berners-Lee and the Semantic Web Vision
• The Semantic Web: A Primer

-- Edd Dumbill, Editor, XML.com.

XML.com is a good source; I used it a lot the other night during my 2 hour debugging session for my homework. Our textbook is "XML for the World Wide Web" by Elizabeth Castro, from Peachpit Press. I'm not going to link to Amazon.com here; support your local independent bookstore instead!

• XML validator
• Merriam-Webster dictionary
• www.wdvl.com/Authoring/
• WebImage
• gifoptimizer.com
• WS_FTP
• Cute HTML
• CGi documentation

The dictionary and gifoptimizer.com are the ones I use the most.

--
Spelling by m-w.com.

LaTeX is an excellent tool, but it's a tool to organize information into platform-independent documents. These documents are set up using pre-defined types (this is an article, a book, etc.), and then organized following the established structure for that document type. LaTeX then provides a variety of tools to simplify cross-referencing, indexing, and otherwise making logincal use of that information.

Using LaTeX to provide greater control over the layout of information on the Web seems like it would be falling into the same trap that ate HTML -- if you remember, HTML was originally intended to organize information in a logical hierarchy, not make pretty pictures.

The paragraph of links:
At least one other person has already pointed to TeX 2 HTML and LaTeX 2 HTML, so I'll just add that if you're interested in well structured documents on the Web, it is actually true that XML has a lot to offer. And as long as I'm listing sites off like a madman, let's not forget the good old W3C.

Oh, yeah...http://www.latex-project.org...


Coke Is It (1982)

... learn Common Lisp. Seriously. XML is really just S-expressions (in drag, with redundant, overblown syntax - see here; (sorry about the pdf)), so why not use a language designed for munging them?

Perl and XML don't really get along well, primarily because Perl and arbitrarily nested data structures don't really get along well (see here if you want a less biased, but still discouraging opinion).

Strangely enough, Java and XML aren't getting along as well as one would think, if this article on the JDOM project is any indication. Java also has the shifting sands problem - vendor-controlled standards are evil, no matter who the vendor is.

Common Lisp has an ANSI standard that hasn't changed since 1995, open-source multi-threaded web servers that you can add native code to on the fly (see AllegroServe or CL-HTTP) and a lot of other good stuff that I don't have time to list here.

I haven't had a lot of time to study the UDDI spec, but I have been pondering the topic of Open Services for quite some time and my feeling is they will. I like the term Open Services, as Tim O'Reilly calls them, over Web services because this concept is applicable beyond HTML and just the Web.

I think the biggest hurdle at the moment for this concept, is the perception that Microsoft invented this concept (therefore there must be something sinister and evil behind it!) and its tied to just their technology which is just plain off.

The idea of open services where around before SOAP. I haven't done an in-depth genealogy of the concept, but I can tell you Dave Winer at Userland has been evangelizing it for a couple of year now. There is also Allaire's WDDX and in a looser sense RSS and ICE.

Microsoft did initiate the SOAP spec, but have put they have opened it up and submitted to the W3C. They incorporated IBM's feedback which garnered IBM whole-hearted support. IBM released their Java implementation on AlphaWorks and then donated the code to Apache. Even Sun conceded it was a good idea and gave as much of an endorsement as they could stomach for something Microsoft had initiated.

I would even argue that IBM is excelling beyond Microsoft. Well... at least in the developer community. They've yet to release anything commercially or articulated a product strategy that utilizes it. (Typical them.) Microsoft does seem to be betting quite a bit on SOAP/Open Services and going from there.

What I love about this concept (and why I think it will succeed) is that its fairly easy and straight forward to work with. It also is a more concrete way to get all of these different platforms that are deployed to talk to each other. It will just makes developing easier, better and smarter.

The way I read it, UDDI is just a progression in making solutions built on this concept more robust.

For all of those interested in this topic, here are some good background links on the topic that aren't so Microsoft-rah-rah.

• The Network Really Is The Computer
• XML: A Disruptive Technology
• AGENCY.CO M's Flexitecture Methodology
• Meerkat: An Open Wire Service
• XMethods: Web Service Listing
• SOAP::Lite (A lightweight SOAP server written in Perl)
• xml-rpc.com
• soap.weblogs.com
• Apache SOAP

I say just ignore it, and if whatever it is gets big, buy the O'Reilly book.

It's on its way. An author from XML.com has one in the works called Writing Web Services with SOAP.

I say just ignore it, and if whatever it is gets big, buy the O'Reilly book.

It's on its way. An author from XML.com has one in the works called Writing Web Services with SOAP.

I was at this session and there was a very interesting reaction to it from the people I talked to after it was done. It seemed that half were all pumped about perl 6 and the other half left resolved to switch to something else (python being the most mentioned). This surprised me a little.


I got the feeling from Larry's speech that there were desperate measures to be taken. In particular, that conference with the jar throwing because people weren't being excited as much as they use to caught my eye. On the one hand, Perl had it's time in the sun, and things like XML (this article suggests that XML removes a problem that makes perl so useful) and PHP are taking away steam.

On the other, this is an attempt to allow Perl's philosophy to transcend a niche.. Perl is more than string processing.. It's an artists language. But it only is useful so long as people continue solving problems with it (and share those solutions with others).

Personally, I'm going to keep making my pet projects out of Perl, because I'm in love with the language. Recently, I have found myself deviating towards Python because of the clean-ness of OO, exception handling, and generally beautiful syntax. I almost strayed to PHP till I determined that it's horrible for large scale design (completely ignoring performance issues). The idea of super-setting perl restores my faith, however.. Since we have the opportunity to write an entirely new syntax if we choose.. Personalize it to our or our company's needs, and be able to transparently intermix with neighbors.

When Perl6 was first announced, I read on slashdot some that said that they were appauled by various activities.. We're actually losing developers, I'm sure.. And I can't imagine that we're gaining too many (we're still not taught much in academic circles). Still, it was encouraging to hear Larry say that there were a lot of young faces. Perl almost seems to me an older-person's language. It was hip just about the time that I went through school, and to a great extent, it still is.

Let's hope that making working on the perl core is more fun now that they're stream-lining it. Let's hope that perl can reinvent itself.. And for those perl-haters out there (it's all right.. You can admit it openly. :), competition helps evolution of all languages.. Yes, you may gripe when a piece of perl code comes across your desk, but have you never done shell programming? Have you never tried to modify an /etc/... script? You can't tell me that bash is _any_ cleaner of a language than perl.. Or maybe you're part of the MS crowd?

-Michael

XML-aware search-engines can remove the brokering of information by introducing standard DTD's for each industry (such as Real Estate Listing Markup Language (RELML).

We can credit W3C for being forward-looking, but I expect that CSSMP will go the way of WAP.

Perhaps not. I believe the point of this newly crafted subset of CSS2 is to provide a stable reference for useful functions that ought to be in mobile devices (meaning ultra-portable devices with limited display capabilities, and not meaning laptops which might have better display capabilities than many quite old desktop computer layouts with small VGA monitors which are still in use throughout the world).

This area is of keen interest to me, and after the long agony with simple HTML 3.2/4.0[1]+ and with CSS1 through the still not-quite-totally-there CSS2, any way to avoid any more standards wrangling will come as a great relief to those of us who have to actually do this stuff for a living. I'd imagine that XSLT 1.0+ engines will do much of the actual work, and it really helps to be able to more or less reuse all that existing work with a near-exact subset of CSS2.

Anyways, I'm back (in a few minutes, after a little more procrastination) to figuring out how to most efficiently split up parts of (simple for now) XML documents for later Java/Python XML/XSLT processing, while allowing simpler, more immediate PHP 4.0+ XML processing. Argh ....

The most notable places where RDF is presently used for real things (as opposed to "we'd like it to be used here vaporware") include:

• In the dmoz.org Open Directory RDF Dump
• The encoding of rpm2html used at rpmfind.net

The latter is exceedingly relevant, as it represents an encoding of metadata about Linux software packages in RDF form.

Also there's a report from XML.com on an paper presented at XML'99

There's an active XML SIG, with a page on Python org.

There seems to be the idea in much of the open source community that if something uses a GUI, it's not as powerful and flexible as the command line. While the command line is a powerful tool, and will always be necessary for coding(and whoever wants to use it), I think many open source programmers need to start thinking outside the box. This is all not to say that open source can't come up with a good GUI, I think that many open source GUI projects have the potential to be much more flexible and usable than many commercial projects. A good example of this is XMLterm.

That was a very, very good article by Miguel. Unfortunately the first few posts I have read are from posters who obviously didn't read it and instead are making personal attacks at Miguel.

Miguel's article is spot on. I love everything about Unix except the fact that Component Based programming is so underused. If there is only one thing Microsoft has done right, it is the way they have developed and pushed COM. With COM, I can write a piece of software that performs a task (be it a Widget or piece of middleware) and COMify it.
Once this is done, anyone can use it regardless of what language it was written in, fast XML parsers can be written in C++ and used in from Javascript or VB. This way developers of business apps do not have to make the choice between a.) putting up with a slow app or b.) writing one themselves with all the attendant bugs therein especially if they have little C++/C skills, also they can go on towards actually creating their application instead of worrying about if they malloced() enough space for their char*'s.

Lots of *nix people believe this implies laziness but fail to realize that reinventing the wheel dozens of times over is folly.

Example I:
I am currently designing and implementing a project management system on Windows(TM) for a small business with a few of my friends. two of them are *nix hackers and they balked at using an XML based protocol to transfer data between the client and server. Now instead of simply designing our protocol then using one of the dozens of available parsers to do this, they decided that we should invent our own binary protocol and write our own parser to parse it.

Our project involves code written in both C++ and Javascript/ASP. We could have used a single COM based parser to consistly interact with the data both from the C++ and the Javascript code but instead its been 2 weeks and counting and our homegrown parser is still being written, tested and debugged. In my opinion this is nothing but a waste of time. When I ask them why not just use XML and an already existing parser their replies boil down to "It just feels wrong.". The chances that a bug or two will slip through in testing or that there is a buffer overflow in our parser is not unlikely considering that most early versions of parsers written in C++ have a few bugs like this hidden somewhere. in this situation component based programming would have allowed us to focus on building and designing our actual application instead of focusing time and energy on a tangential application.

Example II:
At work a MBA intern asked me if it was possible to create an application that housed a search engine that searched a database of MBA students based on criteria like concentration, work experience, graduation date, etc. and then displayed results with links to their resumes in MSFT Word(TM) or HTML format which could be stored on a CD to give recruiters at career fairs. Their first attempt had been to use VB and Access which turned out to be a disaster because of DLL Hell based issues. My simple solution was for them to store all the students in an XML file and to write a Javascript page that used the COM based XML parser (written in C++) to perform the search. Writing this page took less than 2 hours.

Now they have this search functionality they can press on a CD and give out at career fairs which any recruiter can view without needing more than MSIE 4.0 or greater.
Without Component based programming their request would have been impossible to fill in their time frame and would have also required that the recruiters machines would need to fulfill a stricter set of requirements (like a Webserver being installed or they'd have to install an app).


In conclusion my question is "Why has it taken so long for a major *nix push towards component based technology?". After all we've had CORBA for almost a decade but there hasn't been that much a big push towards components. Frankly I am eagerly awaiting MSFT's .NET for one reason only...cross language inheritance. The thought that my C++ components can be inherited by my Perl, Java or Javascript objects makes me extremely *CENSORED*.
FOOD FOR THOUGHT

xmlterm - The most advanced gui available? Allows you to switch from gui mode to cli mode within the same window without having to use the mouse. Pretty amazing.


Script Editor
- Another example of mozilla put to good use.

You might also check out tha AxKit, if you're thinking of moving towards XML+template processors.

Here's a backgrounder & introduction by the author (Matt Sergeant).

- Barrie

The downside of XML, is that it's compatible with nothing out there browser-wise and so you'd inevitably fall back to a two-formats legacy position, probably involving HTML 3.2 for the lesser stream.

Two points about this.

First, I think there is better XML display support than you might think. Given that you're realistically looking something like a year ahead on this, I don't see why you shouldn't go for the gusto.

You also suggest that going with just XHTML won't require any fall-back position. I'm really not sure that's true. And even if it were true, you could turn an internal XML representation into the traditional, cruftified Slashdot HTML that we and our browsers know and love.

But, having said that, I agree that XHTML (with full CSS) is waaaay better than nothing. Given that Slashdot is News for Nerds, I see no reason why it shouldn't be at least closer to the leading edge with respect to style sheets and standards compliance.

Does Mozilla handle client-side XML yet ? And NO I don't mean the piss-poor CSS implementation that the earlier builds had.

CSS on Mozilla is actually getting quite good. Last I checked, it was like 99% compliant with CSS1. To give credit where credit is due, IE 5 for the Mac is apparently fully compliant (but IE 5.5 for Windows isn't...the irony.)

Anyway, the most recent table of client-side XML performance I've seen is this one on xml.com, by Simon St. Laurent. In brief, Mozilla looks pretty good in this comparison. It's the only browser with XLink support of any kind, and handles a few other small things better than IE. Other than that, it's basically right up there. You mention XSL, but no browser has a standards-conforming XSLT at this point.

More interesting to see will be how well things shape up for CSS2 and DOM support, assuming DOM Level 2 ever gets unwedged. You mention SMIL, but I would have to argue that full CSS2 and W3C-compliant DOM are much more important.

Basically, these views are correct, however, they also seem to miss the point of XSL. :-) XSL is not, nor is it likely to ever be a full-fledged programming language. XSL is a declarative translation language used for converting from XML to other forms of XML and/or HTML.

XSL separates the programming logic of the site from the display logic in a relatively clean manner. The advantage of this is that it allows Designers to use advanced graphic oriented tools such as eXcelon Stylus to develop the look and feel of the site, rather than relying on developers.

You can see an example of an entire site run by XSL/XML at HeadlineW atch.com, where it provides all HTML content, as well as RSS and WAP feeds.

I probably shouldn't be contributing to this tangent, but just to set the record state, Mozilla is not moving to a GTK interface. In fact, it's moving away from it.

Mozilla uses a brand-new, cross-platform toolkit (important buzzwords: XPFE and XUL) that's rendered and scripted, more or less, by the same machinery that renders and scripts web page content.

Granted, under Linux, GTK is currently used to actually draw pixels on the screen, but it's used, more or less, the same way other toolkits use Xlib. Dialog boxes, scrollbars, and geometry management are all implemented in cross-platform toolkit code, and GTK just draw lines, rectangles, and pixmaps, really. For the most part, it just gets in the way, since GTK has different ideas than XPFE about geometry management, styles, and even which widgets should get which events.

Say, maybe this is on-topic! In an ideal world, there.is.only.xul, and GTK, Qt, and Motif are all obsolete. You pick a XUL rendering engine of your choice, tweak your style sheets and pixmaps as needed, and hack away at the totally scriptable GUIs boasted by all your K-RAD XUL APPS. <BL1NK>3l33t h4x0rs 43v3r!!!</BL1NK>

Impressions:
[1] Downloading the program is fast. Getting a browser, mail and news in under 6M (1254 files), is impressive.

[2] click Mozilla.exe --> open browser == 11 seconds. Cool.

[3] Moving my mouse along the pull down menus, considerable lag when I hover over bookmarks (prolly from the 985 bookmarks:).

[4] Pulled down QA and loded the smoke tests. all OK.

[5] Loaded the aphrodite skin. The GO button is a few pixels to low on the tool bar but, It all works well.

[6] Loaded the Sullivan skin. The back ground color looks like something changed. M15 has a darker grey than the background on the buttons.

[7] Loaded xml.com Alert: "the connection was refused when attempting to contact adforce.imgis.com". There's a dialog for every time an image doesn't load. had to press OK 8 times.

[8] Fast...ohmygod fast. Loaded the Jargon file v4.2.0 Jargon.html file from my local drive (2.16M) and saw it on the screen in less than 2 seconds!

[9] Clean interface, standards compliant, and ohmygod fast.

[10] My best regards to the entire Mozilla team and to all that help them with this wonderfull platform. Your quality work shows in all that you do. To those of you who have been waiting for a working browser before you start your mozilla development project . . .come and get it! !
___

www.xml.com has a good startup guide to XML for those who still don't know what it is.

The best thing about it is that it is an open, easy to parse data format. Creating your own apps is easily done in any programming language, so you don't need to rely on other people to create the software for you.

And because an XML Document contains it's own DTD (the rules on what is allowed within a document), others can easily use their own XML software with your data in ways you never intended. Which is a feature, aparently.

But XML is, by definition, abstract. Once you start using it, it might make more sense. Look at it as a structured text file and it might be easier

www.xml.com has a good startup guide to XML for those who still don't know what it is.

The best thing about it is that it is an open, easy to parse data format. Creating your own apps is easily done in any programming language, so you don't need to rely on other people to create the software for you.

And because an XML Document contains it's own DTD (the rules on what is allowed within a document), others can easily use their own XML software with your data in ways you never intended. Which is a feature, aparently.

But XML is, by definition, abstract. Once you start using it, it might make more sense. Look at it as a structured text file and it might be easier

That means the only thing they are missing is you writing the code. Go to it!

A lot of people have posted comments like "I don't really see the problem" or "I don't understand". The problem as stated originally is a bit hard to grasp. How about this, though?

A basic issue with the GNU GPL is that it does not cover the use of the program as a service. This has not mattered until recently. The web has now made it possible to deliver such services to large numbers of people cheaply. Pretty soon we will see more fully-featured applications available over the web (MS Office apps, for example.)

Hypothetically, I will create a new company called "Compile.com". I will take GCC, soup it up a little, and provide a handy-dandy web interface so that individuals can (for a fee, or perhaps supported by advertising) select a target architecture, POST a piece of their own source code, and have a piece of object code returned. A linker would also be provided.

Now, accepting and disregarding for the moment the obvious rebuttals to this proposal (it's slow, people won't want to send their source code across the internet, it's a perfect vehicle for trojan horses), imagine if this were a successful service.

Why bother to install or compile GCC (ever tried it?) when the latest version, with proprietary enhancements, is available this way? I never have to release the source for those enhancements, however, since the object code (of the compiler itself) is never distributed to the end user. I could do this with all sorts of GPL'd software and would not be legally entitled to share any of my modifications, even though I would be profiting from them.

Please do not mention that someone could provide this service using a fully-free version of GCC, and incorporate their own, disclosed implementations of my proprietary enhancements. Of course that is possible, but it is irrelevant. And please don't say things like "we'll boycott them" or "companies live by their reputations". It's precisely because things like that do not always work that the GNU GPL was created. The argument, after all, is about the GPL itself, not about the community's reaction after a violation (of the GPL or of the perceived intentions behind the GPL).

kemokid

PS For an interesting article by Tim O'Reilly on the new possibility of open versus proprietary services, see Where the Web Leads Us.

Looking at any non-trivial XSL stylesheets, you can see what a generally bad idea it is.

My advice would be to use a real programming language with DOM bindings.

XML.com has a good article regarding XSL:XSL considered hamrful.

Note that XML.com also has some pro-XSL articles listed, but they aren't nearly as persuasive.

The bottom line is that the W3 "ordained" XSL to be part of the grand scheme of things, although the technology hasn't been developed in response to any particular problem.

Definitely use XML over HTML. With XML, you can make up your own tag-set that accurately represents the structure of your documents. It would then be trivial for you to write an XSLT (see http://www.w3c.org/TR/xslt) stylesheet to transform your document into HTML (which has very little structure beyond lists and nested 'div' containers) for delivery, complete with auto-generated TOCs, indices, etc.

Then, if you decide to change your HTML style, you can just re-generate it by changing your stylesheet - without touching your content. It's sort of like generating HTML forms out of content in a database.

In terms of internationalization support, XML documents can contain just about any Unicode character. So basically you can write an XML document in practically any language.

Your XML source can capture things like:

12345-67

Whereas in HTML it would be more like:

12345-67, or at best 12345-67

In HTML, the only way to reproduce the 'build-your-own-vocabulary' capability of XML would be to have your whole document be a sea of div> and elements, with their 'class' attribute set to different values. But processing (and reading) such documents would be a real bitch.

A plethora of XML tools are available and tons more are on the way...

I recommend using James Clark's "Xt" (http://www.jclark.com/xml/xt.html) XSLT engine in conjunction with Sun's "Project X" (http://java.sun.com/xml) XML parser.

James was editor of the XSLT spec, and an outstanding programmer. The Sun XML parser has been shown to be the most conformant, and is quite fast.

Both applications are written in Java.

More XML info:

• http://www.oasis-open.org
• http://www.xml.org
• http://www.xml.com

Why Don't you go tell Sun that Star Portal can't work.

Because, according to this press release, StarPortal isn't the sort of "Web-based application" the original poster was citing as a reason why we should all "forget about toolkits". It says

Completing development of StarPortal, a web-based version of the office suite that combines a Java(TM)-based client with the software to enable browser access to office productivity tools.

which appear to be saying it's an application written in Java (see earlier comments in which I note that a Java-based application is just an application written for Java plus some widget set, just as a GNOME application is written in C or C++ or whatever plus GTK+ and a KDE application is written in C++ or whatever plus Qt), not a "web-based application" where you just fill in forms and hit "Submit", as the Web calendar and mail applications some people mentioned are.

Yeah, maybe it's more cross-platform than, say, a UNIX+KDE or UNIX+GNOME application is, but it's not the same sort of application as is, say, Slashdot, that being an example that one of the people to whom I replied gave.

And what about a web based mp3 player? Couldn't they store all the mp3 files on the server and stream to your local machine, saving you from having to find all the mp3s you want and archiving them yourself.

Again, that's not a "Web-based application" any more than an MP3 player that can read files somehow magically becomes "NFS-based" or "CIFS-based" by reading from a file system on a server; the application is a local application, written using some toolkit - toolkits being what the person to whom I originally replied (and who cited Slashdot as an example of "Writing for the Web") said we should "forget".

Are you trying to say that Netscape doesn't have access to your sound card?

No - but if it's playing something itself, it's not as if somebody "wrote for the Web" - they didn't write any application at all to play MP3s, they just used an application that already existed, namely Netscape or a plug-in. If you already have a canned application to perform some function, the mere fact that the canned application happens to be part of a Web browser doesn't mean that, by using that application, you've "written for the Web", it means you haven't had to write it in the first place - that certainly means you don't have to worry about toolkits, but it doesn't help you if that's something Netscape or whatever doesn't do.

Try reading Tim O'reilly's new article on MS vs. Linux.

Oh, you mean this one, which I read several days ago, where he says

Traditional software embeds small amounts of information in a lot of software; infoware embeds small amounts of software in a lot of information. The "actions" in an infoware product are generally fairly simple: make a choice, buy or sell, enter a small amount of data, and get back a customized result.

and

Information interfaces are not as efficient for tasks that you do over and over as pure software interfaces, but they are far better for tasks you do only rarely, or differently each time. In particular, they are good for interfaces in which you make choices based on information presented to you. Whether you're buying a book or CD at Amazon.com, or a stock at E*Trade, the actual purchase is a fairly trivial part of the interaction. It's the quality of the information provided to help you make a decision that forms the heart of the application you interact with.

where he pretty clearly indicates that he does not think that all traditional applications are dead and that CGI scripts will replace them, he indicates that there's a whole pile of new applications for doing new things that are best done with browsers talking to Web servers.

The problem that some people have is that, as, if I remember correctly, Abraham Maslow said, "to somebody whose only tool is a hammer, the whole world looks like a nail". Web-based applications, in the "3270 for the '90s" sense (as somebody described Web stuff several years ago), are cool - but they're not the whole world.

Try reading the original poster's article, which said

Forget toolkits. Linux-only development is a dead-end. Write for the web and maybe you'll make some bucks like CmdrTaco and Jerry Yang.

(without, it appears, bothering to ask what application the submitter of the question was trying to write).

Writing a custom GUI application to do Internet shopping, or calendar management, or library card catalog searching, might be a dumb thing to do now that we have HTTP servers and clients all over the place (although I'm not about to boldly declare that it is foolish; there may well be reasons why some particular such application makes more sense than a CGI script as a solution for some particular problem); nobody's made a convincing case that writing GUI applications in general is no longer necessary now that we have the Web.