Re: [ecf-dev] org.eclipse.ecf.presence.IFQID

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Eugen,

Sorry about the delayed response.  I was at ESE and I sort of lost track 
of this posting.  My apologies.

Eugen Reiswich wrote:
> Hi Scott,
>
> I'm thinking of a new use case where all user resources are grouped to 
> an e.g. 'IResourceGroup' object rather than displaying all 
> user/resource-objects at the same level. To be more precise if a user 
> connects to a server several times (with different resources) this 
> user or the resource could be assigned to an IResourceGroup which will 
> be used in a tree as a node (similar to the use case where users are 
> assigned to groups).

Could this potentially use the platform resource API?  i.e. The resource 
API has IFolder and IProject (with super interface IContainer...not the 
ECF IContainer but the org.eclipse.core.resources.IContainer).

> Do you think this is important enough to become part of ECF or should 
> I handle this just within my project?

The whole interaction between ECF/distribution and the Eclipse local 
resources system (and EFS) is extremely important for ECF as a whole.  
There are several enhancement requests that are related to this 
issue...e.g.:  https://bugs.eclipse.org/bugs/show_bug.cgi?id=239048.  
Note that using ECF would allow several/many existing UIs to work 
unmodified...e.g. navigator, wtp project browser, etc.

In short, we need to figure out how to replicate multiple resources into 
the workspace...for shared editing, but also for lots of other things 
(e.g. folders and recursive contents, projects, whole workspaces 
potentially).   There are some very tricky questions, IMHO:

1) Should we try to use EFS to provide transparent access to replicated 
workspace contents?
2) When should we do the replication? 
3) How should we decide how much to replicate...or leave to user (e.g. 
projects, folders, individual resources, what's is shared via repository).
4) How/what should we do WRT source code repositories? (e.g. SVN, CVS, 
others).  That is, how should we deal with cases like:  repo has one 
content, shared editing initiator has some other version, and the 
receiver(s) have yet a third version/or nth version?
5) How to keep local caches of resources consistent enough for use cases?

I'm quite sure there are very good answers to all these questions, given 
some use cases, and I do think that now ECF has the tools (e.g. with 
remote services, datashare, etc) to address these issues.  But I wanted 
to get them out there for everyone to consider.

So to summarize, I do think that your area of work here (i.e. 
relationship to local and distributed resources) is important enough to 
be directly related to ECF...and it would be great if we could have ECF 
community benefit from such work.

Thanks,

Scott

> Cheers,
> Eugen
>
>
>
> Am 02.11.2008 um 21:29 schrieb Scott Lewis:
>
> > Hi Eugen,
> >
> > Eugen Reiswich wrote:
> > > Hi Scott,
> > >
> > > obviously I'm not the only one who's working on sunday :) I've tried 
> > > your new solution with the IFQID and it looks great!!! I will have a 
> > > deep look at it during the week and check out whether the remote 
> > > services are working properly with user/resource pairs, but my first 
> > > impression is that it works pretty good. Thanks Scott!
> >
> > No problem.  Just keep those use cases coming.  Also Eugen...I need 
> > to hook up with you directly about work I've been doing on remote 
> > mgmt...using p2 and ECF remote services.  If you are available please 
> > let me know directly when we could chat via Skype, etc.
> >
> >
> > > > > You should not have to specify this property any longer:
> > > > >
> > > > > props.put(Constants.SERVICE_REGISTRATION_TARGETS, targetIDs);
> > >
> > > What is the right way to register remote services, just provide 
> > > empty Dictionary<?> parameters?
> >
> > Yes.  Now that the 'on-demand' access to IRemoteServices is available 
> > (via getRemoteServiceReferences), it should be unnecessary to 
> > actually specify service registration targets on the service host as 
> > per above.
> >
> > Thanks,
> >
> > Scott
> >
> > _______________________________________________
> > ecf-dev mailing list
> > ecf-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/ecf-dev
>
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev