|
On 1/23/2014 6:50 AM, Cristiano Gavião
wrote:
Hi Scott,
Sorry for any uncomfortable feeling...
There's no uncomfortable feeling. From my chair this is a public
discussion, not an argument.
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.
Sorry for being slow, but I guess I'm still not clear on what you
are saying. I've also seen the example code below from RFC
206...are you saying that what's there is relatively complex, or
relatively simple?
IMHO, the example code is relatively complex...especially for
programmers that have no prior knowledge of OSGi services, DS,
remote services, Promises, Async services, mediators, etc
(unfortunately still the vast majority of programmers I would
guess). Another thing that I have some concerns about is that the
Async service requires the service consumer to do all the 'work' of
invoking a service asynchronously (inject async service, inject
service ref, create mediator, etc)...and part of that 'work' is that
the consumer will also have to keep track of whether the List
service (e.g.) instance is an async mediator or a sync service in
order to use both (which I assume consumers will likely want to
do). One advantage of ECF's approach for remote
services...IMHO...is that the 'work' of using a remote service
asynchronously can be done by the service creator...and ECF's remote
service impl...rather than the service consumer.
In any event...none of these/my concerns will prevent us/ECF from
using/implementing RFC 206 once it's close to completed...as well as
having our own async service approach for ECF remote services.
Scott
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
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
|
