SUP? I’m good, I have ADC, Ya Know?
October 20, 2006 3 Comments
One of the most interesting features in ADC is the ability to signal that the client or hub support some feature, and that others can take advantage of that. This is not all too different from NMDC’s (hacked) $Supports. In fact, they represent the same thing; The ability to support a particular feature. These features should only be things that are being transmitted between clients and/or to the hub, since it’s no use signaling that you have the ability to have a Notepad built in the client.
There are three ways a client will signal it supports something.
1) To the hub (usually/probably in the initial connection state). Here, hubs may (should) decide to allow clients that support a particular feature the hub owner(s) would want users to have. The hub may restrict clients if the clients signal they support a particular feature, or if they lack the support of another. It’s all very “hey, I support this and that. May I enter?” If the hub sees the clients supporting a feature the hub doesn’t know about, it can/should let the clients through. With ‘should’ in that sentence, the clients have the ability to be up to date with features, while the hub could be extremely old and without any piece of knowledge about the new features. In NMDC, hubs and clients need to be updated when one either are updated with a new feature.
This part is signaled as HSUP ADfeaturename ADanotherfeature. All clients and hubs must support BASE, which is the ADC draft. Every feature must be 4 characters, and all upper case.
2) To all clients, in a broadcast manor (usually/probably in the connection stage). This is signaled in the INF, where you send BINF SUfeature, otherfeature,nfeature. (B == broadcast) As far as I know, there is no way to signal to specifically add or remove a feature in this way, so the client probably need to send the entire feature list. Again, this must be 4 characters and all upper case.
3) To specific client (usually in the connecting stage for a download). Here, you can send the SUP list or the INF list, which ever you find appropriate.
Sometimes, the user (or client) may want to say “hey, I don’t want to support/use this feature anymore, so don’t query me about it”. A simple checkbox in the client/hub can suffice for the meaning of “enable/disable this feature”. This is an interesting feature (in ADC) that NMDC doesn’t. NMDC has no way of saying (while connected to the hub) that the client doesn’t want to support a particular feature. But in ADC, the client can signal that it doesn’t want to support something any time it want to. (Whether the hub will approve of removing a that feature is something else. It may get you kicked out of the hub.)
Clients (and hubs) can signal that it has stopped supporting a feature by using HSUP RMremovethisfeature.
So, let us create a feature, and see what we need to do. Say we want a way to tell people when (you’re) searching that you also want to receive back the entered e-mail the other user got. (Why? Well, I don’t know…)
Now, let us call it SINF (“search inf”), where we have also abstracted it so much that one should be able to “want” anything from the INF. Eg, the client version or the e-mail. So we signal SUP ADSINF (for the hub), and then INF SUSINF (for the clients). Now, we also say that everyone that is able to send the request, should also be able to send the result back. (So we don’t have to come up with another command. Now, whenever we send a search we also signal “EM1”, meaning “give me the information in EM. (EM == e-mail). The other clients that support the SINF feature, will then send back “EMthis.email@example.com”. What is particularly interesting here is that the hub doesn’t have to send the EM1 to every client in the hub. The hub can keep a list of everyone that support SINF, and only forward that part to those clients. There’s no reason a client should get EM1 if it doesn’t even comprehend what that means. A little more hub work == less bandwidth cost for many. (The client, if it see something it doesn’t know, will anyway only discard it.)
There aren’t any particular restriction when signaling. You have to make sure the extension and/or command name is unique, since otherwise it could lead to clashes. And of course that everything transmitted in ADC (command names etc) are always in upper case. Beyond that, what restricts the programmer is the amount of combinations for feature name (A-Z, 0-9) and the programmer’s imagination.
(Yes, I know, I used lower case for the above features, but it didn’t look so nice with upper case, and the blog is weird when it comes to certain brackets…)