XML:
But why use XML? XML should be used for structured data which can potentially be highly complex requiring nesting and/or possible objectification. What you're proposing isn't any of those things, using XML for it would be a waste of time and effort.

Why implement it as an HTTP link? Why not just create a new command for the IRCd or for services and save having to put another excessive peice of code into IRC clients (support for HTTP connections)?

RSS:
RSS may well be a valid system for propogating information, what I'm disagreeing with is that an IRCd should have any place in logging channel activity in any way shape or form. Many people would no doubt see that as intrusive. I sincerely doubt there are channels or users who are going to want to pay to advertise themselves, I think you misjudge the overwhelming majority of IRC users. Chances are the added cost of gathering this info would outweigh any advertising payment.

Winamp 3 and Channel Central:
I'm aware that Winamp 3 uses XML for storing various info although I'm not particularly familiar with the details. I am also aware that Winamp 3 is incredibly slow. I'm not saying that the XML parsing is the cause of this, but it does just go to show just how complex those things stored in XML are, whereas nothing you've proposed comes remotely close to that level of complexity.

Channel central's etc. could all be built dynamically regardless of XML use. To a large degree you could already build a fully working channel central based on the contents of the CHANMODES token in raw 005.

Service=DALnet:
I don't see how stylesheets correllate to what you're suggesting. With stylesheets direct links are given to each item for the purposes of saving time and bandwidth due to caching. With what you've suggested ther is no direct link, simply an indication that the client must connect to DALnet to find another file before it can even continue reading the current one. Caching is possible, but of course things have to be updated sooner or later since IRCds and Services are constantly having updates and fixes released. The same problem comes up with your idea of having "bigger" networks' information supplied with mIRC. So inevitably it would slow down the processing of your original suggestion by forcing an entirely different connection to another IRC server.

Quote:
If you think about how many plain text ugly commands exist within the IRC protocol, it kinda makes you shudder if you want to try and integrate new features.

- I don't really know what you mean by that. IRC is entirely composed of plain text commands. If I found them ugly I wouldn't use IRC.


Quote:
Right now its dead easy to include a google search, or the latest weather, or jsut about anythting on a web site via XML-RPC's.
Try doing that with IRC. You can't merge services in a uniform way and expect other servers to mirror your choices - leading to an ugly mish mash.

- Sorry but I don't see the connection. It's apples and oranges, search engines and IRC services, markup languages and text chat protocols - completely unrelated things.


Quote:
If XML is overlapped onto an IRC server environment, think about all of the integration with other systems you could achieve. Web sites are by far the most popular medium for the web - so why not bring portions of web pages to irc.

Again they're completely unrelated things and I can't see what you mean. If you go to two different webpages with the query string ?variable=value&search=full&keyword=moo then they're not going to interpret that the same way - websites are not interconnected or 'merged' in any way shape of form other than that they most likely use some form of the HTML 1.0-4.01, XML 1.0 + XSL/CSS 1/-P/2/3, or XHTML 1.0-1.1 protocols to do that, just like IRC servers use some interpretation of the IRC protocol. And again neither XML or HTTP has any bearing on any kind of integration between services' syntaxes.