[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] org.eclipse.ecf.presence.IFQID
|
Sure, just send me a short mail which date and time. This resource
stuff was really more complicated than I expected too, but the people
which needed this capability will be really happy to see this working!
Am 27.11.2008 um 20:30 schrieb Scott Lewis:
Hi Eugen,
Thanks for the nice words. I'm very glad to get everything
going...xmpp's handling of resources (and therefore XMPP ids) is
more complicated than I expected.
I would like to arrange to speak with you after the holiday weekend
(i.e. next week) to discuss some things with you...including the
ideas below and remote mgmt/your rcp work.
Thanks,
Scott
Eugen Reiswich wrote:
Hi Scott,
I've checked your bug fixes for the IFQID today and it works
perfect! You've done a great job on this, thanks a lot, I really
appreciate it!!!
Cheers,
Eugen
Am 25.11.2008 um 23:03 schrieb Eugen Reiswich:
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).
I rather meant the resources we've added to the XMPP-IDs. By now
all users are displayed at the same level in a group (within the
roster tree in a GUI). But if a user logs in several times it
might be useful to group this user/resource pairs in a new node.
This could be done by using something like an IResourceGroup.
I've also received the updates regarding "multiple users after
log in and log out". I will test these changes by the end of the
week and give you some feedback. Thanks for this update and your
work!
Cheers,
Eugen
Am 24.11.2008 um 21:46 schrieb Scott Lewis:
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
_______________________________________________
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
_______________________________________________
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
