04 Aug, 2009, aidil wrote in the 21st comment:
Votes: 0
David Haley said:
ghasatta said:
I understand the impetus to make it easier on developers by making the packets human readable. However, if you were to look at the IMC2 deployments out there, they all seem to stem from a handful of client libraries. So I think it is fair to assume that the same will be true of IMC3 – namely, a select group of (mostly) competent developers will build libraries that they will then distribute. If the lower-level packet handling is taken care of deep in the bowels of the client libraries, will its readability really give that much of a benefit?

Frankly, I think that most complaints stem from the fact that the format and its semantics are somewhat obscure, and inconsistent. What people really want is clarity, I believe, not necessarily complete human readability.


So, the solution is to properly document IMC2, and fix the inconsistencies.

Obviously, you can design a new protocol that is properly documented, has no ambiguities and so on, but, I'm somewhat afraid that will just result in arguing about preference for specific ways to address perceived problems.

IMHO, it would be better to address the issues in the current implementation and come with an updated specification, that is well published, and leaves little room for interpretation.

Also, while I understand all the calls for servers being extremely strict about the protocol, that quite goes against long standing wisdom among those who design and implement typical protocols on the internet.

You are strict when sending, and tolerant when receiving. That doesn't mean you should accept utterly malformed or ambigious messages, but tolerating things like not mentioning fields when they have a (documented, not assumed!!) default, slight variations on the same message that don't cause ambiguity and so on.

Experience tells that this makes for a much more reliable and usable system then having an extremely strict receiver.

As to my own experience in this, I run one of the intermud 3 routers on the lpmuds.net network. Its not IMC2, but it is similar enough in purpose and when disregarding the protocol details, in how it works generally. If I were 'strict' about some parts of the protocol, virtually no real world client would be able to connect.

Another thing to learn from intermud 3, it is a VERY BAD idea to make assumptions about your clients, in this specific case, the thing called mudmode. It excludes many clients needlessly, and puts quite some burden on those wanting to develop a client for another platform then the one that is counted on.

I've actually had to deal with that since I'm using a platform that doesn't support 'mudmode' and I'll have to emulate it (this is also true for my router).

Some form of structured data however is very desirable. It doesn't have to be as verbose as XML, rather not.

