On 1/22/2014 5:17 AM, Cristiano Gavião
wrote:
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
;)
I'm a little confused as to what you are saying in the above, but it
seems to me that you are asserting that creating two interfaces (one
with async semantics in addition to one with sync semantics) is
somehow more 'difficult' than using the API specified in RFC-206.
You are of course entitled to your view/opinion, but if that's what
you are saying then I differ with you on your judgment of
'difficulty' (and perhaps 'complexity'). For me, 'complexity' is
not primarily a metric of how many characters of code must be typed
in (by programmer as user), but rather whether something can be
understood (by programmer), has been used before in other contexts
(e.g. the concurrent API)/is familiar, and whether the runtime
behavior can be understood/predicted. By those metrics, it seems
to me that current RFC-206 is relatively complicated (partially
because it's unfamiliar/new concurrent API, and partially for other
reasons).
But of course, both of us are predicting 'understandability' among a
set of people that doesn't necessarily include ourselves. A very
difficult task when it comes to creating API. That's why ECF
remote services will support both approaches...because in the end,
we are all guessing about 'understandability'...at least for others.
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...
Thanks. We already have a branch (rfc1.1) and a set of bugs [1]
that are related to supporting RFC-203. Please contribute to the
discussion and/or implementation if you would like.
Scott
[1]
https://bugs.eclipse.org/bugs/buglist.cgi?list_id=8015377&query_format=advanced&short_desc=%5BRFC%201.1%5D&short_desc_type=allwordssubstr
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
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
|