Re: [ecf-dev] Remote Service Tooling: Endpoint discovery and import

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

On 4/2/2015 12:29 AM, Wim Jongman wrote:

Yes probably not good English. My understanding was that in computing "mocking" meant to locally imitate a back end object. 

When looking at the ui code, I see that you listen to the RSA to discover a remote service. What I usually do is add the remote properties to a local service but this would not work in this case.

Looking at your answer it is not a trivial task so I will get a couple of pi's out to do the real thing.

I'm not really sure what 'pi's are but I would like to redirect things back to getting this work out and available for Mars consumers, which all has to happen within this month (April)...read right away.   Sure, there are a lot of nice things that can/could/hopefully will be added, but frankly speaking those things are very unlikely to actually happen within the next month (before Mars SR deadlines), and I would like to get something first salvo out in Mars on RS Tooling to aid people doing RS development. 

The Endpoint Discovery view can immediately provide some of that help, and so I would like to get it completed, tested, and deployed before May 1, rather than expend any energies on what admittedly would be nice-to-have, but unlikely to materialize in the next month (BTW, I do consider what I described in response to your original question pretty simple...perhaps not trivial...but relatively simple).

These are the things that have to happen this month for this work to get into Mars:

1) Help with creating icons for the RSA-specific entities that need to be displayed...principally the *Endpoint* entity.  I'm essentially using the 'folder' icon right now (with the remote container id...e.g. ecftcp://localhost:3288/server...for the text).   I would like to have an icon that conveys the concept of 'RSA Endpoint' better than a folder.

2) Help with generalizing the content provider, label provider, and UI model classes.  These are currently inner classes (e.g. 'ENode, EDNode') in EndpointDiscoveryView class.  It would make sense, I believe, to separate these from the EndpointDiscoveryView class, and perhaps even make them available as API, so that other UIs could reuse them.

3) Help with any other features that people would like to see added.

4) Create some reusable code to do the 'import' (i.e. call RSA.importService) and the close/remove of a previously-reported Endpoint.   There are a number of folks that are now apparently doing this in RCP apps using ECF Remote Services (e.g. Peter and Tim) and it would be useful for them an other to potentially re-use the code doing the import and close in their own apps. 

5) Help with refactoring for clarity/simplification and extensibility, use all the best Eclipse UI mechanisms (e.g. commands, e4, data binding) if appropriate, and help with incorporation into the Remote Services perspective [2].

6) Help with the releng and IP (add to features, add necessary notices, etc).

Please join 2 and 3 to participate in helping to get this work out.

Scott

[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=461000
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=463626

Cheers,

Wim 

On Thu, Apr 2, 2015 at 1:14 AM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:

On 4/1/2015 2:05 PM, Wim Jongman wrote:

Nice Scott. Is there way to mock the remote services?

Not sure what exactly you mean by mocking a remote service but since both the client and the host distribution provider can be easily be created/customized, the answer is 'yes'.

From a RS consumer's point of view, what they already get when a remote service is imported is an ECF-dynamically-constructed proxy to the remote service...which typically then uses the distribution provider to marshal and send the method call to a remote host. It's technically trivial to use a alternative distribution provider (or to customize an existing provider) that simply turns around and uses a 'mock object' to implement the proxy, rather than distributes the call to a remote host (using some transport/protocol).

On the host side, it's also quite easy to provide a 'mock object' to export the remote service...meaning that the client distribution would still occur (i.e. the marshalling, etc), but when the call reached the host it would actually be implemented by the mock object.

So in both senses...i.e. a 'mock object' for the consumer/proxy, or a 'mock object' for the host implementation, the answer is 'yes', there is a way to mock remote services.

Scott

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev