Re: On Cerebro, Telepathy, yokes and whites (was Re: cerebro in sugar)
On Tue, Jun 10, 2008 at 19:05, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: Like Michael pointed out, there are few people at OLPC who understand and enjoy telepathy. I think this is an understatement. Personally, I think that Collabora was very pressed to get something working on the laptop and the resulting presence stack looks like one hack on top of another. For example, there are tons of abstraction layers, yet activities have visibility (while they shouldn't) on how telepathy works (since telepathy is only a dependency to sugar, this should not be the case). Also, the presence service needs to understand if it should switch from salut to gabble, but the broadcast storm caused by salut won't let XO get an IP address through DHCP, which would mean that there's a school server around and. you get the picture! The current plan to attack scalability problems is implementing gadget from scratch which, if I understand correctly, is a plug-in to jabber which already has many problems of its own. Are we sure we're investing our limited time in the right direction? I started working for Collabora on the presence stack just over a year ago. I'll try to give some context to the presence stack architecture based on my experience since then. Presence Service (PS) predates the use of Telepathy. When I started on this, PS was maintained by Dan Williams (Redhat). It was then maintained by Simon McVittie (Collabora) and then myself when Simon switched projects. When I left Collabora, Guillaume Desmottes (Collabora) took over as primary maintainer, although I continue to contribute. PS has a certain amount of cruft in the codebase from before Telepathy was integrated. There are some design aspects that would be politely considered interesting, such as the fact that there are two entirely different mechanisms for tracking who is in an activity (so we can show the buddies clustered around the activity icon in Neighborhood view) - before we join a shared activity we need to track who's in it by their announcements of their activities, but when we are in a shared activity, we can see the other participants directly. When joining an activity, we switch from the one mechanism to the other. For your interest, outside of Sugarland, the component in the Telepathy architecture which is most directly equivalent to PS is called Mission Control (see the diagram on http://mission-control.sourceforge.net/). When I started with Collabora, activities contained a lot of Telepathy code. In fact, Connect was the only collaborative activity, and it was our test case for the implementation. A fair amount of my efforts with respect to the presence stack have been to simplify the API or collaboration mechanisms available to activity authors. This has been done by pushing the Telepathy functionality into PS where possible, or sugar.presence which is the client to the PS D-Bus API for python activities. At this point, there remains code in activities to deal with the setup of Tubes. In a further development cycle, after 8.2 / Sugar 0.82, I plan to simplify that further so that all collaborative python activities get a D-Tube set up automatically, and don't need any boilerplate for that at all. I hope this gives some explanation of why there is Telepathy code in activities. Even with all the current boilerplate removed, it should still be possible for activities to interact directly with Telepathy should the activity author want to do something not provided by the framework. Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
On Cerebro, Telepathy, yokes and whites (was Re: cerebro in sugar)
Tomeu and Marco, For the history, both me and another student from MIT tried to implement a connection manager back in January but gave up after a couple of weeks, even with significant help from Daf. We don't claim to be expert python programmers, but spending two weeks on something and still not even having understood what needs to be implemented (let alone implementing it) to get a connection manager going, or exactly how telepathy works was quite frustrating. What is more frustrating is that the telepathy API is no secret, but it seems that there is some distance between the API and how the presence service and telepathy really work on the laptop. Like Michael pointed out, there are few people at OLPC who understand and enjoy telepathy. I think this is an understatement. Personally, I think that Collabora was very pressed to get something working on the laptop and the resulting presence stack looks like one hack on top of another. For example, there are tons of abstraction layers, yet activities have visibility (while they shouldn't) on how telepathy works (since telepathy is only a dependency to sugar, this should not be the case). Also, the presence service needs to understand if it should switch from salut to gabble, but the broadcast storm caused by salut won't let XO get an IP address through DHCP, which would mean that there's a school server around and. you get the picture! The current plan to attack scalability problems is implementing gadget from scratch which, if I understand correctly, is a plug-in to jabber which already has many problems of its own. Are we sure we're investing our limited time in the right direction? Personally, I don't think this is entirely Collabora's fault. I also think that if you want to have distinct yoke and white, this is where you should start: Make telepathy dead-simple to understand by reading the code, not the API. I did a funny activity showing XOs and their relative distance (http://www.olpcnews.com/hardware/wireless/xo_space_where_you_are.html) almost a year ago in a couple of afternoons, when there was no hint of Sugar APIs (not even hippocanvas!) because it was dead-simple to inspect other activities' code and how sugar works. Which brings us to cerebro. Since I got stuck with telepathy, I decided to circumvent telepathy altogether, at the very least as a proof of concept for cerebro's functionality. The result is an API (http://wiki.laptop.org/go/Cerebro#Programming_API ) that offers not only presence and data sharing between activities, but is also a /complete collaboration framework/: you can share/join activities, get a list of all currently shared activities and users participating in them, invitations, out-of-band chat, interoperability with Windows, embedded Linux and OpenMoko (collaboration tested on all these platforms) and most importantly, scalability. Now, the nightmare strikes back: I have to go back to implementing a connection manager. Tomeu has a point: How many people you know that understands and enjoys any of mozilla, gtk, pygtk, abiword, X, cairo, etc?. But when did OLPC start doing compromises? And if you have to do a compromise, it's better not to do it at such a critical point like the collaboration in sugar. Here's what I propose: 1) Someone should take the lead at implementing a connection manager and I will actively participate, not just by adapting cerebro's API if necessary, but also with implementing the necessary stubs for the connection manager. But the skeleton must be well understood by the person implementing it! 2) Make provision in both sugar and activities so that there is a clear abstraction from telepathy so that _if_ a better collaboration stack comes along, telepathy won't be hardcoded in sugar. This mainly involves documenting the existing calls from sugar/activities to telepathy (and objects returned thereof) and signals provided by telepathy. 3) Get cerebro into joyride which will help a lot with the upcoming multi-hop tests: humans will be operating and updating their XO that participates in the mesh in MIT campus, so I think it is critical to have cerebro in joyride. Am I wrong? Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: On Cerebro, Telepathy, yokes and whites (was Re: cerebro in sugar)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Polychronis Ypodimatopoulos wrote: | 2) Make provision in both sugar and activities so that there is a clear | abstraction from telepathy so that _if_ a better collaboration stack | comes along, telepathy won't be hardcoded in sugar. This mainly | involves documenting the existing calls from sugar/activities to | telepathy (and objects returned thereof) and signals provided by telepathy. Telepathy _is_ that abstraction. It exists specifically so that different underlying collaboration mechanisms can be used interchangeably. For example, Telepathy can run over not only Jabber but also IRC, MSN, AIM, and other protocols. It seems perfectly reasonable to add Cerebro to this list. If you think Telepathy's API should be changed in some way, then that is perfectly reasonable. Telepathy's API can be changed in response to user requirements. Please make those suggestions public. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhOtsIACgkQUJT6e6HFtqT7OgCfXtr0fB5XwxV3KMzqKr92MNY/ sSkAmgMvy3er/0R8B10eMUw0ouZZaZUu =NfB3 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: On Cerebro, Telepathy, yokes and whites (was Re: cerebro in sugar)
Benjamin M. Schwartz wrote: Polychronis Ypodimatopoulos wrote: | 2) Make provision in both sugar and activities so that there is a clear | abstraction from telepathy so that _if_ a better collaboration stack | comes along, telepathy won't be hardcoded in sugar. This mainly | involves documenting the existing calls from sugar/activities to | telepathy (and objects returned thereof) and signals provided by telepathy. Telepathy _is_ that abstraction. It exists specifically so that different underlying collaboration mechanisms can be used interchangeably. For example, Telepathy can run over not only Jabber but also IRC, MSN, AIM, and other protocols. It seems perfectly reasonable to add Cerebro to this list. I thought we were talking about collaboration. MSN, IRC etc are basically chat protocols. Cerebro has little to do with such protocols; its goal is to provide efficient and scalable presence and data sharing in an ad-hoc, mobile environment where even IP addresses are a burden to maintain. I believe such functionality to be central to OLPC and should not be used interchangeably with anything else as long as you have and msh0 interface ;-) p. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: On Cerebro, Telepathy, yokes and whites (was Re: cerebro in sugar)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Polychronis Ypodimatopoulos wrote: | Benjamin M. Schwartz wrote: | Polychronis Ypodimatopoulos wrote: | | 2) Make provision in both sugar and activities so that there is a clear | | abstraction from telepathy so that _if_ a better collaboration stack | | comes along, telepathy won't be hardcoded in sugar. This mainly | | involves documenting the existing calls from sugar/activities to | | telepathy (and objects returned thereof) and signals provided by | telepathy. | | Telepathy _is_ that abstraction. It exists specifically so that | different | underlying collaboration mechanisms can be used interchangeably. For | example, Telepathy can run over not only Jabber but also IRC, MSN, AIM, | and other protocols. It seems perfectly reasonable to add Cerebro to | this | list. | | I thought we were talking about collaboration. MSN, IRC etc are | basically chat protocols. Cerebro has little to do with such protocols; | its goal is to provide efficient and scalable presence and data sharing | in an ad-hoc, mobile environment where even IP addresses are a burden to | maintain. AIM, MSN, IRC, and Cerebro are all protocols that provide message channels, file transfer, and presence info. Cerebro is different in that it is designed to run on networks that do not have strong routing guarantees, but it ultimately provides a very similar set of features. | I believe such functionality to be central to OLPC and should | not be used interchangeably with anything else as long as you have and | msh0 interface ;-) Cerebro _also_ provides a really cool mesh routing protocol. As such, Cerebro (or at least that portion) should ideally run on the network chip, not the main CPU. My kingdom for some Free marvell firmware, etc. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhOyccACgkQUJT6e6HFtqRhGACfcp9nEy0RYJXG+biL/RXUdW31 8W4AnA6+GEN4JD5juwvVFsGGJsB+nNPa =5Sj5 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: On Cerebro, Telepathy, yokes and whites (was Re: cerebro in sugar)
Like Michael pointed out, there are few people at OLPC who understand and enjoy telepathy. I think this is an understatement. Personally, I think that Collabora was very pressed to get something working on the laptop and the resulting presence stack looks like one hack on top of another. For example, there are tons of abstraction layers, yet activities have visibility (while they shouldn't) on how telepathy works (since telepathy is only a dependency to sugar, this should not be the case). Also, the presence service needs to understand if it should switch from salut to gabble, but the broadcast storm caused by salut won't let XO get an IP address through DHCP, which would mean that there's a school server around and. you get the picture! The current plan to attack scalability problems is implementing gadget from scratch which, if I understand correctly, is a plug-in to jabber which already has many problems of its own. Are we sure we're investing our limited time in the right direction? We need Jabber to be working too. For the infra scenario in the schools to work. But if we consider Cerebro an important part of our future (at least I do) we should dedicate more attention to it. I don't know about the arrangements between OLPC and Collabora. It seems to be implied that if Collabora works in the Jabber front it won't be able to work in Cerebro. Is that the case? Really? -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: On Cerebro, Telepathy, yokes and whites (was Re: cerebro in sugar)
On Tue, Jun 10, 2008 at 3:36 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Polychronis Ypodimatopoulos wrote: | Benjamin M. Schwartz wrote: | Polychronis Ypodimatopoulos wrote: | | 2) Make provision in both sugar and activities so that there is a clear | | abstraction from telepathy so that _if_ a better collaboration stack | | comes along, telepathy won't be hardcoded in sugar. This mainly | | involves documenting the existing calls from sugar/activities to | | telepathy (and objects returned thereof) and signals provided by | telepathy. | | Telepathy _is_ that abstraction. It exists specifically so that | different | underlying collaboration mechanisms can be used interchangeably. For | example, Telepathy can run over not only Jabber but also IRC, MSN, AIM, | and other protocols. It seems perfectly reasonable to add Cerebro to | this | list. | | I thought we were talking about collaboration. MSN, IRC etc are | basically chat protocols. Cerebro has little to do with such protocols; | its goal is to provide efficient and scalable presence and data sharing | in an ad-hoc, mobile environment where even IP addresses are a burden to | maintain. AIM, MSN, IRC, and Cerebro are all protocols that provide message channels, file transfer, and presence info. Cerebro is different in that it is designed to run on networks that do not have strong routing guarantees, but it ultimately provides a very similar set of features. A swiss army knife is never as simple as a knife. When what you need is a knife, trying to find the proper thing to pull out your swiss army knife may cost your life. We've made a mistake if we decided that an all encompassing framework is what we needed in an XO. That's in the past and certainly there was a good reason by the time. The real question is: can we fix this mistake now? | I believe such functionality to be central to OLPC and should | not be used interchangeably with anything else as long as you have and | msh0 interface ;-) Cerebro _also_ provides a really cool mesh routing protocol. As such, Cerebro (or at least that portion) should ideally run on the network chip, not the main CPU. My kingdom for some Free marvell firmware, etc. Really? Could you develop? Cheers Ricardo Carrano ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: On Cerebro, Telepathy, yokes and whites (was Re: cerebro in sugar)
On Tue, Jun 10, 2008 at 7:05 PM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: Like Michael pointed out, there are few people at OLPC who understand and enjoy telepathy. I think this is an understatement. Personally, I think that Collabora was very pressed to get something working on the laptop and the resulting presence stack looks like one hack on top of another. For example, there are tons of abstraction layers, yet activities have visibility (while they shouldn't) on how telepathy works (since telepathy is only a dependency to sugar, this should not be the case). Hello Polychronis, Really? My understanding is that telepathy is dependency for activities to, the abstraction layer they use to communicate on the network. Now, the nightmare strikes back: I have to go back to implementing a connection manager. Tomeu has a point: How many people you know that understands and enjoys any of mozilla, gtk, pygtk, abiword, X, cairo, etc?. But when did OLPC start doing compromises? The whole software stack is full of compromises, we have to make them for a couple of reason: * We have finite (read ridiculously limited) time and resources. On the short time a decent user experience is more important than a perfect architecture. * We have to interoperate with existing software for a bunch of good reason that I'm not going to explain here. And if you have to do a compromise, it's better not to do it at such a critical point like the collaboration in sugar. Here's what I propose: 1) Someone should take the lead at implementing a connection manager and I will actively participate, not just by adapting cerebro's API if necessary, but also with implementing the necessary stubs for the connection manager. But the skeleton must be well understood by the person implementing it! Sounds totally like a good idea to me, since you tried to do it yourself but was not able to. Everyone seem to have an high opinion on Cerebro and testing showed impressive results so far, so I think it's worth investing some of the Collabora time into it. 2) Make provision in both sugar and activities so that there is a clear abstraction from telepathy so that _if_ a better collaboration stack comes along, telepathy won't be hardcoded in sugar. This mainly involves documenting the existing calls from sugar/activities to telepathy (and objects returned thereof) and signals provided by telepathy. This sounds like a bad idea to me for several reasons: * The abstraction layer needs to be accessible to non-python activities. Unless you want to expose it through DBus, you will have to write it in C (with python bindings). And if I'm not mistake Cerebro is written in python. * Good or bad (I can't have an opinion since I never looked deeply into it) telepathy is already and abstraction layer. We should fix it or replace it, if it has problems, not hide it under another one. * I haven't seen any concrete technical argument against telepathy *API* so far. * We have already a bunch of activities out of there which are using the current API, so it's kinda late to introduce an abstraction layer to avoid breaking them in the future. If you think telepathy API is irremediably broken, I suggest you focus on coming up with an alternative which meets all the requirements (included working for non python activities) and at the same time it's technically superior to the telepathy one (enough to be worth an API break of these dimensions). 3) Get cerebro into joyride which will help a lot with the upcoming multi-hop tests: humans will be operating and updating their XO that participates in the mesh in MIT campus, so I think it is critical to have cerebro in joyride. Am I wrong? I don't see any issue in doing that. Just my 0.02$ Cheers, Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: On Cerebro, Telepathy, yokes and whites (was Re: cerebro in sugar)
On Tue, Jun 10, 2008 at 7:51 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 7:05 PM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: * The abstraction layer needs to be accessible to non-python activities. Unless you want to expose it through DBus, you will have to write it in C (with python bindings). And if I'm not mistake Cerebro is written in python. So expose it through DBus. This is done already, if I understand correctly. * I haven't seen any concrete technical argument against telepathy *API* so far. I've got a concrete non-technical objection: kids at gamejams invariably want to write a multiplayer game. Almost none succeed. This tells me we need a better collaboration API. You can argue that this simple API should be *on top* of the lower-level telepathy (or cerebro) API, and I won't argue. But we need *something* which a 12-year old can use. If you think telepathy API is irremediably broken, I suggest you focus on coming up with an alternative which meets all the requirements (included working for non python activities) and at the same time it's technically superior to the telepathy one (enough to be worth an API break of these dimensions). My personal metric revolves around tutorials: can you write a simple and straightforward guide to using your API? I haven't seen such a thing yet for telepathy or cerebro; the first one to come up with such a thing would score points in my personal metric (not the only one which counts, of course). http://www.pygame.org/wiki/tutorials http://www.pygtk.org/pygtk2tutorial/ -- for big kids --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: On Cerebro, Telepathy, yokes and whites (was Re: cerebro in sugar)
Ricardo Carrano wrote: We need Jabber to be working too. For the infra scenario in the schools to work. But if we consider Cerebro an important part of our future (at least I do) we should dedicate more attention to it. I don't know about the arrangements between OLPC and Collabora. It seems to be implied that if Collabora works in the Jabber front it won't be able to work in Cerebro. Is that the case? Really? Not really, no, we'd be happy to work on using Cerebro to implement the Telepathy APIs. We do however have a limited amount of resources to dedicate to on our work for OLPC, and they are spent as directed by the management at 1CC, as represented to us by Michael Stone. Currently the main priority for us is implementation of the XMPP server component (Gadget) to handle activity/buddy discovery and hence allow greater numbers of users on one XMPP server, and allow us to consider other XMPP daemons besides ejabberd. It's my opinion that we should also dedicate some of our resources to working on Telepathy - Cerebro integration too, so that we can make some comparisons and see how well the existing activities and UIs behave on a hopefully more mesh-friendly backend. We're currently discussing with Michael and the folks at 1CC how/when we can make this happen. Regards, Rob ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: On Cerebro, Telepathy, yokes and whites (was Re: cerebro in sugar)
We are discussing this and the best use of resources to get to 8.2.0 and beyond. There will be many more discussions. I would like to figure out how to make progress on cerebro. Kim On Tue, Jun 10, 2008 at 9:34 PM, Robert McQueen [EMAIL PROTECTED] wrote: Ricardo Carrano wrote: We need Jabber to be working too. For the infra scenario in the schools to work. But if we consider Cerebro an important part of our future (at least I do) we should dedicate more attention to it. I don't know about the arrangements between OLPC and Collabora. It seems to be implied that if Collabora works in the Jabber front it won't be able to work in Cerebro. Is that the case? Really? Not really, no, we'd be happy to work on using Cerebro to implement the Telepathy APIs. We do however have a limited amount of resources to dedicate to on our work for OLPC, and they are spent as directed by the management at 1CC, as represented to us by Michael Stone. Currently the main priority for us is implementation of the XMPP server component (Gadget) to handle activity/buddy discovery and hence allow greater numbers of users on one XMPP server, and allow us to consider other XMPP daemons besides ejabberd. It's my opinion that we should also dedicate some of our resources to working on Telepathy - Cerebro integration too, so that we can make some comparisons and see how well the existing activities and UIs behave on a hopefully more mesh-friendly backend. We're currently discussing with Michael and the folks at 1CC how/when we can make this happen. Regards, Rob ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: On Cerebro, Telepathy, yokes and whites (was Re: cerebro in sugar)
Ricardo Carrano wrote: On Tue, Jun 10, 2008 at 3:36 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Polychronis Ypodimatopoulos wrote: | I thought we were talking about collaboration. MSN, IRC etc are | basically chat protocols. Cerebro has little to do with such protocols; | its goal is to provide efficient and scalable presence and data sharing | in an ad-hoc, mobile environment where even IP addresses are a burden to | maintain. AIM, MSN, IRC, and Cerebro are all protocols that provide message channels, file transfer, and presence info. Cerebro is different in that it is designed to run on networks that do not have strong routing guarantees, but it ultimately provides a very similar set of features. A swiss army knife is never as simple as a knife. When what you need is a knife, trying to find the proper thing to pull out your swiss army knife may cost your life. We've made a mistake if we decided that an all encompassing framework is what we needed in an XO. That's in the past and certainly there was a good reason by the time. The real question is: can we fix this mistake now? If you say you need to see presence, send text messages, transfer files *and* transmit streams of data for collaborative applications, then we don't just need a knife, we need the screwdriver, corkscrew and can opener. A swiss army knife isn't such a bad option, unless you want to carry around a whole toolbox. :) More seriously, I don't think it's fair to qualify this as a mistake, and in fact I'm not that sure Telepathy should be described just as an all encompassing framework. It's primarily an API for accessing a variety of functionality which are common to different communications mechanisms. I'm not (too) ashamed to admit that for various reasons, some errors in judgement were made with the implementations we've ended up with, but I don't believe these are inherent to the API in use, and we've got plans for rectifying them. Making and testing a Telepathy implementation that uses Cerebro is part of these plans. Cheers Ricardo Carrano Regards, Rob ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: On Cerebro, Telepathy, yokes and whites (was Re: cerebro in sugar)
C. Scott Ananian wrote: I've got a concrete non-technical objection: kids at gamejams invariably want to write a multiplayer game. Almost none succeed. This tells me we need a better collaboration API. You can argue that this simple API should be *on top* of the lower-level telepathy (or cerebro) API, and I won't argue. But we need *something* which a 12-year old can use. Yes. The entire concept of Telepathy Tubes was conceived of by us and dcbw with these two ideas in mind: a) how can we efficiently expose the one-to-many nature of the mesh to application authors who are already working comfortably with Telepathy and D-Bus - this resulted in D-Tubes (at the time, this was believed to be achievable via multicast, and hopefully now with Cerebro, may well be realistically achievable) b) how can we allow existing stream protocols to be used in a way that allows the Telepathy connection manager to do extra work to establish connections in the situations where ordinary TCP connections would fail (you're behind NATs, you're avoiding TCP/IP, whatever) - this resulted in stream tubes As I said to Jim when he visited us in (t'other) Cambridge a couple of weeks ago, any clearer requirements were pretty thin on the ground at the time, so it wasn't clear to us what the needs of the collaborative applications would actually be, so we decided to start by making these available, and see what concrete use cases people came up with. Unfortunately, we started our implementation work with D-Tubes, and stream tubes were quite slow to follow, so what actually ended up happening was the authors of the activities we have adapting to the quirks of the APIs we initially provided. For instance, Abiword's Write activity, whose first implementation was a TCP server to which clients connected, could've been shared via a stream tube with a couple of method calls, but instead grew a backend which layered these one to one communications over the one-to-many D-Tube, and I think Record also contains an implementation of streaming files over D-Tubes. In reality, and I think the past year or so has shown us, most users of Telepathy, and Sugar activity authors in particular, shouldn't need to be be exposed to the vagaries of D-Bus, and certainly not forced to speak it to make collaborative activities. On the other hand, I'm not very sure that for beginner programmers, implementing well-behaved (non-blocking, robust, etc) BSD socket code is that straightforward either, and doesn't really provide very easy mechanisms for sharing state between multiple participants. However, the Telepathy API is inherently extensible and we may also conceive of further primitives besides D-Tubes and stream tubes which we can implement to hide some of the the complexities of network programming (and distributed consistency, etc) from activity authors. Or as you say, we could provide something which did that on top of Telepathy, if the current APIs were deemed to be suitable to allow that. We just need a better idea of what those alternative primitives should look like. Regards, Rob ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
