mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
#56962 23/10/03 04:51 PM
Joined: Jan 2003
Posts: 119
A
AKO Offline OP
Vogon poet
OP Offline
Vogon poet
A
Joined: Jan 2003
Posts: 119
I know that this is an mIRC discussion forum, but eh, I would imagine most of us are pretty advanced IRC users.

I think they ought to have a SERVICES= reported in the beginning connection to the IRCD (where CHANMODES, MODES, MAXBANS, etc. is reported).

This would be good for verification of services of any kind. That way they wouldn't be able to trip. Though the most common is Nickserv,Chanserv,Memoserv,Operserv and X on Undernet. It would be nice to be able to grab that information from the IRCD itself.

Anyone else think this would be an interesting idea? It would prevent wrongful triggering of events.

#56963 24/10/03 04:17 AM
Joined: Oct 2003
Posts: 38
T
Ameglian cow
Offline
Ameglian cow
T
Joined: Oct 2003
Posts: 38
I agree, there should be some way of telling the style of services before sending commands, i've though of this before and i'm sure we're not the only people who have.


-TheXenocide
ParseMPopup
#56964 24/10/03 05:36 AM
Joined: Dec 2002
Posts: 1,527
_
Hoopy frood
Offline
Hoopy frood
_
Joined: Dec 2002
Posts: 1,527
it would make the idea of having an auto identify system with passes built into mirc a whole lot easier to determine what and how to send them. not only it would make ppls services addons very easy to use by knowing what type of services they are u could hide the services types that dont apply to that particular version, as it is now i have mine set to read like

$iif(networkname isin $server,NETWORKNAME Services)
.blah
..blah


well u get the idea, now imagine several networks ud join and since ive added that to my services, even if the network has the same type of services it wont even display the commands. makes things alil frustrating Id love to see this added into the ircd either for mirc to be able to have its own services ident or to make our means easier to script them.


D3m0nnet.com
#56965 24/10/03 07:33 PM
Joined: Jan 2003
Posts: 119
A
AKO Offline OP
Vogon poet
OP Offline
Vogon poet
A
Joined: Jan 2003
Posts: 119
Some IRCDs use /nickserv now ; so my earlier concerns with this a few years ago are answered. But not all do.

