#3431 HIGH Trial-3: Need to be able to share objects in the mesh, not just activities

[Samuel Klein]

I see this as a spectrum between sharing things almost-synchronously
(nothing is 100% synchronous) and sharing them highly asynchronously
(posting things you expect others halfway around the world to get in a
few weeks).  Another point on the spectrum is an Activity such as
Meshboard, which centers around asynchronous collaboration and the
persistance of a specialized 'bulletin board' view of postings that
anyone has made that have not yet expired.

Right now the mesh view supports pretty synchronous activities -
either you are actively doing something with someone, or you very
recently were.  Eben discusses sharing objects as "a snapshot, and not
in any way permanently linking/publishing the file (It should be a
momentary button)"...  Also worth considering are meshboard sharing of
objects with expiration date and more permanent sharing of objects.

SJ

On 9/14/07, Walter Bender <walter.bender at gmail.com> wrote:
> Just to reiterate from Kim's original posting:
>
> We are not proposing this as a new feature for Trial-3, just " some
> analysis of what is needed."
>
> I am not married to the exact details* of the scenerio as described;
> simply I want to suggest that to have mechanisms for sharing
> activities and "objects" is the goal. From the user perspective, it is
> a clear, simple, and powerful concept. How it gets implemented under
> the hood and how it gets exposed in the UI is of course something that
> needs careful thought.
>
> -walter
>
> * for one, it isn't clear that in "object" sharing, the same activity
> that created an object need be the one that is used to open it when it
> is shared. It might be sufficient to place the object in the journal
> as the default action (or as a hover option) and use the Journal's
> existing resume mechanism as the arbitor.
>
> On 9/13/07, Zarro Boogs per Child <bugtracker at laptop.org> wrote:
> > #3431: Need to be able to share objects in the mesh, not just activities
> > -----------------------+----------------------------------------------------
> >  Reporter:  kimquirk  |       Owner:  marco
> >      Type:  defect    |      Status:  new
> >  Priority:  high      |   Milestone:  Trial-3
> >  Component:  sugar     |     Version:
> > Resolution:            |    Keywords:
> >  Verified:  0         |
> > -----------------------+----------------------------------------------------
> >
> > Comment(by Eben):
> >
> >  Replying to [comment:2 kimquirk]:
> >  >  * Design team. I talked with Eben and I think we need a way to
> >  > differentiate activities and objects. Either using visual styling inside
> >  > the mesh view or doing some sort of overlay (which I think would be
> >  > cleaner but we would have to evaluate implementation if we go that way).
> >
> >  Whatever method we choose, I think we need to indicate the distinction
> >  between collaborations (activities) and objects (their result).  I'm not
> >  confident that anything we do in the current mesh view will be distinct
> >  enough, since the implication for objects in that view is that XOs can
> >  cluster around them eg. they are activities.  Still, in order to get a
> >  rough implementation of this working sooner than later, I would be content
> >  to skip the overlay if we can come up with another way of making the
> >  distinction.
> >
> >  > Also Eben was thinking to a slightly different way to trigger share from
> >  > the journal. Anyway we need a solid/agreed design before starting with
> >  > the implementation.
> >
> >  I think that we need to make this an action upon the object, rather than a
> >  change to its state.  To clarify, I mean that we shouldn't be "setting a
> >  sharing scope" for the Journal entry, since that implies a more persistent
> >  change.  Instead, what we're really doing is posting a copy of the current
> >  state of the object itself, much like tacking it to a bboard.  However we
> >  reveal this in the Journal, we should make it clear that it is tacking up
> >  a snapshot, and not in any way permanently linking/publishing the file (It
> >  should be a momentary button).
> >
> > --
> > Ticket URL: <https://dev.laptop.org/ticket/3431#comment:3>
> > One Laptop Per Child <https://dev.laptop.org>
> > OLPC bug tracking system
> >
>
>
> --
> Walter Bender
> One Laptop per Child
> http://laptop.org
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>