| Re: [ecf-dev] Remote Service Tooling: Endpoint discovery and import |
Cool Scott, great work. I was working on this icon as the endpoint icon.On Mon, Apr 6, 2015 at 11:49 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:On 4/2/2015 8:52 AM, Scott Lewis wrote:
Over the weekend I made significant progress on the Endpoint discovery view, specifics below:
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.
I created icons for the Endpoint entity and added them to the project at [1].
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.
I've generalized the content provider so that it uses the IAdaptable/IWorkbenchAdapter patterns that allow other plugins to extend both the content provider model, as well as the presentation (e.g. the structure and the label provider). I also moved the model classes to a new package and exported that package so that extensions can easily extend/customize/add.
3) Help with any other features that people would like to see added.
I added several new features, including the ability to read an edef file from the filesystem (and discover the endpoints defined in the edef). Also added the ability to undiscover/remove Endpoints from the discovered endpoint descriptions. If others want to have other features not yet present, please proceed.
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.
I still intend to do this (this week) for both the import and close/unimport operations.
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].
As I mentioned above, I've done most of this...probably as much as I'll be able to do prior to Mars release. If others want to make other UI generalizations please do so.
6) Help with the releng and IP (add to features, add necessary notices, etc).
Much of this still has to be done. Here's what my plan is: 1) Move everything about this view (all packages/code, views) to the org.eclipse.ecf.remoteservices.ui plugin at the Eclipse Foundation; 2) Do the string externalization at the same time as 1; 3) Since everything will be part of an existing plugin, it will be unnecessary to create new features or add any new notices. I expect to do this next week, after I've finalized the code, given others time to review and/or add other desired features.
Below is a new screenshot
Scott
[1] https://github.com/ECF/OSGIRemoteManagement/tree/master/plugins/org.eclipse.ecf.mgmt.rsa.discovery.ui
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=461000
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=463626
WimCheers,
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
_______________________________________________ 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
