Brian Warner wrote: > Reducing round trips is nice, and being able to reduce our dependence > It seems like in your situation, the pattern is "meet a server once and then do many megabytes of traffic with it", so I don't see why optimizing for round trips is so important. The server can give something like its process id that the clients can use to tell if the server has just restarted with new features. If the client knows this is the same server process that it was talking to for the last 30 minutes, it can assume the feature negotiation is still valid.
The other thing that strikes me about your plan, or at least the email about it, is the amount of effort spent mapping protocol numbers to actual features. If you were relaxed about the time and bytes it takes to do the negotiation, I would think you'd just talk about the features directly instead of making everyone map them back and forth to version numbers. The matrix of which servers work with which clients sounds nice, but in practice won't it grow full of subtle caveats? E.g. "server3 was declared compatible with client6, until 2008-11-14 when we learned that the client was padding a structure that the server would blindly return to all clients, causing client2 to crash. So while server3 and client6 work fine, don't use client6 if there's a possibility of a client2 connecting . . ." Next, I hope you're considering the presence of non-allmydata nodes out there. Your server version number shouldn't be "1.2.0r1234", since you're then inviting each new server to invent its own new scheme for versioning. At least use "allmydata-1.2.0r1234". As an RDF nut, I would suggest making the server versions always be URLs. Then I would go further and say that each negotiated feature should also be a URL. Using URLs makes the values really clear for debugging purposes; you can make them into working URLs that connect to the documentation about the feature; and we'll be able to search the net for any feature URL to find past discussions about it, etc. This topic reminds me of the XMPP negotiation spec, although I don't think it adds anything significant: http://xmpp.org/extensions/xep-0020.html _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
