Re: [ecf-dev] shared editing design thought

["Remy Chi Jian Suen" <remy.suen@xxxxxxxxx>]

Is this plugin.xml change related to this code?
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/plugins/org.eclipse.ecf.presence.ui/plugin.xml?root=Technology_Project&r1=1.22&r2=1.23

Looks like a mis-commit.

On 10/30/07, Mustafa K. Isik <isik@xxxxxxxxxx> wrote:
> Good Stuff.
>
> I'll try it out once I am home ...
>
> On Oct 30, 2007 6:08 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
> >
> >  Hi Folks,
> >
> >  I've added some classes to create 'Roster Menus' as per the original
> > posting on this thread.  I put up a new wiki page describing this and
> > showing a quick test/demo here:
> >
> >  http://wiki.eclipse.org/Roster_Menus
> >
> >  It's pretty cool, I think, as it would allow easy addition of arbitrary
> > communications to existing editors, views, etc.
> >
> >  Any thoughts/comments, etc are appreciated.
> >
> >  Scott
> >
> >  Scott Lewis wrote:
> >
> >  Hi Chris,
> >
> >  Chris Aniszczyk wrote:
> >
> >
> > +1
> >
> >  This work will probably encompass taking some of the roster information
> > offline which is a good thing.
> >  I don't really expect so at this point...as even if the roster information
> > is available persistently offline, it doesn't make much sense to expose
> > actions/commandhandlers (like share current editor with soandso, etc)
> > because the actions are generally worthless when offline (e.g. you can't
> > start a shared editing session with a user that is offline).
> >
> >
> >
> >
> > If I have some spare cycles I would love to help.
> >
> >  That would be great.  I think the trickiest bits will have to do with
> > setting/resetting the command handlers dynamically (with the IServiceLocator
> > I guess).  I expect you, Remy, and Boris have more knowledge of this than I
> > do so anything that shows doing this sort of thing (creating menus
> > dynamically, and assigning actions to dynamically constructed items) would
> > be helpful.
> >
> >
> >
> >
> >
> >  I also noticed that ECF hasn't submitted anything to EclipseCon yet :)
> >  https://eclipsecon.greenmeetingsystems.com/submissions
> >
> >  I noticed that too.  I will be submitting something...probably around
> > remote OSGi services and/or ECF overview, but I haven't decided what.
> >
> >  I hope that we can get other submissions from committers...i.e. around
> > topics such as
> >
> >  RT Shared Editing
> >  Presence and IM APIs
> >  Bots
> >  Committer Community, IRC, XMPP, and Communication
> >  Discovery
> >  VOIP
> >  Others of interest...
> >
> >  These are just some ideas.  I imagine others have other ideas as well.
> >
> >  Scott
> >
> >
> >
> >
> >
> >
> >  Cheers,
> >
> >  ---
> >  Chris Aniszczyk | IBM Lotus | Eclipse Committer |
> > http://mea-bloga.blogspot.com | +1.860.839.2465
> >
> >  Scott Lewis ---10/27/2007 06:07:45 PM---Hi Folks, We at BEA have/will/are
> > doing some work with using ECF to add real-time
> >
> >
> >
> >  From:
> >  Scott Lewis <slewis@xxxxxxxxxxxxx>
> >
> >  To:
> >  "Eclipse Communication Framework (ECF) developer mailing list."
> > <ecf-dev@xxxxxxxxxxx>
> >
> >  Date:
> >  10/27/2007 06:07 PM
> >
> >  Subject:
> >  [ecf-dev] shared editing design thought ________________________________
> >
> >
> >
> >  Hi Folks,
> >
> >  We at BEA have/will/are doing some work with using ECF to add real-time
> >  shared editing to commercial and OS editors...i.e. text editors,
> >  structured editors (e.g. java, other langs, xml, etc), graphical
> >  editors, and the like.
> >
> >  I was thinking yesterday was that it is typically unnecessarily
> >  difficult to setup a sharing/editing session.  It usually has to be
> >  explicitly done by one or both participants prior to the actual shared
> >  editing...and it's often error prone.
> >
> >  This is true also of the existing cola shared editor...the setup of the
> >  shared editing session is kind of cumbersome.
> >
> >  I had one thought about how this could be easier...and I thought I would
> >  throw it out to the mailing list:
> >
> >  Let's assume that user 'slewis' has a (e.g.) text editor open.  At a
> >  certain point, they decide that they would like to initiate a shared
> >  editing session with another party (e.g. 'codesurgeon').  At that point,
> >  'slewis' has to initiate a shared editing session.
> >
> >  What if they simply opened the editor's context menu, and chose
> >  'Share'->codesurgeon...and this initiated a shared editing session with
> >  codesurgeon.  This begs the question, though...where does the
> >  'Share'->codesurgeon menu come from?  My answer:  Using Eclipse's new
> >  dynamic menu contribution mechanisms, it could be dynamically created
> >  from the ECF Contacts/buddy list.  That is, when the user chose 'Share'
> >  it could produce a menu hierarchy that corresponded to the entries in
> >  the contacts list (whatever the active ones happened to be at that
> >  moment)...allowing the initiator to choose the target user for the
> >  shared editing session.  The Eclipse menu contribution mechanisms should
> >  allow this (i.e. dynamic creation of hierarchical menus...plus the
> >  ability to retarget actions), and ECF allows programmatic access to the
> >  buddy list via IPresenceContainerAdapter.getRosterManager().   Further,
> >  it would be possible to add such a thing in a new plugin (rather than
> >  modifying the existing editor's code) to increase separation of concerns.
> >
> >  Any thoughts/comments about this approach?
> >
> >  Scott
> >
> >
> >
> >
> >
> >
> >
> >  Let's also
> >
> >
> >
> >
> >  That is,  between...perhaps one way on how to setup a 'session for
> >  shared editing' (between 2 participants is initial focus...2+ will
> >  probably be for later).
> >
> >
> >  _______________________________________________
> >  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
>