[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] Questions from conf call
- From: Scott Lewis <slewis@xxxxxxxxxxxxx>
- Date: Tue, 13 Jun 2006 10:25:33 -0700
- Delivered-to: firstname.lastname@example.org
- User-agent: Thunderbird 18.104.22.168 (Windows/20060516)
Boris Bokowski wrote:
1. Are the differences between Datashare and Datashare2 documented?
Is Datashare2 ready for client consumption?
No, Datashare2 is not ready for consumption, and its differences to
Datashare are not documented. As far as I know, it is not part of the
ECF builds, I created it a while ago to capture what I think a
general-purpose model sharing API should look like, but since then did
not have the time to get it into a state that could be consumed by
2. Is it expected than core model synchronization logic developed in
Summer of Code projects will make it into core ECF code if appropriate?
I think this would be great. I will talk to Mustafa on Thursday, and I
will explain the ideas behind datashare2 to him. Maybe you would like
to join the call? I think it is at 2pm eastern.
It's been my intention that we would extend/enhance the datashare API
over time...with additions of things like a completed 'datashare2',
support for other types of IChannels, as well as work from Mustafa's or
other's projects. That is, datashare currently is just a starter API
and there are many opportunities to enhance it/extend it in useful
So, I guess you could say I'm more than all in favor RE: including API
designs from datashare2, Mustafa's work, other work, etc. directly in
3. Has anyone considered exposing ECF datashare servers and channels
as OSGi services for consumption by other bundles? (For example, I
have a bundle that wants to replicate a model. Rather that create ECF
in my bundle, I install an ECF bundle that provides a channel
service. I create a channel by accessing it from the ECF channel
service using standard OSGi service access semantics.)
Yes, I've been thinking this would be a very good thing to do...but I've
not gone through the programming exercise to do it.
I am actively pursuing a varient of item 3) with the ECF Generic
Server. It is an "ECFBridge bundle" , with the goal of making it
protocol agostic as possible and reducing much client coding to OSGi
service calls. I plan to present a simple implementation example at
I would be glad to share the current bridge design with you, discuss
any changes to the talk you might think appropriate, or collaborate in
Bob would there be any chance that some of this work could be considered
for a contribution? (to foundation under EPL)? Perhaps we could take
parts of this (the OSGI service parts in particular) and include them
directly in ECF? (in one of the core plugins...I'm not immediately sure
which ones would make sense right now). Would there be any opportunity
for any of us to use/try/examine source for this ecfbridge bundle?
Thanks...sounds exciting. This would be some real 'meat' for the ECF
"Server" subproject in particular.