Re: [ecf-dev] rest api change?

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Thanks Alex.

It was not marked as NoImplement.   It's backwardly incompatible and so a major version increment is required.

There are certainly some clients implementing, but my intention with asking was to find out how many it might affect.

Scott


On 2/7/2013 12:18 AM, Alex Blewitt wrote:

It depends if this was marked as @NoImplement or not. 

If it was, adding a new method is backward compatible and should be fine, with a bump to the minor version. 

If it wasn't, it's backwardly incompatible and so the change should occur with a bump to the major version. 

The I*2 pattern is a way of introducing new methods to interfaces without bumping the major version. 

If its unlikely there are clients implementing this then fixing the API makes sense - but remember to bump the major version to signify a backward incompatible change. 

Alex

Sent from my iPhone 5

On 7 Feb 2013, at 01:40, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:

On 2/6/2013 4:38 PM, Wim Jongman wrote:

Hi Scott,

Would it not be better to deprecate the method and introduce a new interface? 

IRemoteResponseDeserializer2

Best regards,

Wim

I suppose it depends upon what you mean by better.   Since this is an API mistake, I would say it would be better to just fix it...and not have multiple ways of doing the same thing (along with the confusion that comes...e.g. 'which IRemoteResponseDeserializer do I use?').   OTOH, if lots of clients would be broken...causing many difficult fixes, then definitely 'better' would be not breaking things...and allowing the old interface to remain.

That's why I'm trying to get a feel for how much pain this would cause among consumers.  If it's not a lot of pain, better would be to fix it, if it is a lot of pain, then better to do something else.

Scott

On Tue, Jan 29, 2013 at 11:56 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:

Hi Folks,

In order to address this bug:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=320175

I think it's going to be easiest to simply make a change in the org.eclipse.ecf.remoteservice.client.IRemoteResponseDeserializer API:

from

    public Object deserializeResponse(String endpoint, IRemoteCall call, IRemoteCallable callable, Map responseHeaders, String responseBody) throws NotSerializableException;

to

    public Object deserializeResponse(String endpoint, IRemoteCall call, IRemoteCallable callable, Map responseHeaders, byte[] responseBody) throws NotSerializableException;

(just change the responseBody from type String to type byte[]).

This change, however, would constitute a breaking API change, meaning that existing clients would need to recompile (at least).

Could those of you interested in this issue please comment on the bug?   I would like to address this issue at some time, and now/ECF 3.6  would be a reasonable time, I think.

thanksinadvance,

Scott







_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev