[dsdp-tcf-dev] RE: TCF communication protocol versioning

["Burton, Felix" <Felix.Burton@xxxxxxxxxxxxx>]

Hi Thomas,

As Martin noted, I do have an action to add version information in the
documents.  However, reading your email I get the impression that your
question is more in regards version information at run-time than in the
documents.  For TCF there are two types of run-time versioning: 

1. Versioning of protocol and service interfaces, and
2. Versioning of the implementation of a client or value-add

Regarding #1: The strategy is to change the name of a service whenever a
incompatible change is made, so for example if a backward incompatible
change is needed on a service named "PhoneBook" is needed its name would
change to "PhoneBook2".  In order to allow older clients that still
relies on the "PhoneBook" service to continue to function, the service
implementation could implement both "PhoneBook" and "PhoneBook2".  In
most cases, the underlying implementation of the two interfaces would
probably be shared, so this would not have a significant footprint
impact.  An alternative way of achieving backwards compatibility is to
have a value-add that translates between the old and the new service.

For changes to the channel protocol or the marshaling of messages we
would like all changes to be negotiated between the peers such that
changes will only take effect of both sides agree to the change.  The
plan is to use special service names to indicate which new features are
supported.

Regarding #2: We have discussed adding a command that returns
information properties about the implementation of a peer.  This
information could include information about the version, vendor and
other things.  This command has not been implemented or documented since
we have not seen a need for it yet.

Hoppe this helps,
Felix

> -----Original Message-----
> From: Oberhuber, Martin
> Sent: Thursday, March 19, 2009 5:54 AM
> To: Thomas Emil Hansen; Burton, Felix; dsdp-tcf-dev@xxxxxxxxxxx
> Subject: Re: TCF communication protocol versioning
> 
> Hi Thomas,
> 
> there is a plan to version the TCF Protocol Specification in a
> fine granular way. Felix Burton has the action item to do that:
> 
>    https://bugs.eclipse.org/bugs/show_bug.cgi?id=269352
> 
> I just created the bug for tracking the effort, but we did discuss it
> on
> the TCF Round Table meeting recently:
> 
>    http://wiki.eclipse.org/DSDP/TCF/Meetings/March_12_2009_Round_Table
> 
> Cheers,
> --
> Martin Oberhuber, Senior Member of Technical Staff, Wind River
> Target Management Project Lead, DSDP PMC Member
> http://www.eclipse.org/dsdp/tm
> 
> 
> 
> 
> Thomas Emil Hansen wrote:
> > What is the version of the TCF communication protocol specified in
> > http://dsdp.eclipse.org/dsdp/tm/tcf/docs/TCF%20Specification.html ?
> >
> > Is there a way, or planned a way, to have versioning as part of the
> > protocol itself? For example, it could be possible for the PC side
to
> > request the target for the version used.
> >
> > Or the target could be allowed to use various versions of the
> procotol
> > in parallel, and the PC side would know, for example by looking at
> the
> > message header, which version the message belongs to. This would
make
> > really good sense if different parts of the target is delievered
from
> > different vendors, each implementing different versions of the
> protocol
> > (you can't expect everyone to upgrade at the same time).
> >