Marco Pesenti Gritti wrote: >> is known to work in resource-limited environments > > Just a curiosity, in which environments have it been used?
On the Nokia 770 and N800 Internet Tablets, so 64/128MB RAM and 180/400MHz processors respectively. > 100 contacts seem too limited, or at least out of proportion with 30 per > activity. Maybe a more realistic proportion is 1/10. Our original thought was that the school would have one server, so ~1000 or somesuch, but Dan said that due to the need to split stuff up across RF channels, and the potential that a server would just be another laptop with maybe an uplink to other servers. So our working assumption currently is that we can have several servers in one school, each one serving ~100 users directly, and they can route to each other to see the other users. > Even assuming free JVM, is it worth to have a JVM installed/running for > just this? This is just for the server, but ejabberd looks like it has better support for PEP at the moment, and I think its less resource intensive than Wildfire anyway, so it'll be our first port of call. >> Question: if an activity exists but is not anyone's "current" activity >> (i.e., all buddies switched to a different activity but still have the >> inactive one running in the background), does the PS care about that >> activity at all? > > Totally. It should be still visible on the mesh view. Also there might > be cases of activities which could be evolving and exchanging data even > without active user participation. This was just us pondering whether it was worth buddies publishing all their current activities via the server, or just the active one. All of them isn't too much of a hardship. >> For bandwidth and scalability reasons, the PS will have to filter or >> not subscribe to some presence information for buddies. It needs to >> figure out which buddies and which activities are more relevant to >> Sugar and only deal with those. > > Can you elaborate about this please. Is it just an implementation > details or it effectively limit the information we will be able to > retrieve about a buddy. It's kinda an implementation detail, in that we need to put a limit on how many people the PS will collect/cache info for, and a limit on how much bandwidth it will use retreiving information, but to get this right we need a clearer idea of the people and activities we want to be able to show in the desired UI. We don't want a situation where the PS is pulling down info about 100s of buddies but sugar is choosing to show only a small fraction of them. >> one-to-one channels like an IM or a voice/video call can be made into a >> private activity > > I think activities are inherently social. There might be cases where > private can be used but it's gen2 stuff IHMO. This is just about mapping concepts. In Telepathy (and IM in general) you can get one to one messages and calls, and in the UI we only have concepts of activities, so we were thinking of "upcasting" these to activities to display in the UI. Otherwise we need a different way to represent these one-to-one tasks. >> do we need to migrate activites from the mesh to the server, and if so, >> how do we do it? > > I think this is an important use case. Kids could start activities at > home, in a small group, and then continue it at school, with other > buddies joining it. Implementation-wise, it's very hard to think of a sensible way to have an activity where some users are on the mesh and some are on the server, without ending up using someone as a relay, in which case why can't the other mesh users see the server using him as a mesh node? For migrating all of the mesh users to server users "atomically", this could be arranged by the PS looking at when all of the mesh people are visible through the server, and then arranging a migration then. >> are participants in an activity equal, or is there one person who is >> hosting each activity? > > I don't think there is one true strategy for this. I see it as activity > dependent. Yeah, I think thats what we thought too. >> what does the Sugar API look like? > > That's a very important question and one that we should figure out > early. I'd like to see at least a very general proposal about it. A > starting point could be the current presence service and the plan I and > Dan discussed. But it's unclear, for example, how the tubes will > integrate with it. The current concept is that the presence service will sheperd the Telepathy connections for XMPP and link-local, and pick up the buddies and activies that are deemed relevant, and make them available as Buddy or Activity objects for use from Sugar, similar to the current API. Where it differs is that rather than having Channels and Services exposed in the PS API, we just pass the Telepathy Channels involved up to the UI, and the other concepts (tubes) are exposed there and implemented by interacting directly with the backends. >> If you're sitting next to someone and want to make them your friend, >> but you're both on different mesh RF channels, you won't see them on >> the link-local. > > I'm unclear on how the network structure relates to the UI here. What I > was thinking is that you would just see the friend in the mesh view, > even if he is not on your local link. The problem is about finding people. If you're on mesh channel #6 and talking to a server on #6, and the guy who's sitting next to you is on mesh channel #11 and talking to /his/ server, even if you can talk to him via the server with IP routing, you're not going to see him on your mesh. I don't think it's very scalable to consider the presence service being aware of every single buddy within eg a school. Seeing everyone on your mesh, plus everyone you've marked as friends, and then maybe picking up some extras from the server, would be more reasonable. If you consider the potential traffic from them changing activity etc, so we think some "relevance" heuristic is necessary. But as a consequence of network topology you can end up not seeing the person next to you. :-/ >> How do we implement searching for people as described in the HIG? > > What issues are you seeing with this one? It could just be a search in > the presence service model (unless we want to avoid to fetch part of the > info about buddies). Yeah, this just follows on from the not having all the information about everyone all the time. You can search the people you can see over mesh easily because you get given the mDNS stuff all the time, but searching 1000 people on several servers is tricky. Jabber only has a concept of a User Directory which is searchable by name, alias and e-mail address. Do we need to build something better than this on the server in order to allow the PS to launch searches for people? >> Implementation plan > > I think it's difficult to discuss this before having an idea of what the > API will look like. There is code based on the existing presence service > and we need to figure out a migration plan. That's not quite the case. I think we have a reasonable idea of what shape the API will have, and we've identified some clear areas where we need to modify Telepathy spec/backends to provide extra features, so we can get started on some of this whilst the higher level stuff is nailed down too. > Marco Regards, Rob _______________________________________________ Sugar mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/sugar
