XS meeting notes/2008-11-12
These notes are not complete, because some aspects of what were discussed are internal (production-related, etc.) - I have also withheld the attendance list. This was a closed meeting held at 1cc on 2008 Dec 11. Please let me know if you have any comments, concerns, or questions. Mchua 21:20, 4 January 2009 (UTC)
 Topics discussed during the meeting
- How to support the XS in official deployments
- How to test the XS
 Supported product
(notes by Mchua)
This sentence is probably wrong. I am trying to understand what's wrong with this sentence and where the correct version of this sentence should be found. The technical product OLPC develops and supports is a system of up to 3000 XOs + (optional) XS in a school, with up to 500 XOs simultaneously connected to the XS at one time.
This system is the formally supported product; more functionality may be available (to developers, etc.) but the above is the supported product functionality.
The XS is one component of this system, and can also be thought of as a product itself, with the supported features listed at http://wiki.laptop.org/go/School_Server_Specification.
- (Response from another attendee, paraphrasd:) In terms of what does the XS support that link you refer to is not definitive. It includes too much stuff that is future or planned but not yet available; this is being actively revised. Pages will soon look more like this (as a good example): http://wiki.laptop.org/go/XS_Automount_triggers (note: if you are reading this significantly after 2008 Dec 11, you may want to look at the wiki history for that page.).
 Things OLPC can control
- What we say we will support ("we only guarantee X will work if you meet criteria Y")
 Things OLPC can't control
- How many XOs are at a school
- How many hours they are used by children, specifically how often and for how long students will try to connect to the XS
- How many XSs a school will have (they may have 0)
- How much bandwidth a school will have, and how reliable it is
- What kind of layout (that affects RF) the school has, and what sort of wifi hardware they have access to
 Next-up features under consideration
- A managed roster to allow XOs to connect/collaborate in groups (an XO won't see all 3000 XOs in its school in Neighborhood, it'll see a smaller number of the ones that "make sense" for it to see.) (Not sure what the definition of "makes sense" is in this context.)
- (Continuous, ongoing) Work on the XS software to make the daemons degrade gracefully when XS-capacity-per-XO drops for any reason, be that a larger number of XOs connecting to an XS, or a physical XS machine with less-than-optimal hardware specs.
 Future opportunities
Not being worked on now, but appealing.
- A UI usable by non-sysadmins, particularly for lease management.
- No-signon "logins" for ds-restore (automatically authenticate an XO to get its backup), possibly through a tweak in Browse (and adding a "Get ds backup from XS" link to the default Browse start page).
- Listing the bottlenecks that the XS software has to outperform (i.e. if RF can only handle N XOs, XS software only needs to handle N+1 XOs). Possible starting list (much of this starting list is deployment-specific): RF, bandwidth, collaboration/ejabberd, XS hardware.
- Re: Future opportunities, should these be filed as enhancements somewhere in Trac, so we can keep track of when or in which release they should be worked on? I was not able to find these exact enhancements searching through Trac, the closest was on shared ejabberd rosters in #5310. Mchua 13:08, 12 November 2008 (EST)
- Should the supported product (or product component, if the XS is part of our sole product of a completely working large-scale system) and our support mechanisms for it be listed somewhere? Where? (Public/accessible to who?) Mchua 13:08, 12 November 2008 (EST)