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

[Eben Eliason]

SJ, I think that the "Meshboard" of which you speak embodies most of
our goals for bulletin boards as designed early on.  We may need to
think through some more details, but this is certainly the goal if we
can manage it.  Things would probably time out, and they might time
out based on popularity and other factors, too.  They would travel
"over the mesh" assuming anyone currently on the mesh had picked up
the object (eg. it would still be distributed).

I think a distributed persistent bulletin board is where we're
heading, but I think that the one-to-many approach of serving it up
only from my own machine will get us a lot in the near term.  As a
side note, we may also want to think about the "send to" action and
how we might allow direct transfer of things from XO to XO.

Also, I like your previous comment about the method of "grabbing" one
of these shared objects.  I think that this greatly simplifies the
interaction, which is especially good for now.  At its core, this
action is a download, which the Journal now neatly handles, and it can
handle opening it with any suitable activity as you mention.

- Eben


On 9/14/07, Samuel Klein <meta.sj at gmail.com> wrote:
> 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
> >
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>