tut-tut

Web S-E-R-V-I-C-E-S provide a reusable resource via XML-RPC. Websites can dynamically add content such as a google search resultset via use of these. Perhaps I didn't make that clear enough.

I'm suggesting that with XML you can achieve a solution which would integrate with what seems to be the future of the web. Sure you can structure data a thousand other ways, but if many, MANY other people/companies/technologies make use of it where's teh sense in swimming against the current?

The RSS digest I had in mind wouldn't be any more intrusive than an activity rating;something akin to
Active Chatters: 10%; Chat Volume: Low; Topic: "Blah"

HTTP is just an example protocol, you could use any recognised method of transfer - thought HTTP is well proven and can be done with a low overhead (think a single GET /filename.xml) - IRC:// would make no sense, quite obviously, FTP:// doesnt cut it either.

Of course I don't think that many people would pay to advertise themselves. Well, maybe I would, just to advertise my new pants. However, if such ideas as banner systems became common place, we might see some more companies put funding into IRC - advertising servers, encouraging users onto it, or just paying for product placement. With a commercial drive behind IRC we might see some revival of it compared to many of the larger IM's.

Winamp 3 (I only recently discovered) doesn't only store data in XML, it builds components entirely from it. Its called WASABI, and its a reasonable idea. I won't go into it here, I suggest you go read up on it at winamp dot com if your interested.
If mirc or other IRC clients were able to do this, imagine how interesting things could be. No longer would mirc script dialogs be entirely for mirc script - you could write one in XML and have it displayed in any IRC client. Of course, you'd have to write mirc script * script interpreters for the clients if their authors didn't include the XML parser features themselves.

How many commands are in your average dalnet service?
Quite a few no doubt. And yes, they are changing alot. But instead of the overhead in typing /help <command> every time you forget how to work it, you'd have it cached.
You'd have a simple RAW sent by dalnet or the current server which told you not only the service file name, but the version.

If your server used Dalnet's services, you could tie to a specific version.

services=Dalnet 1.7.1 01/01/2003
services_url=http://myserver/Dalnet_1.7.1

If Dalnet upgrades services, its not the client which has to connect back to Dalnet and get a new version - it just keeps on using 1.7.1 until told otherwise.
When the current server updates the services it uses, it will take the Dalnet original, merge it with its own additions, and then rehost it - no load on dalnet (1 access), only current server (client accesses).


The mess I mentioned is observable in that network X supports
/ns password while network Y doesn't. It has something different. Every time it changes, adds a new command, or decides to use /zebras are cool password you'd have to relearn it.
XMLerizing a list of services would allow you to pick something and create a list of aliases for it.
IE: <command type="nickserv:identify" name="zebras" values="are cool [password]]>
Meaning that so long as network X and network Y had an entry for type="nickserv:identify" you'd have no troubles.
Its all in teh abstraction that hooks you.

I hope this has cleared some of your confusion about what I intended.

Have you played with the XML DLL on mircscripts? its wonderful - even on a clunky old PII its lightning fast (I use it for reading RSS streams). The problems I encountered were translateing its output into a mirc workable fashion - and it was done with a misuse of hash tables to pretend I had an array.
XML isn't bloaty on the processing side of things, not if you do it right. Sure its got overhead in the bandwidth stakes, and thats always going to be a thorn in its side.
If you compare it to teh rubbish people have had to put up with from non-w3c-html generated by lil jimmy and his i'm-15-years-old-use-dreamweaver-and-run-a-.com, you'll realize that people can indeed put up with bloat.

If your really worried, mirc has started to support $compress() and $decompress(). Its possible to do gzipped content encoding, and isn't $compress teh gzip alog. ? I'm not too sure, so don't tear me to shreds.

I say its still feasible, and an idea certainly worth looking at.

Other imagined applications:
IRC Networks trading blacklists of spam content automatically - rather than a blacklist of ips, regex which matches the adverts.
IRC Networks sharing news - servers might not be linked and on the same network, but think about how it could have been useful to know across almost every network about the 6.12 exploit.
IRC clients could benefit from more structured WHOIS replies, mirc infact would be benefitted by having an 'add info to addressbook' hotlink - WHOISes could be extended out to include a profile of some sort
ie
Dude is DSDF@DAF.com :loser
Profile: http://server/DUDE.xml

Im just kicking around the ideas can, please don't bother shooting down all of them...