[news.eclipse.technology.ecomm] Re: have a look at existing code base?!

[Eike Stepper <stepper@xxxxxxxxxxxx>]

On Tue, 16 Nov 2004 00:37:38 -0800, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:

>Hi Eike,
>
>It certainly seems as if we should solicit from you a 'provider' 
>implementation of the ECF api.  We're defining the API such that other 
>plugins can register themselves to provide certain 'types' of 
>communications.  Clearly we would like to have as many providers to 
>deliver their specific protocols to other plugins.
>
>Given an abstract API spec, would you be able to provide your net4j work 
>as such a provider?

hmm, seems that i should have a look at your APIs first ;-)

Net4j is well-designed but its protocol paradigm is not based on 
formal message structures! on the other hand the proper separation of 
transport and protocol layer would possibly enable at least the
integration of the transport layer as an ECF provider. let's see...

>Thanks...and let's keep connected as the project gets fully up and 
>running over the next week.  It will be known as ECF (Eclipse 
>Communications Framework) rather than ecomm.
>
>Thanks Eike,
>
>Scott
>
>
>Eike Stepper wrote:
>> hi,
>> 
>> i'm very excited about the establishment of this project!
>> my company is currently working on a sophisticated 
>> solution to the workflow challenge on an eclipse basis.
>> 
>> for that reason we already have developed an
>> extensible communications plattform. the Net4j project
>> is published as open source at http://www.sympedia.org/net4j.
>> 
>> unfortunately the documentation is not up to date,
>> the system has been reimplemented for the use of the 
>> Spring framework (instead of merlin, as the docs say).
>> 
>> Net4j is a server-based system with pluggable protocols,
>> built-in support for embedded and NIO socket transport.
>> 
>> design is optimized for performance and extensibility.
>> it uses an advanced form of protocol multiplexing to
>> enable multiple protocols to use a single transport connection.
>> 
>> i'd really appreciate if you'd dare to have a look at it ;-)
>> maybe you like some of the ideas behind it.
>> 
>> of course i'd also be willing to migrate my protocols
>> (mainly an O/R mapping protocol for EMF and some
>> for collaboration) to ECOMM, provided it will be able
>> to fulfil their special requirements.
>> 
>> cheers
>> /eike
>> 
>>