[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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