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

[Wade Brainerd]

To simplify, I think MIME types are the best way to communicate
between activities.

Spreadsheet data can be text/csv, image data can be image/png, plain
text can be text/plain etc.

That's currently what's supported by the clipboard anyway.  All
activities have to do is implement a little more advanced version of
Copy & Paste, and the clipboard needs to support everything correctly
too.

-Wade


2009/3/25 Frederick Grose <fgrose at gmail.com>:
> Just thinking at the conceptual level.  How about filtering irrelevant
> method calls and signals? How about a RESTful interface
> (http://en.wikipedia.org/wiki/Representational_State_Transfer)?
>
> I don't know. Just thinking...
>
> Thanks for contributing!   --Fred
>
> 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-----
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>