Then there are points where some networks in fact use different service names (though it's not very common), and that is what this is aimed to solve.

Most scripts will be in fact coded for the default names, but this can cause some problems with those very specific cases.

On top of this, normal scripts can sometimes be triggered by people using false nicks.

I don't care if I even have to populate the values myself, though it'd be nick to have say $services($network) to return the format of Nickserv,Chanserv,MemoServ,OperServ. Then you can be like

Code:
on *:notice:*:?:{
  if ($nick isin $services($network)) {
    blah blah blah
  }
}


The SERVICES= function could be something like
SERVICES=Nickserv,Chanserv,OperServ,HostServ,MemoServ,AuthServ.

At the very least, you would know that it was default network services that triggered the event.

#56966 24/10/03 08:11 PM
Joined: Dec 2002
Posts: 1,527
_
Hoopy frood
Offline
Hoopy frood
_
Joined: Dec 2002
Posts: 1,527
true altho even if they had something like SERVICES=EPONA1.6 or whatever other version that would be kinda a nice addition as u can then get the services commands to use for that particular servicesi mean really either way would return something for us to be able to figure out what type of commands to use.


D3m0nnet.com
#56967 24/10/03 09:20 PM
Joined: Jan 2003
Posts: 119
A
AKO Offline OP
Vogon poet
OP Offline
Vogon poet
A
Joined: Jan 2003
Posts: 119
Well, with this rate, you could safely use '/msg $nick' and it would not be a problem. Providing the network admins tell server admins to use Q lines, which should be a non issue on correctly configured IRCDs.

#56968 25/10/03 01:37 PM
Joined: Jan 2003
Posts: 119
A
AKO Offline OP
Vogon poet
OP Offline
Vogon poet
A
Joined: Jan 2003
Posts: 119
Well, if you look at that rate, then that would mean you would have an internal document of service names. Some people like to change the default names of the services, and this would then cause a problem.

#56969 25/10/03 03:58 PM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Knowing the names of the service bots could be helpful. But remember knowing that doesn't mean you know the commands or syntax supported.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
#56970 27/10/03 06:37 AM
Joined: Oct 2003
Posts: 38
T
Ameglian cow
Offline
Ameglian cow
T
Joined: Oct 2003
Posts: 38
but if you know that they have ChanServ for instance you can "/msg ChanServ help" and that will tell you the commands/syntax support smile

perhaps tho, there could be a better way of notifying certain command syntaxs easily, this is something i would like to see


-TheXenocide
ParseMPopup
#56971 27/10/03 03:00 PM
Joined: Feb 2003
Posts: 810
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Feb 2003
Posts: 810
This wouldn't be *that* easy from a script, since the language can vary very easily as well. Hence the suggestion of identifying the syntaxes in any other - fixed - way..


* cold edits his posts 24/7
#56972 30/10/03 12:05 AM
Joined: Feb 2003
Posts: 309
C
Fjord artisan
Offline
Fjord artisan
C
Joined: Feb 2003
Posts: 309
I like the SERVICES=XXX suggestion, but what about it being a URI... just like in html, you link to a stylesheet

Have the file written in XML or something derived from it.
<SERVICE title="Uncle Joes Pizza Bot">
<COMMAND action="order" title="Order Pizza" description="This command lets you order a pizza" syntax="nick password email" />
</SERVICE>

That'd let mirc pick it up and fetch it from the URI, and scripters could customise stuff ontop of mircs implementation.
Mirc might jsut build a popup menu system off of it, with a few nity hints, and prompt for input. It could then 'remember' certain stuff

You could also really econmise on stuff by doing something like inheritence, so if your services are identical to dal nets except use 2 different commands, you simply do:
<SERVICE base="Dalnet"> etc.

This Idea excites me smile
oh oh oh...
What about an RSS summary of channels - it'd be a lot slower than a typical list, but it'd let website and so forth integrate with irc better. Perhaps run it all offa an ansi sql db that supports limit and offset so you can 'paginate' results, saving bandwidth.

Just some whacky ideas

#56973 30/10/03 12:27 PM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Since IRC is a simple text protocol it would be massively excessive to use XML for something like that. Simply having a line-per command with tokens would make a lot more sense. Also, having a 'service=dalnet' would be a bad idea, basically all it's done is mean the IRC client now has to somehow find out that information from DALnet. Plus, what does this system really provide? It just means there's now an external source to information that can already be obtained as necessary via /*serv help (assuming a service supports the help command, but then again if they didn't support that why would they support more complex external documentation?).

As for the RSS thing well I don't think that should be done by an IRCd. It should be done by a bot, whether that's a services or user bot doesn't matter, but I would suspect that most networks wouldn't really like the idea of processing statistics for any and all channels that requested it, maintaining a database for it all, and then supplying RSS feeds for anyone who requested it. Seems like a drain on network resources as opposed to each channel using their own bot, recording and providing statistics however they want.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
#56974 30/10/03 03:29 PM
Joined: Feb 2003
Posts: 309
C
Fjord artisan
Offline
Fjord artisan
C
Joined: Feb 2003
Posts: 309
I disagree that XML has no place within IRC.
HTTP + XML have proven to be a robust method of transfering structured data in both a human and machine readble form.

The idea behind adding to the IRC protocol stuff with XML would be not something which is forced down the necks of all IRC clients.
It would again work like a web browser - if your client doesn't know what
Services_URI: http://servername.com:8080/services.xml
means, it would be simply displayed as part of teh MOTD.

RSS is a pretty good model for storing channel information such as topic, users, plus a few other 'smart' statistics about a channel - ie traffic volume, active users in last 5 minutes.
You could build a commercial server which directs clients to look at certain adverts - thus providing some income for the servers in advertising revenue. I could envision this similar to the advert banner in Opera. Channels could advertise themselves on the server, or even individual people if they wanted attention. This would provide a commercial input into IRC, something which it lacks at the moment (and which no doubt adds to its faltering use)

Are you familiar with winamp 3's skin system? I like the idea they have there of an XML based skin & component coupledc to a rendering engine - if IRC clients moved in this direction you could log onto a server and have a channel central, server commands, and all sorts dynamically built.

Quote:
Also, having a 'service=dalnet' would be a bad idea, basically all it's done is mean the IRC client now has to somehow find out that information from DALnet.


Think about what your browser does when you visit a webpage - it applys some system default stylesheet to the webpage. If otherwise directed, it fetches from the server a stylesheet which goes on top of the system default.
Bigger networks could quite easily furnish their own services that could get bundled with Mirc... I can't imagine them coming it at anything bigger than 10kb. Surely, thats not unreasonable to expect a user to cache

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. 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. Users don't know how to access stuff very well and have to remember 4 different basic command sets for every network.
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.

#56975 30/10/03 07:21 PM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
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.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
#56976 31/10/03 04:41 AM
Joined: Feb 2003
Posts: 309
C
Fjord artisan
Offline
Fjord artisan
C
Joined: Feb 2003
Posts: 309
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...


#56977 31/10/03 03:30 PM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Web services have no more in common with IRC services than with a taxi service. Web services use XML because it is a markup language formulated from the same superset as HTML, meaning they share a common syntax but allows them to separate data from presentation. They use XML to allow other websites to use their data. IRC services however have no link with HTML, SGML, or XML, they don't need to share their data across multiple arenas, they represent and work for a single IRC network, nothing more.

If you'll avert you eyes from XML for a few moments you may notice that the basic functions you're suggesting can be obtained in a much simpler and more IRC-centric way:
/*serv syntax command subcommand ... subcommandN
The command returns something in a format like: command syntax: [color:red]token 'string' (token-option|token-option|token-option) [optional-token][/color]
eg.
akick syntax: channel 'add' mask [reason]
akick syntax: channel ('del'|'stick'|'unstick') mask
akick syntax: channel ('list'|'view') [mask]
akick syntax: channel ('enforce'|'clear')

You could even go as far as to have a /*serv grammar command returning a grammar list detailing the format of the token types given in the syntax replies.

Using a system like that you've removed the need for:
- Extra connections to external files
- Segregating documentation from services
- XML parsing
- External protocols altogether

As for your 'other applications', they're really something apart from the IRCd. That is unless you expect different networks to want to automatically share that information. Of course if they did that then opers on one network would to a large extent have oper control over another, which I don't think any network admin would ever want. Whois replies are already structured.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
#56978 31/10/03 09:11 PM
Joined: Dec 2002
Posts: 2,985
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 2,985
Fairdinkum Clockwerx, when you gave those XML examples, you could at least have used the network you use as the example. :tongue:

Personally I think while the general ideas expressed here arn't bad, it is a classic case of over-engineering and does require all IRCd coders and chat programme coders (like say hundreds of them) to shake hands on it for the idea to become usable.

#56979 01/11/03 01:06 AM
Joined: Feb 2003
Posts: 309
C
Fjord artisan
Offline
Fjord artisan
C
Joined: Feb 2003
Posts: 309
Heh.
Overengineering? Perhaps - I like to think of it as 'preparing for future applications'

I don't think it needs world wide agreement. I think it merely needs two or three ircds to start developing. Once they do that, I kinda hope we'll see a IE vs. Netscape cold war expansion happen, instead of the rather stagnant situation we have now.

IRCd's lead teh development of IRC proggies. IRC proggies with scripting support can have scripts - decent scripts, written by professional coders (like C++ers who will stoop down to this level) - that handle 90% of the new features, so even if their author's don't integrate the new features there are addons which exist that do.

As for telstra, I'm rarely on there, skulking around all over the place. I was shocked when I created a room all by my self smile

#56980 01/11/03 02:42 AM
Joined: Dec 2002
Posts: 2,985
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 2,985
IRCd's lead teh development of IRC proggies.

Well that would be logical thinking but try telling Khaled that. He seems to dictate that IRCd coders should listen to client coders and I remind you of what Khaled has said in the past: That IRCd coders need to take into account how their work affects how clients behave. It's a bit like cutlery manufacturers telling the creator of Man how to construct a human mouth.

In all seriousness there will never be 100% compatibility without a team effort from all involved and I doubt it will happen. The first thing an IRCd coder says when he decides to write a server is "What can I change to make my product stand out from the rest? I don't want it to be better, just different." That is why there is soooooooooooooooo many variations of channel and user modes for a start, also different channel prefixes, different mode prefises for nicknames and why some IRCds support IRCX or part thereof and why others don't.

ONe last thing and about your comment on IE v's Netscape: It's hardly a cold war. Netscape still renders pages like a dog's brekky.

#56981 13/11/03 11:35 PM
Joined: Nov 2003
Posts: 2
D
Bowl of petunias
Offline
Bowl of petunias
D
Joined: Nov 2003
Posts: 2
As others may have said, it makes no sense why you cannot make out the default features of a network from the network name. Like we use PHP to find $_GET variables, we should really use $network to find the NETWORK= from VERSION replies. It makes no sense to try and extend the protocol further using an extra variable here and there when there are so many revisions of the IRC protocol around now. I could list a whole heap of them now, and I doubt if the developers of any of them will want to bother coding in a SERVICES argument. I can give an appropriate example where SERVICES is inappropriate (nicely said Deme!):

In terms of services that use ChanServ-genre network services, we find that there are many varients of the software. We have IRCServices, Epona, and Anope which has an extra service, HostServ. They are practically the same by architecture, but to force clients to react to different irc environment settings is a little difficult on the behalf of the scripter - not only does it limit the amount of space a developer of a services pseudoserver has to create features, but it could probably also make it difficult for us to create bindings for all the different types.
Its time we admitted that IRC isnt as basic as it used to be - it has become more diverse, the protocol has had many facelifts in different facets thanks to open source. Lets stick to the basics and keep thinking - I just think adding SERVICES= is a lazy move to stop trying to be diverse in our own scripting techniques :P

The Illusion...

Page 1 of 2 1 2

Link Copied to Clipboard