[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 23:50, Gary C Martin wrote:

> 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.

Replying to myself, always a bad sign ;-)

Use case: "Darn, I missed the weekly project chat meeting, AGAIN...  
Oooh, Bob is still online, let me see if I can download the meeting  
activity entry."

Misc supporting argument: If you default to Journal sharing OFF and  
make it a new separate manual public sharing UI tick box/setting  
(required for privacy), folks will rarely set it, there will be little  
to share from someone else's Journal so you'll rarely bother looking  
for something remotely. Changing the Activity sharing language from  
"Share with: Neighbourhood" to "Share with: Anyone", means both  
synchronous and asynchronous sharing could happen, suddenly allows  
deployments to automatically** cross pollinate content and activities  
as folks move from otherwise isolated network islands.

**by automatically, I mean that the sharer has not needed to be asked  
to provide specific access to some entry, if it already was public,  
then it is shared. Though this does suggest to me that we should  
finally be allowed to "un-publicly share" an entry if desired (a  
manual choice); and perhaps a global manual setting for deployments/ 
users to switch of all Journal sharing.

Regards,
--Gary