[Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting

[Gary C Martin]

On 3 Jul 2009, at 18:29, Eben Eliason wrote:

> On Fri, Jul 3, 2009 at 10:42 AM, Gary C Martin<gary at garycmartin.com>  
> wrote:
>> On 2 Jul 2009, at 14:47, Eben Eliason wrote:
>>>
>>> On Wed, Jul 1, 2009 at 1:42 PM, Aleksey  
>>> Lim<alsroot at member.fsf.org> wrote:
>>>>
>>>> But in that case we should provide possibility to mark objects  
>>>> that can
>>>> be shared(I guess sharing all local objects by default is not a  
>>>> nice
>>>> idea).
>>>
>>> Right. This would be essential. There's definitely some thought that
>>> needs to be done here.
>>>
>>> Scott had an interesting proposal which basically exposed the  
>>> Journal
>>> (or some subset of it) as an RSS feed. This was really neat, because
>>> it meant we could build a UI for someone else's Journal in Sugar,
>>> populating it with that data, but also that these feeds could be
>>> shared globally, for anyone with an RSS reader to benefit from.  
>>> That's
>>> a really powerful approach in my mind, and there is some starter  
>>> code
>>> lying around as a proof of concept already!
>>
>>
>> +1 to rss feed concept, makes life a lot easier in a heterogeneous
>> environment.
>>
>> I'm still catching up on email so apologies if this has been  
>> mentioned
>> already. But the UI for marking of entries as sharable does not  
>> necessarily
>> need to be another Journal user-interface addition** In the simplest
>> approach you could just extend the Activity "Share with: my  
>> Neighbourhood"
>> control to mark a Journal entry as part of the RRS feed. Would need  
>> some
>
> The problem I see with this is that we're talking about two different
> kinds of sharing. Just because I want to make a picture I drew
> available for anyone to look at, or even make a "photocopy" of to
> scribble on, doesn't mean that I want to let them into a shared
> painting session so they can scribble on the original with me.
>
> This is the difference between sharing an activity with someone
> collaboratively, and sending them (a copy of) the resulting object.

Devils advocate here, so just because someone was late to the realtime  
party, they don't get to download an otherwise openly published piece  
of work that could be re-published at any time by any of the  
temporally lucky contributors? Downloading a Journal entry would not  
allow you in anyway to edit the remote users copy, you'd just get a  
snapshot downloaded to your Journal as if they had performed an  
equivalent "Send to" function.

>> thought on wording, do you add more levels of sharing? Or do you just
>> simplify the "Share with:" language language to "Private", "Share  
>> with:
>> Anyone".
>>
>> **though I would like entries to visually show their sharing state,  
>> the
>> buddy column hints at this but should be made explicit
>
> I do actually think that the Journal is the best place to expose this,
> especially since the way we plan to expose the feature in the UI is
> something like "view <my friend>'s Journal." I'm not sure exactly how
> or where that happens. Perhaps if we can abandon the checkbox for the
> multi-selection we can use that space for a public/private toggle of
> some kind.


My main reasons against the check-boxes are that they seem to eat  
quite a chunk of the UI, and make it seem a deal more visually  
complicated. I could imagine changing entry sharing status in the  
Journal details view, but that is out the way and not so scary for  
regular Journal use.

Regarding RSS feeds (which I do otherwise like for heterogeneous  
reasons), the main issue with that solution would be the problems when  
collaborators were using a remote Jabber server. Machines are likely  
behind firewalls et al, and accessing standard RSS feeds off such  
machines would fail in most cases requiring non standard network  
tweaks or alternative protocol support.

Regards,
--Gary