The format from Quixadhal's first example (YAML alike) however isn't that bad. Yes, it is verbose, but, it also allows parsing by a client that never ever saw such a message and wasn't prepared to deal with it. Even if it can't actually handle the packet most likely, it can still provide very useful information to the administrator of the mud (hey, someone is trying to talk to a 'x' service on my mud, but I don't have that.. hmm, what would this 'x' service be?)

Incidentely, I wrote a parser for a very similar format, which was about 1 hour of work :P

It is a big mistake to think that most people will read specs completely, and of those who do read them completely, most won't remember everything.
04 Aug, 2009, David Haley wrote in the 22nd comment:
Votes: 0
aidil said:
That doesn't mean you should accept utterly malformed or ambigious messages, but tolerating things like not mentioning fields when they have a (documented, not assumed!!) default, slight variations on the same message that don't cause ambiguity and so on.

Omitting things with clearly documented default values is not being lax with what you receive, it's following the protocol.

This long standing wisdom applies when you're in the jungle of the internet; in this case we have far more control over what all ends of the communication will be doing.

aidil said:
So, the solution is to properly document IMC2, and fix the inconsistencies.

You can't fix many of these inconsistencies without completely breaking existing clients, or putting horrible backwards compatibility hacks into the servers to detect who is using the new and old version of the protocol.

aidil said:
The format from Quixadhal's first example (YAML alike) however isn't that bad. Yes, it is verbose, but, it also allows parsing by a client that never ever saw such a message and wasn't prepared to deal with it. Even if it can't actually handle the packet most likely, it can still provide very useful information to the administrator of the mud (hey, someone is trying to talk to a 'x' service on my mud, but I don't have that.. hmm, what would this 'x' service be?)

This is assuming that people know to look in the first place for this kind of stuff. I think that this sounds an awful lot like a semantic web pipedream where programs automagically tell who is trying to talk to whom, why, and how.

aidil said:
Incidentely, I wrote a parser for a very similar format, which was about 1 hour of work :P

All of the formats above are easy to write parsers for. The delimited format is in fact even easier than the verbose format…
04 Aug, 2009, Kline wrote in the 23rd comment:
Votes: 0
Random blurb from the IMC discussion: again, why not just implement IRC? While most services prohibit running an IRC server, there is typically no restriction on a client. You can fire up BitchX, or if you're really hardcore, telnet, and connect to an IRC network just fine.

IRC is already well documented on both client and server side, and only clients would need to be written. Even if no one wants to pony up hosting an IRCD there are many free, open networks, and channels natively support keys (passwords) to restrict entry to easily hold one channel as the default chatline, currently ichat.

edit: fixed open bbcode
04 Aug, 2009, aidil wrote in the 24th comment:
Votes: 0
David Haley said:
Omitting things with clearly documented default values is not being lax with what you receive, it's following the protocol.


That depends on the protocol definition. A well designed protocol should allow you to omit such things, but, around 20 years of being a network engineer quite tells me this is rather the exception. If a new IMC3 protocol clearly defines certain defaults and allows omiting them, all the better. I believe however you need a structured data format that is somewhat self descriptive to do this, else it might be very difficult to 'guess' at which information was omitted.

In any protocol that uses some kind of 'fixed' field positions (either 'field X' is the 3rd field or it starts at position 22) this becomes difficult, and requires you to tell the difference between 'empty' and 'default'.

David Haley said:
This long standing wisdom applies when you're in the jungle of the internet; in this case we have far more control over what all ends of the communication will be doing.


I'd turn this around. This gives you much more control over who is in the community.

If you want to support people writing their own clients, then you better deal with that jungle. If you don't wanna deal with that jungle, you are limiting people to using your implementation or a clone of it.

In other words, are you about to design an open network? Then you should apply this wisdom. If you don't, you are by consequence designing a non open network.

This is closely tied to my comment about not making assumptions about clients, at least not about their runtime environment.

David Haley said:
aidil said:
So, the solution is to properly document IMC2, and fix the inconsistencies.

You can't fix many of these inconsistencies without completely breaking existing clients, or putting horrible backwards compatibility hacks into the servers to detect who is using the new and old version of the protocol.


That is a problem when wanting to provide backward compatibility indeed. If you design an entirely new protocol you won't have backward compatibility anyway, so why is that a concern here?

If it is a concern, it is easy to fix for both cases by keeping an IMC2 server around bridged to the new network and listening on a different port.

The reason why I suggest fixing the IMC2 protocol instead is because it eliminates a lot of discussion and allows you to concentrate on the things that are broken instead of trying to design a protocol from Utopia.

David Haley said:
aidil said:
The format from Quixadhal's first example (YAML alike) however isn't that bad. Yes, it is verbose, but, it also allows parsing by a client that never ever saw such a message and wasn't prepared to deal with it. Even if it can't actually handle the packet most likely, it can still provide very useful information to the administrator of the mud (hey, someone is trying to talk to a 'x' service on my mud, but I don't have that.. hmm, what would this 'x' service be?)

This is assuming that people know to look in the first place for this kind of stuff. I think that this sounds an awful lot like a semantic web pipedream where programs automagically tell who is trying to talk to whom, why, and how.


If your client does proper logging, then it is actually quite hard to not see those packets, unless you explicitly don't want to see them.

A descriptive packet format makes it much easier to extend the protocol and helps preventing conflicts between different people extending the protocol at the same time.

Lets just compare:

You decide to extend the protocol with say a net news alike distribution protocol, and you decide to pick a nice out of the way number as packet indentifier. Lets say there are 47 packet types (number chosen randomly), you want a nice number for now, and one that is out of the way, so you use 64.

I at the same time decide to extend the protocol with an smtp over intermud mail protocol, and with the same arguing end up at type 64 as well.

As long as we don't try to talk to eachother and noone tries to implement both our extensions, that is no problem…

Using 'names' for packet types instead doesn't completely prevent the issue, we could both have decided to name our custom packet 'custom'. The chance of this happening is much smaller however.

David Haley said:
aidil said:
Incidentely, I wrote a parser for a very similar format, which was about 1 hour of work :P

All of the formats above are easy to write parsers for. The delimited format is in fact even easier than the verbose format…


The point was that that format is not very difficult to parse, obviously, there are easier to parse formats, but they usually cannot convey structure in a message in a generic way.

While bandwidth is definitely a limited resource, it has been some 10+ years ago that the amount of overhead we are talking about here would be a really serious concern.

A mud like discworld, which easily hits the 100+ players and is part of the i3 network can easily run from a home dsl connection still, despite also using an intermud protocol that has a fair bit of overhead, and using an intermud server that is sending a fair bit of spurious packets.

I find this 'it uses too much bandwidth' argument rather unconvincing.
04 Aug, 2009, David Haley wrote in the 25th comment:
Votes: 0
aidil said:
I believe however you need a structured data format that is somewhat self descriptive to do this, else it might be very difficult to 'guess' at which information was omitted.

In any protocol that uses some kind of 'fixed' field positions (either 'field X' is the 3rd field or it starts at position 22) this becomes difficult, and requires you to tell the difference between 'empty' and 'default'.

Yes, of course. You can't have defaults if field order is relevant, unless emptiness means omission.

aidil said:
This gives you much more control over who is in the community.

If you want to support people writing their own clients, then you better deal with that jungle. (…) In other words, are you about to design an open network? Then you should apply this wisdom. If you don't, you are by consequence designing a non open network.

At worse, assuming that you are completely correct, then we haven't changed the status quo – people either use packaged IMC layers, or they deal with writing their own implementation and struggling with the difficulties involved. At best, I don't think you are correct or are exaggerating the terrible consequences of strictness, and we'll have a sane protocol and easy implementation. The truth is likely going to end up somewhere in between those extremes.

aidil said:
That is a problem when wanting to provide backward compatibility indeed. If you design an entirely new protocol you won't have backward compatibility anyway, so why is that a concern here?

You tell me, you're the one saying we should be staying with IMC2, which means adding backwards compatibility. I'd much rather just dump it.

aidil said:
If your client does proper logging, then it is actually quite hard to not see those packets, unless you explicitly don't want to see them.

IMC typically uses a dedicated connection, so if your port is open in the first place and you connect to the server, it's obvious what is going on. Your scenario of random packets showing up at somebody's door doesn't really apply here.
04 Aug, 2009, aidil wrote in the 26th comment:
Votes: 0
Kline said:
Random blurb from the IMC discussion: again, why not just implement IRC? While most services prohibit running an IRC server, there is typically no restriction on a client. You can fire up BitchX, or if you're really hardcore, telnet, and connect to an IRC network just fine.


An IRC client running from a machine hosted in a datacenter is extremely likely to make some alarms go off since this is 999 out of 1000 times a control channel for a compromised host. If you do this, it is often a good idea to inform your provider of this.

But beyond that..

Kline said:
IRC is already well documented on both client and server side, and only clients would need to be written. Even if no one wants to pony up hosting an IRCD there are many free, open networks, and channels natively support keys (passwords) to restrict entry to easily hold one channel as the default chatline, currently ichat.

edit: fixed open bbcode


Well, it is well documented in its core, but there are a gazillion variations, some allowing nick registration (this almost always requires some kind of out of band login) and channel protection. Also, IRC has a terrible, extremely terrible record when it comes to reliability, security and difficulties of dealing with abusive users.

I should also mention 'netsplit'. Really looking forward to that :)

The big advantages of IRC are scale and years of experience in how to deal with the borkedness of the protocol.
04 Aug, 2009, aidil wrote in the 27th comment:
Votes: 0
David Haley said:
At worse, assuming that you are completely correct, then we haven't changed the status quo – people either use packaged IMC layers, or they deal with writing their own implementation and struggling with the difficulties involved. At best, I don't think you are correct or are exaggerating the terrible consequences of strictness, and we'll have a sane protocol and easy implementation. The truth is likely going to end up somewhere in between those extremes.


I don't want to sound pessimistic, but my take is that the truth is gonna be stuck in endless discussions about reaching protocol utopia.

David Haley said:
You tell me, you're the one saying we should be staying with IMC2, which means adding backwards compatibility. I'd much rather just dump it.


So, where did I say it should be backward compatible?

I said that clarifying and fixing IMC2 would give some practical result in a reasonable time and prevent trying to reach for protocol utopia. This has nothing whatsoever to do with backward compatibility.

So, either I don't understand your comment, or I do understand it but you weren't understanding what I was suggesting.

David Haley said:
aidil said:
If your client does proper logging, then it is actually quite hard to not see those packets, unless you explicitly don't want to see them.

IMC typically uses a dedicated connection, so if your port is open in the first place and you connect to the server, it's obvious what is going on. Your scenario of random packets showing up at somebody's door doesn't really apply here.


I suggest you come look at what it is to run a server on an open, extensible network, and what traffic flows between clients. And no, I don't mean IMC2, but a network that does seperate the jobs of acting on packets and routing them, allows for easy extension of features, and allows nearly random client implementations to connect.

On such a network, client 1 can send a packet to the server that is addressed to client 2. The server will then deliver this packet to client 2, without needing any knowledge about what is in the packet beyond addressing information.

Client 2 will now have to act on this packet. Client 1 however could have guessed wrongly that client 2 supports this packet, and client 2 now has a packet it can't handle.

This won't happen you say?

I see it happen many times a day on the i3 network, at times due to broadcasts, at times due to one client trying to probe another client for extensions, sometimes its human mistakes.

This is of little to no concern if your aim is to design a closed network. If you aim for an open and extensible network, then getting data you didn't count on or have never heard about before is guaranteed to happen.

EDIT: as an aside, if anyone is interested in helping resurrect intermud.org, drop me a pm.
04 Aug, 2009, David Haley wrote in the 28th comment:
Votes: 0
aidil said:
I suggest you come look at what it is to run a server on an open, extensible network, and what traffic flows between clients. And no, I don't mean IMC2, but a network that does seperate the jobs of acting on packets and routing them, allows for easy extension of features, and allows nearly random client implementations to connect.

<words about clients sending stuff>

This won't happen you say?

I see it happen many times a day on the i3 network, at times due to broadcasts, at times due to one client trying to probe another client for extensions, sometimes its human mistakes.

I'm not even sure if we're talking about the same thing anymore. This is all completely irrelevant to the way that IMC works. There's no need to be patronizing if you're working on a completely different problem in the first place. :thinking:

It's a little bit of a red herring to criticize IMC based on experience with a protocol that makes completely different fundamental assumptions.

IMC has a client-server model. That is not, as I understand it, under discussion. So no, I don't think your scenario is terribly likely at all.
04 Aug, 2009, aidil wrote in the 29th comment:
Votes: 0
David Haley said:
aidil said:
I suggest you come look at what it is to run a server on an open, extensible network, and what traffic flows between clients. And no, I don't mean IMC2, but a network that does seperate the jobs of acting on packets and routing them, allows for easy extension of features, and allows nearly random client implementations to connect.

<words about clients sending stuff>

This won't happen you say?

I see it happen many times a day on the i3 network, at times due to broadcasts, at times due to one client trying to probe another client for extensions, sometimes its human mistakes.

I'm not even sure if we're talking about the same thing anymore. This is all completely irrelevant to the way that IMC works. There's no need to be patronizing if you're working on a completely different problem in the first place. :thinking:

It's a little bit of a red herring to criticize IMC based on experience with a protocol that makes completely different fundamental assumptions.

IMC has a client-server model. That is not, as I understand it, under discussion. So no, I don't think your scenario is terribly likely at all.


If the protocol has to be extensible, as has been suggested by more then one participant in this IMC3 discussion, then you can go a few ways:

- The server has to handle every possible extension that people are using.
- The server role is one of a router for packets not aimed at the server directly so clients can use an extension regardless of if the server knows about this extension.

Tells on go from client to server to client. A remote finger request goes from client to server to client. From all I know (from implementing an IMC2 client once some 2 years ago) such things also happen on IMC2, and in case of an intermud tell, the only alternative is direct client to client.

So, the server acts as a router at least for specific things already. I suggest it would be extremely useful to generalize this idea.

And, if you ever looked at the i3 spec and compare it to the imc2 spec, you'll find the differences are far far smaller then you are suggesting here. The different packet format and some implementation details however make a very big difference in things like extensibility (and no, not suggesting mudmode is a good idea, it really is not for various reasons, but, a structured data format IS a good idea for sure)
04 Aug, 2009, Guest wrote in the 30th comment:
Votes: 0
David Haley said:
IMC has a client-server model. That is not, as I understand it, under discussion. So no, I don't think your scenario is terribly likely at all.


Actually his scenario is just as likely to happen as it does/did on I3. Being a client-server model doesn't prevent clients from throwing around packets that other clients don't understand. The current network has that problem now, there are a couple of clients connected using the old code that throw packets out every now and then that none of the new clients support, yet they still arrive. The servers passes them around even though they're no longer part of the protocol.

The same happens in reverse. Things that are now part of the protocol are being thrown at clients that have no idea what the data is for. So they simply don't process it.
04 Aug, 2009, David Haley wrote in the 31st comment:
Votes: 0
Samson said:
Being a client-server model doesn't prevent clients from throwing around packets that other clients don't understand. The current network has that problem now, there are a couple of clients connected using the old code that throw packets out every now and then that none of the new clients support, yet they still arrive. The servers passes them around even though they're no longer part of the protocol.

But if the protocol isn't designed to be extensible with clients able to throw around random packets, the point is moot. Now, if we want to change all of that and make the server some kind of hub for whatever clients care to throw around, that changes things. That said, if we don't want it to be arbitrarily extensible, the server shouldn't blindly pass around packets IMO.

Samson said:
The same happens in reverse. Things that are now part of the protocol are being thrown at clients that have no idea what the data is for. So they simply don't process it.

This doesn't really bother me. If people aren't updating their clients to support the protocol additions, it is highly unlikely that they care about the level of knowledge that aidil seems to think people need.
04 Aug, 2009, Guest wrote in the 32nd comment:
Votes: 0
David Haley said:
But if the protocol isn't designed to be extensible with clients able to throw around random packets, the point is moot. Now, if we want to change all of that and make the server some kind of hub for whatever clients care to throw around, that changes things. That said, if we don't want it to be arbitrarily extensible, the server shouldn't blindly pass around packets IMO.


I can't honestly say if IMC2 was intended to be privately extensible. It was developed long before I even started mudding. The fact that it obviously can be never bothered me enough to modify the servers to drop things that weren't in the spec - a spec that didn't even exist before Xorith and I produced it. The protocol existed for years without anyone even knowing how it all worked inside.

Quote
This doesn't really bother me. If people aren't updating their clients to support the protocol additions, it is highly unlikely that they care about the level of knowledge that aidil seems to think people need.


Never bothered me either. It usually indicates the particular MUD admin doesn't care about the chat link or, as has happened, doesn't even know it's still there. And it's this sort of thing that needs to be considered in the equation. You're going to have plenty of people who won't want to update their clients to the new protocol because what they have works and isn't causing them any problems. Those people are likely to continue wanting to connect and if they're left with no avenue to do so are more likely to just drop it than adopt new code that also involves removing the old.
04 Aug, 2009, David Haley wrote in the 33rd comment:
Votes: 0
Samson said:
You're going to have plenty of people who won't want to update their clients to the new protocol because what they have works and isn't causing them any problems.

This is true if we do pretty much anything, including just changing IMC2's packet format. We just have to accept this as a fact of life, if we want to change anything as opposed to just adding stuff.

If we (for some definition of "we") do our job right, it will be very easy to connect to the new network, possibly with a clean, easy to use library for all the major languages and even codebases. I'm not concerned about migration as a particular problem here: the vast majority of currently active IMC2 MUDs either post here, or are competent enough programmers to stick in a new snippet. And those that aren't are probably using more or less stock FUSS, anyhow.

It's also not out of the question to make an IMC2<->IMC3 bridge.

Samson said:
I can't honestly say if IMC2 was intended to be privately extensible.

It would probably be good to establish this for the new protocol. My intuition is that it shouldn't be. We're designing a chat protocol, not a remote-procedure-calling protocol or anything where MUDs are sending all kinds of complicated information around. Now, some might argue that we should be designing such a thing, but that's a different discussion.

It's a relevant, one, though, because I'm starting to get the feeling that we don't really know what we're actually trying to accomplish here. :smile:
04 Aug, 2009, aidil wrote in the 34th comment:
Votes: 0
Just to be clear about this, its 2 years ago since I last looked at imc2 as a protocol, so I am in no position to critisize it. Also, so far IMC2 has served its purpose quite well for all I can tell, despite there being some generally agreed upon issues with the protocol, else we'd not be having this discussion in the first place.

I am however in a position to suggest things that are common practice for addressing the kind of problems an intermud protocol has to deal with since I have a fair bit of experience in design and implementation of such protocols, so, no reason to get defensive about the IMC2 protocol here :)

(that I decided to involve myself with I3 has a lot more to do with long time involvement with lpmuds then anything else)
04 Aug, 2009, aidil wrote in the 35th comment:
Votes: 0
Samson said:
I can't honestly say if IMC2 was intended to be privately extensible. It was developed long before I even started mudding. The fact that it obviously can be never bothered me enough to modify the servers to drop things that weren't in the spec - a spec that didn't even exist before Xorith and I produced it. The protocol existed for years without anyone even knowing how it all worked inside.


Being privately extensible adds some issues, including that you potentially get a lot more traffic on the servers, and complexity of the protocol. Also, you'd want some registry for extensions probably.

The advantage is that it allows those who happen to have the skills, desire and time to add useful ideas and publish those to do so independently, allowing many more people to build on top of the protocol. You'll need some way to merge back useful extensions into the official protocol for this.

At any rate,


David Haley said:
It would probably be good to establish this for the new protocol. My intuition is that it shouldn't be. We're designing a chat protocol, not a remote-procedure-calling protocol or anything where MUDs are sending all kinds of complicated information around. Now, some might argue that we should be designing such a thing, but that's a different discussion.

It's a relevant, one, though, because I'm starting to get the feeling that we don't really know what we're actually trying to accomplish here. :smile:


Its a very relevant question indeed.

To me the answer seems obvious, you should allow and even facilitate it, but, you are right about first knowing what you are trying to accomplish. If you are designing a pure chat protocol, you don't need it, and it may even be undesirable to have.

The answer seems obvious to me due to the many uses I've had so far for intermud communications beyond chat.

An obvious one, which you could of course support in a chat protocol, is 'live remote who' (ie, it is not cached data, it is data live from the mud from which you wanted to see the who list). This also happens to have been one of the first things that connections between muds were used for, not chat.

Together with one of the co-developers of the mudlib I maintain, I'm currently building an intermud news distribution system, which is somewhat similar in function to old fashioned newsgroups (and no, no binaries allowed… :tongue:). This requires no changes to the routers (our i3 equivalent of imc2 servers), but once the implementation has had some time to settle, it is quite possible to change the routers to make it a fair bit more efficient. (note that I3 already allows news distribution between clients directly, using 'out of band' communications, what we are building uses normal 'in band' communications)

Allowing people to send mail between muds doesn't seem that useful at first glance, but it allows for easy creation of an in-mud bug reporting system that can send bug reports to the maintainers of the codebase being used, something which we intend to implement sometime.

So yes, what is it that you want to achieve here.
04 Aug, 2009, David Haley wrote in the 36th comment:
Votes: 0
aidil said:
To me the answer seems obvious, you should allow and even facilitate it, but, you are right about first knowing what you are trying to accomplish. If you are designing a pure chat protocol, you don't need it, and it may even be undesirable to have.

In practice, it seems that the main usage of IMC2 has been chatting and just chatting. For things like this I am a fan of doing one thing at a time but doing it well, instead of trying to build or use a protocol that does everything with the risk of either never finishing or coming up with something complex (which defeats the initial stated goal here, which was simplicity). I'm sure we all agree that it's far easier to build a chat protocol than one that addresses more or less arbitrary extensibility.
04 Aug, 2009, quixadhal wrote in the 37th comment:
Votes: 0
I'll go ahead and toss the idea of just using YAML out.

The advantages are that it IS readable by humans (even if a bit ugly), it handles complex structures, it can be self-documenting but isn't as bloated as XML. Most importantly, it's available as plug-in libraries for almost any language you'd want to code a MUD in, so the wheel doesn't need to be re-invented again.

Quote
It's a little interesting that you tell me you don't need escaping, and then go on to say that it can't be in the data because "it's been encoded" – I'm not entirely sure how "encoding" a tab is any different than "escaping" it.


Sure, encoding is a form of escaping… but it's simpler to apply. I don't have to care what characters might or might not be "special" today or next year, because everything is switched to a common format. As with YAML, Base64 is available as either standard code, or a simple plug-in for just about every language out there.
04 Aug, 2009, aidil wrote in the 38th comment:
Votes: 0
David Haley said:
In practice, it seems that the main usage of IMC2 has been chatting and just chatting. For things like this I am a fan of doing one thing at a time but doing it well, instead of trying to build or use a protocol that does everything with the risk of either never finishing or coming up with something complex (which defeats the initial stated goal here, which was simplicity). I'm sure we all agree that it's far easier to build a chat protocol than one that addresses more or less arbitrary extensibility.


It is much easier to design a chat only protocol initially, but as is evident from the previous few pages in this discussion, you still have to decide on things like data encoding, escaping, some kind of structure to separate the different fields in a message and such. Also, there seems to be a need to encode ints, strings and lists of those at various places.

You can try to do this yourself, and if you want to, please do so (I'm no stranger to reinventing the wheel just because I enjoyed doing so), but, there are some well tried solutions for this that have existing and tried implementations.

XML is way too verbose to my taste, and has a number of headaches that make me want to forget it exists, so lets skip that one. YAML promises to do the same for this purpose, it can encode strings, integers, lists and key value pairs in non ambiguous and easy to parse form, for which there already exist standard libraries for almost every language you can find. It makes extensibility pretty trivial as long as there is a standardized way to address individual clients (and letting the server do the delivery on behalf of the sending client)

There are some more candidates for this, I'm playing with json objects for something that has similar requirements for what kind of data has to be transfered.

It will lead to a slightly more complex protocol, but existing and tried tools for handling the implementation side of that.

So, from a protocol point of view, you are probably right, a chat only protocol is very likely simpler. I'm not sure you are right from an implementation point of view however.

I also agree with Samson about having to consider those who think IMC2 is quite fine since it is not giving them any problems. You'll have to offer some actual reason for them to want to move I think.
04 Aug, 2009, Davion wrote in the 39th comment:
Votes: 0
After reading all the points and suggestions. What we've come up with seems extremely flexible, and easy to parse! We wont be using YAML because of the requirement for an external lib (trying to make it small, right?)

The current way to handle the packets will be as follows.

packet_name field1:size=value field2:size=value field3:size=value\0

Because all packets will be compressed, it's already going to use a lot less bandwidth than IMC2. This also provides an extremely easy way to parse things by 1) Not required to escape anything 2)With the length of the given argument, be able to read it in in a snap in any language.
05 Aug, 2009, ghasatta wrote in the 40th comment:
Votes: 0
Davion said:
The current way to handle the packets will be as follows.

packet_name field1:size=value field2:size=value field3:size=value\0
Great, I'm all for moving forward. Am I correct in understanding that the following is a potential valid packet?

imc3_msg sender:11=ghasatta@da channel:4=chat msg:80=omg I like this easy to parse format, my code can totally handle field:4=easy !!\0
20.0/51