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