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 <fgr...@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 > <bmsch...@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@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel