We can always hope…
October 21, 2006 2 Comments
In my last post, I talked about how you added a feature to the protocol and how you signal that you support it. However, you may have gotten the impression that you have to signal that you support something, but this is not true. Even if you support a particular feature, you don’t actually have to signal it.
Let me take an example. In NMDC, there is a distinction (well, not in the protocol, but by the hubs and clients) between “hub topic” and “hub description”. The hub description is used for when a hublist checks you hub, and then displays that description on their website or something. But “topic” is the name of the hub smashed together with the topic, separated with a “-“. (Yes, this is very ugly.) In ADC, there is also no way of saying “this is the topic”. However, due to ADC’s easily extensible interface, it is possible to have the hub send a parameter that isn’t in the base protocol, and one we don’t actually need to advertise we know (before we send it).
There are two possible things the hub can send, depending on whom should get it. Let us think about who would want a topic vs description. 1) the users in the hub or 2) a hublist bot.
To have 1), one would need to change all clients to accept a new parameter. Eg, “TP” (“ToPic”). The hub will then send NIthisismyname DEthis_description_should_be_used_for_hublists TPthis_is_some_random_topic. And if the clients doesn’t understand TP, then they’ll simply ignore it and use the DE-parameter as a topic. This solution’s main problem is that so many clients “need” to change its behaviour and accept TP. This is where 2) is better.
To have 2), one would “only” need to change all hublist bots. Eg, “HD” (“Hublist description”). The hub will then send, instead of TP as in the previous example, but HDsome_description_for_the_hublist. This solution is somewhat better then 1) because there aren’t that many hublist bots that need to be changed. (Heck, at the time of writing, I only know of one hublist bot for the ADC protocol anyway.)
However, the point here is that the hub/client doesn’t need to advertise it supports TP or HD (or any other command or parameter). The client/hub can just send the information, and hope (yes, hope) the other end understand it.