|
Hi Scott,
thanks for your inputs...
in my user eyes it seems that the complexity will be added more to
the spec implementation. for the final user seems to be an easier
approach than to create two interfaces as I'm doing today ;)
Btw, I could see now that there is another spec changes that will
be related to ECF, RFC-203. will take a look on it later...
best regards,
Cristiano
On 20/01/14 14:15, Scott Lewis wrote:
Hi Christiano,
On 1/20/2014 7:26 AM, Cristiano Gavião wrote:
Hi Scott and others,
other day I was reading the new version of RFC-206 and noted
that the spec got a different path other than the used by ECF.
I could see the use of an
Async Service, an
asynchronous
mediator and use its own Promise class instead Future...
sounds interesting since we don't need to create specific
interface and methods to do asynch calls.
Have you take a look on it ? Could you give me your
impressions about it ?
I've read it. My own opinion is that currently it's fairly
complex (new classes/API...e.g. Promise rather than concurrent
Future, etc)...and therefore requires quite a lot from the service
developer/programmer. I don't think the complexity of the
current RFC is desirable, although the functionality (for both
local and remote services) is obviously desirable IMHO.
Nonetheless, ECF's impl of OSGi Remote Services will certainly
support it...if/when it makes it into the spec. Not sure yet
whether we will do an implementation or share impl efforts with
others (i.e. use Felix/Equinox, etc)...but I would personally
rather share an implementation than do one ourselves.
In either case, we will *also* continue to expose asynchronous
remote services...as described in the tutorial. Not in exclusion
or competition with RFC 206, but rather in addition.
Scott
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
|
