On Wed, Aug 26, 2009 at 12:52:52PM -0400, Ethan Blanton wrote: > Derek Scherger spake unto us the following wisdom: > > One discussion that we've had before centers around protocol version numbers > > verses specific features. Iirc SMTP's EHLO command may respond with a list > > of keywords indicating the various optional features that a particular > > implementation supports. > > > > Personally, I think I prefer this scheme over a simple version number check. > > It makes feature support explicit rather than implicit and up to the > > respective parties to infer based on what protocol versions they find. > > This makes more sense when you have multiple interoperating > implementations based on different code bases or with differing > requirements ... do you anticipate that there will be multiple > implementations of netsync which need to negotiate individual > features? If not, it's just extra complexity.
That's the main reason why things like the OSI session protocol (which I still think is one of the more useless protocols on the planet) had a whole suite of options -- different implementations might have different availabilities. But there's another reason for having options, even with only one versino of one implementation. A given installation may decide to restrict a particular feature for policy, administrative, or security reasons. Then netsync would have to negotiate accordingly. But I'm not sure this is a realistic situation for the present, and there's the risk that an option notation we choose now may not be sufficiently future-proof. We can use a simple version number check for now. If we ever want a set of optional features (have I got this right?) we can bump the version number and everyone who understands that version number will know to check for optional features. In any case, even if we do have a set of optional features to negotiate, I'd still argue keeping the version number as well, because we'd have to bump it if we ever needed a new coding for the optional features. Anyway, what I've been proposing here is the minimum that's necessary for us to be able to negotiate protocol versions in the future. A sort of protocol ID bootstrap, as it were. And that's a version number. (actually, one bit would do, but that's probably unnecessarily compact, and not as convenient if you have more than one protocol change.) -- hendrik _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
