[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- From: Harshana Eranga Martin <harshana05@xxxxxxxxx>
- Date: Wed, 26 Jan 2011 00:01:51 +0530
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=sONyS2pBj4PHgbIQfHog+H2XMqVWWHPKyIqtkUDE0tthbaPlfjV2P+JrWmf+FCem7C sK/IK1WBj7NNQ3olWKAosBPeTBu1zzCUza5O+p0H/BC9sFzrmON/AAVigalIVBKmqUQO kUZG1xx1qMFl+4jThry+p8nU+lfJQVkAAIYa4=
On 25 January 2011 00:52, Scott Lewis <slewis@xxxxxxxxxxxxx>
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 . Â 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.
I was involved in some work related to ECF SIP provider implementation. Mainly some refactoring work. My initial plan was to complete it for 3.4 but could not do it. But I'm determined to complete it for 3.5. Currently most of the architectural level changes are done. But still there are lot of code segments need to be refactored to reach the quality of the code normally expected in a release. Therefore I'm continuing this work in my spare time, mainly week ends. I will keep this list updated about this work.Â
Since we need to complete the release engineering stuff to be completed for the release, I will undertake the documentation related aspects of it including presentation preparation, etc. Please let me know when we need to Âcomplete those tasks for the release, so that I can complete and commit them to the docs.
Thanks and Regards,
Note that the contribution does *not* have to be a code contribution, as contributions to the ECF documentation project  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,
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 ), 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 , and/or via this mailing list.
ecf-dev mailing list
Thanks and Regards,
Harshana Eranga Martin