Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] New tutorial: Building your first Asynchronous Remote Service

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


Back to the top