Hi Scott,
Sorry for any uncomfortable feeling... When I said "easier" I
just wondering about the number of clicks/type needed to create an
async call when I saw the example below. just it.
I don't have the knowledge to arg more than this, for now... :)
private Async asyncService;
private ServiceReference<List> listRef;
@Reference
synchronized void setAsync(Async async) {
asyncService = async;
}
@Reference(service = List.class)
synchronized void setList(ServiceReference<List> list)
{
listRef = list;
}
public synchronized void doStuff() {
List mediator =
asyncService.createAsyncMediatormediate(ref);
...
}
btw, I saw the links, thanks...
Certainly I'll be contributing with suggestions and feedback for
now, since I'm in charge to integrate a RSA implementation (in
case we choose ECF) with the framework that I'm working, called
Lunifera.
cheers,
Cristiano
On 22/01/14 13:25, Scott Lewis wrote:
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
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
|