Re: [cdt-dev] Changing TCF APIs

["Tarassov, Eugene" <eugene.tarassov@xxxxxxxxxxxxx>]

Hi Ed,

 

> Otherwise I think it could be confusing, because AFAIK, TCF itself has no way to specify an inheritance chain for passing commands from one service to another (e.g. “ProcessesV2 getContext …”).  ProcessesV2 would have to be a free-floating service providing only one command, if I understand correctly.

 

From the protocol point of view, ProcessesV2 (actually it is ProcessesV1, I started numbering from 0) is completely independent service with all new commands.

Inheritance is used only to reduce code size, it does not imply anything beyond that.

 

> Would it be eaiser just to add a new command to [I]Processes directly – startV2() or startEx (windows style) or the like … ? 

 

It would be a bit easier for server side, but more difficult for clients: they would need additional request/response round trips in order to learn the agent capabilities.

Service versioning is opposite: easier for clients, more difficult for servers, and it is a bit faster - clients can check for presence of a service without sending a command.

However, both command versioning and service versioning would work.

I feel that adding and retiring complete services is a bit cleaner way to evolve the protocol then adding commands.

What do you think?

 

Regards,

Eugene

 

---

From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ed.Swartz@xxxxxxxxx
Sent: Monday, February 28, 2011 12:04 PM
To: tcf-dev@xxxxxxxxxxx; dsdp-tcf-dev@xxxxxxxxxxx
Cc: cdt-dev@xxxxxxxxxxx
Subject: Re: [tcf-dev] Changing TCF APIs

Hi Eugene,

 

I was working with Ken and originally complained about this J  

 

I’m not sure extending an interface is a concept that applies to TCF.  Would this just IProcessesV2 just be a convenience for implementors of the Java API? 

 

Otherwise I think it could be confusing, because AFAIK, TCF itself has no way to specify an inheritance chain for passing commands from one service to another (e.g. “ProcessesV2 getContext …”).  ProcessesV2 would have to be a free-floating service providing only one command, if I understand correctly.

 

Would it be eaiser just to add a new command to [I]Processes directly – startV2() or startEx (windows style) or the like … ?  Then when dealing with old agents, a missing command can be diagnosed via the ‘N’ reply.

 

-- Ed

 

 

From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Tarassov, Eugene
Sent: Tuesday, February 22, 2011 11:00 AM
To: TCF Development; DSDP TCF dev list (dsdp-tcf-dev@xxxxxxxxxxx)
Cc: CDT General developers list.
Subject: Re: [tcf-dev] Changing TCF APIs

 

Hi Ken,

 

It looks like time to start versioning service interfaces.

 

How about moving the new command into new interface that extends original service interface:

 

interface IProcessesV2 extends IProcesses {

 

    static final String name = "ProcessesV2";

 

    IToken start(.....);

 

}

 

Clients then can easily check presence of IProcessesV2 and use new command only if available.

This is the versioning scheme that we have planned for TCF originally.

 

What do you think?

 

Regards,

Eugene

 

 

---

From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Schaefer, Doug
Sent: Tuesday, February 22, 2011 7:02 AM
To: DSDP TCF dev list (dsdp-tcf-dev@xxxxxxxxxxx); TCF Development (tcf-dev@xxxxxxxxxxx)
Cc: CDT General developers list.
Subject: Re: [tcf-dev] Changing TCF APIs

Forwarding to tcf-dev.

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of ken.ryall@xxxxxxxxx
Sent: Monday, February 21, 2011 10:57 PM
To: dsdp-tcf-dev-bounces@xxxxxxxxxxx; cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Changing TCF APIs

 

A few weeks back the API in org.eclipse.tm.tcf.services.IProcesses changed. A new version of IProcesses.start was added and the old one deprecated. When I was adapting the EDC sources for this change I realized that the scope goes well beyond the java API change. The format for the TCF "start" command for the Processes service may now be sent to the agent in either the old way or the new one. New agents can easily be revised to handle this, or take advantage or the additional options, but existing agents will at best behave unexpectedly or at worst fail or crash. I don't think a TCF client has any way of knowing which version of "start" is supported by the agent.

 

So changing TCF APIs has more consequences that just changing an API in Eclipse, it may break behavior that existing agents are relying on. So if we want to revise the API to TCF service definitions we need a way to discover what version of a service is supported and not sent it commands in a format it doesn't support.

 

For now EDC will continue to use the old deprecated version of IProcesses.start so it will continue to work with existing agents.

 

- Ken