Just thinking at the conceptual level. How about filtering irrelevant method calls and signals? How about a RESTful interface (<a href="http://en.wikipedia.org/wiki/Representational_State_Transfer">http://en.wikipedia.org/wiki/Representational_State_Transfer</a>)? I don't know. Just thinking... Thanks for contributing! --Fred <div class="gmail_quote">On Wed, Mar 25, 2009 at 5:21 PM, Benjamin M. Schwartz <<a href="mailto:bmschwar@fas.harvard.edu">bmschwar@fas.harvard.edu</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For the moment, I assume you are speaking of our current network collaboration technologies. <div class="im"> 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. </div>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] <a href="http://en.wikipedia.org/wiki/Component_Object_Model" target="_blank">http://en.wikipedia.org/wiki/Component_Object_Model</a> [2] <a href="http://en.wikipedia.org/wiki/Xpcom" target="_blank">http://en.wikipedia.org/wiki/Xpcom</a> [3] <a href="http://en.wikipedia.org/wiki/GNOME#Name" target="_blank">http://en.wikipedia.org/wiki/GNOME#Name</a> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknKoGsACgkQUJT6e6HFtqREVQCaA7m8daZOFBh2PB4/pfTRoHeX En4AnR6BBOZOCA8SfSu3GbA3TarQAX4a =YpnV -----END PGP SIGNATURE----- </blockquote></div>