[Sugar-devel] GSoC idea: Chart/graph-making activity
wadetb at gmail.com
Wed Mar 25 18:33:19 EDT 2009
To simplify, I think MIME types are the best way to communicate
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
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
> 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 , the Cross Platform
>> Component Object Model , or maybe even the GNU Network Object Model
>> Environment .
>> 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
>>  http://en.wikipedia.org/wiki/Component_Object_Model
>>  http://en.wikipedia.org/wiki/Xpcom
>>  http://en.wikipedia.org/wiki/GNOME#Name
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.9 (GNU/Linux)
>> -----END PGP SIGNATURE-----
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
More information about the Sugar-devel