| Re: [ecf-dev] ECF 3.5 |
Hi Scott, I was created an ECF XML-RPC provider implementation [0]. This is a simple provider, but it allows ECF users to make connections for XML-RPC based web services (i.e. Jira or Bugzilla XML-RPC APIs). The implementation based on the Apache XML-RPC library [1] from Eclipse Orbit [2]. Currently the provider supports followed things: - RemoteServicesClient API (Sync and Async invokes via Callable/Call); - Remote Service invokation via Proxy [3] (if a server is based on the Apache XML-RPC library); - Custom input parameters serializers (i.e. java objects into RPC-friendly types serializers). Currently the provider does not support: - HTTP headers relation authentification (see [4]); - custom datatypes (see [3]), but I'm planning to finish this work on early Feb 2011. Also I want to add some examples, i.e. a subset of Jira XML-RPC API (Jira does not need a Http-Authentification). Links: [0] https://bugs.eclipse.org/bugs/show_bug.cgi?id=325813 [1] http://ws.apache.org/xmlrpc/ [2] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=4549 [3] http://ws.apache.org/xmlrpc/advanced.html [4] http://ws.apache.org/xmlrpc/server.html 24.01.2011 22:22, Scott Lewis пишет: > Hi Folks, > > It's time to do some community planning for ECF 3.5 and beyond. In > this email, I'm going to focus on ECF 3.5 specifically...and in a > second planning email I will discuss what we're going to do for the > Indigo simultaneous release. > > When: ECF 3.5 has been previously planned for 'late Feb 2011'. The > desire here is to have the ECF 3.5 release prior to EclipseCon 2011 > (in early March). > > What: This is the main question for this email. We have to (soon) > decide what will go into ECF 3.5. > > Other than bug fixes (of which there have been a good amount since > 3.4), the only thing that I know for sure that is going into ECF 3.5 > is the OSGi 4.2 Remote Service Admin spec implementation that I've > been doing since ECF 3.4. This implementation is now very close to > complete, and you can get technical details and/or participate in the > remaining finishing/testing work via this enhancement [1]. See below > for some initial words describing the RSA implementation. > > I'm sure there are other ECF committers and/or contributors that have > work that they've been doing that could potentially be in ECF 3.5 as > well. So I make the following request of *all ECF committers, > contributors, and community members*: > > Action request: If you have something that you have been working on, > that can/could be in ECF 3.5, please take a few moments to create a > posting to this mailing list (in response to this email) describing > that work, and detailing what/where it is in development and what (to > your own understanding) needs to take place in order for it to be > included in/added to ECF 3.5. > > Note that the contribution does *not* have to be a code contribution, > as contributions to the ECF documentation project [3] can/would also > be great and very welcome additions/contributions to ECF. Such > contributions are *very important*. So if you have/could make a > documentation, and/or examples contribution (whether you are a > committer or not), please respond to this email with that information, > so that I and the rest of the community can plan for that. > > Thanksinadvance for your usage, participation, and continued support > of ECF, > > Scott > > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=324215 > [2] http://wiki.eclipse.org/ECF/Asynchronous_Remote_Services > [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=329124 > > > Short description of ECF's OSGi 4.2 RSA Standard Implementation > > I think RSA will be a very nice addition for ECF consumers...not only > because it's been explicitly requested by some in the community, but > also because ECF's modularity (i.e. separation of discovery and remote > service APIs...allowing multiple, transport specific providers to be > mixed and matched for remote service discovery (e.g. zookeeper, > zeroconf, slp, xml-file-based, custom), and the distribution (rosgi, > ecf generic, jms, xmpp, javagroups, as well as our support of > asynchronous/non-blocking messaging for remote procedure call (see > [2]), makes ECF's implementation of this OSGi standard the most open. > extensible and interoperable implementation available...bug also makes > it the most functional that I know of for creating scalable enterprise > remote services using industry standards. > > I'll be making a number of postings over the coming months clarifying > what RSA is, and how ECF's implementation provides added value above > and beyond existing commercial and/or other implementations. > > If people have questions about the RSA spec, and/or ECF's > implementation, please ask them on either the rsa enhancement request > [1], and/or via this mailing list. > > > _______________________________________________ > ecf-dev mailing list > ecf-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/ecf-dev -- Pavel Samolisov, Eclipse Communication Framework committer, Senior Software Developer, http://psamolisov.blogspot.com
Attachment:
signature.asc
Description: OpenPGP digital signature