[Sugar-devel] GSoC idea: Chart/graph-making activity

[Walter Bender]

I thought Fred was getting at a much simpler idea. For example,
Measure, when it is collaborating, is sending a simple data stream to
each member of the collaboration. Why couldn't a chart program join in
and instead of rendering the datastream as a waveform, it would render
it as a piechart. Of course, we'd need to consider that the chart
program wouldn't be generating data, but if an activity which wants to
share its data with other activities sticks to a simple streaming
protocol, I don't think it is too difficult.

-walter

On Wed, Mar 25, 2009 at 5:21 PM, Benjamin M. Schwartz
<bmschwar at fas.harvard.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> For the moment, I assume you are speaking of our current network
> collaboration technologies.
>
> Walter Bender wrote:
>> Interesting idea. I don't see why this couldn't work; I am not sure of
>> the security implications, but I don't see why collaboration always
>> has to be between two identical activities.
>
> Collaboration always has to be between two identical activities.  The only
> exception is if the two activities, though not identical, speak a unified,
> coherent network protocol.  In order for this to work, Activities would
> have to specify their network protocol in complete detail, with each
> change in the protocol generating a new version identifier.
>
> It is not enough to specify the generic connection parameters, as done by
> Telepathy; this only gets us far enough to fail.  The protocol in question
> must specify the names, types, and meanings, of all remote procedures that
> can be called from either side.  This is approximately the level of
> specification required in something like an IETF RFC... and it would be
> needed for every activity.  The versions would then need some sort of
> identifier, so that the two participants can, when initializing a
> connection, negotiate a mutually intelligible protocol (if one exists).
>
> Achieving this level of precision specification is difficult even for
> experienced full-time software engineers.  It is often performed by
> specification specialists, who are experts in this field.
>
> Moreover, distinct activities are _different_.  It should be obvious
> enough that no matter how we twist the network protocols, Video Chat and
> Write are never going to collaborate directly with each other.  Their
> internal data structures are grossly incompatible, because their codebases
> are unrelated, because their purposes are entirely distinct.
>
> Now, the above is fairly obvious, so I suspect you are talking about
> something else.  Perhaps you envision some way of taking the functionality
> from one Activity and embedding it in another as a kind of widget, or
> perhaps you're thinking of some other way of smushing activities together
> like objects with well-defined interfaces.  If so, you may like to observe
> the history of the Component Object Model [1], the Cross Platform
> Component Object Model [2], or maybe even the GNU Network Object Model
> Environment [3].
>
> I think such "collaborative widgets" are very powerful; I've even written
> one or two for Groupthink... but now I'm off into speculation, since I
> don't really know what you're thinking about.
>
> - --Ben
>
> [1] http://en.wikipedia.org/wiki/Component_Object_Model
> [2] http://en.wikipedia.org/wiki/Xpcom
> [3] http://en.wikipedia.org/wiki/GNOME#Name
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAknKoGsACgkQUJT6e6HFtqREVQCaA7m8daZOFBh2PB4/pfTRoHeX
> En4AnR6BBOZOCA8SfSu3GbA3TarQAX4a
> =YpnV
> -----END PGP SIGNATURE-----
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org