Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

ECF Conference Call 12.10.2008

Attendees

Markus Kuppe, Remy Suen, Scott Lewis, Ted Kubaska, Marcelo Mayworm, Mustafa Isik

Agenda

Resource Synchronization between N Workspaces

There are two similar but different functionalities:

  1. bug 239048 - keep N resources synchronized by distributing changes made to one resource to N-1 other peers
  2. bug 257017 - synchronize a resource with the same resource elsewhere using Compare and Team APIs

Remy has working code written but the bundles' names need to be finalized before they are committed to CVS.

Presence API implementation on top of org.eclipse.ecf.example.collab

Time has shown that people who install the ECF examples and connect around with the ecftcp protocol appears to assume that features implemented over the Datashare APIs (like DocShare) should work for them (see this blog post and this newsgroup post). This is false but is quite misleading as there are often features in the examples plug-in which kind of works but are similar in name to the actual feature that's been pushed down to ECF core. More often than not, the core feature could've been reused by the examples plug-in but it doesn't work because the examples plug-in doesn't offer an implementation of the Presence API. Unfortunately, since a chat window appears, it adds to the false impression that the examples plug-in gives to the user.

[Scott] There are a few things here.

1) The ECF collab examples were originally based upon the shared object API, which predates both the presence API and the datashare API (and, of course, docshare).

2) The datashare API is easily added to the collab example (both for server and clients), by including the code from the org.eclipse.ecf.provider.datashare bundle (which implements datashare via the shared object API]. If this was done, then docshare would work transparently on the ECF collab example (which uses the ecftcp 'generic' protocol).

3) The presence API can/could also be implemented on the example collab, but it would be more difficult, as there is no notion of a login/user-specific roster maintained persistently by the server. There very well could be (as it would be easy to implement such a roster as a shared object, with a primary copy on the server), but to support the presence API fully might be more work than anyone is willing to do.

4) If the the ECF collab example becomes too confusing (i.e. because it has some similar features (e.g. file transfer, text/group messaging), but not others (e.g. roster, support for docshare), then perhaps we should remove/deprecate it...or make the UI more distinct.

[Remy] Since the plug-in is an "example", we should essentially be allowed to add, change, and delete things at will. Requesting comments from Scott as to the implications of such drastic actions.

[Scott] As far as I'm concerned we (the committers) have this capability now...if there are things that can/should be added, changed, or removed to meet expectations (or change expectations) then we can/should do these things.

Release 2.1

Scott has entered IP log hell, and he'll give an update to everyone about what that means for ECF 2.1 release.

ECF Core API Additions and Changes

There are several needed additions and changes to the ECF core API e.g. following bugs:

[256975] - [remoteservices] add RemoteServiceTracker utility class

[250716] - [remotesvcs][api] add asynch method to remote service lookup

[249240] - implement RFC 119

[250717] - [api] add IResourceID

[254872] - Convert org.eclipse.ecf.core.identity.IDCreateException into RuntimeException

[257864] - Turn checked into runtime exceptions

[200800] - org.eclipse.ecf.identity and org.eclipsec.ecf.sharedobject plug-in names differ with project name

[233807] - Move replaceAllIgnoreCase to StringUtils

[257115] - [core] Move ECF core bundles to Foundation 1.1

[256079] - NPE at BaseSharedObject#destroySelfLocal

[252002] - [filetransfer] support NTLMv2 authentication with httpclient provider

[254684] - [core] defer extension registry processing

[239663] - ECF features use two different branding icons

[238021] - Cant login with google apps user acount


and some others (please add to here if you have others)

We need to schedule handling these bugs with full testing *prior* to M6 (end of March), as M6 is the API freeze for the platform, and this applies to the ECF core and filetransfer changes.

Presence Search API

As per [bug 256696] Marcelo is beginning work on a new 'user search' API to enhance the Presence API with the ability to search for/find users.

ECF Book

Scott, Chris, and others are beginning work on an ECF book. The approach will include soliciting work on individual chapters from various ECF committers and contributors. If you are interested to contributing on the book please make this known to Scott Lewis (slewis at eclipsesource.com) or Chris Anisczyzk (zx at eclipsesource.com).

Consistent Support for Future

The following bugs all have to do with adding the use of a future to the discovery API and the remote services API:

[e4 bug 253777] -- support asynchronous programming patterns

[257861 comment 3] -- Split org.eclipse.ecf.discovery.IDiscoveryContainerAdapter into "Locator" and a "Advertiser"

[250716] - [remotesvcs][api] add asynch method to remote service lookup

We need to coordinate work on the use of future/asynchronous programming patterns in discovery, remote services, and platform work.

Back to the top