gathering use cases

Tony Anderson tony at
Fri Nov 9 12:16:11 EST 2012


A server provides services to client computers. These services enable 
and shape the interaction of users with the client. For example, web 
pages are delivered to the user by a browser. However, the web pages are 
delivered to the browser by a service on the server side, e.g. Apache.

Suppose that a deployment wants email capability (a use case). The 
standard server side service is pop3 and smtp. Thunderbird is a possible 
client-side application for these services.
Most discussions on the lists are based on direct login to gmail which 
does not requires only httpd (Apache) on the server side. However, this 
means that email access only when the XO is connected to the internet. A 
client-side email client could enable email to be prepared offline and 
to be read offline. How would email capability be provided by 
sneaker-net with a usb drive, e.g. for someone to periodically take the 
usb key to an internet cafe and send/receive email?


On 11/09/2012 12:09 AM, Sameer Verma wrote:
> To clarify, by use case, we mean a way to describe the interaction of 
> people with a system. In this case, it may be how a child interacts 
> with the XO, and the XS (via XO) or how a teacher may interact with 
> the XS (via XO or otherwise) by using Moodle.
> As you may have noticed, pretty much every response on this thread 
> focuses on the system, with the assumption that the user end of it is 
> understood well. I am not so sure.
> Take a look at 
> to see if it helps you understand the idea behind use cases and user 
> stories.
> Here's another example of how use cases can vary by being very high 
> level (which is what we are aiming for) and can be user centric or 
> system centric.
> Our focus is user centric, in a way where we would like to describe 
> the actors (children, parents, teachers, admin, etc) and their actions 
> (access class information, read books, send email) without the XS as 
> the focus. Networking topology, storage, UI, LMS, DNS, etc. should 
> flow from the storytelling exercise.
> We are a bunch of technologists and it is easy to get carried away by 
> designing from the tech and not the user end. Sometimes that misses 
> the mark. We may build it and they may not come.
> cheers,
> Sameer
> On Thu, Nov 8, 2012 at 4:07 PM, Sridhar Dhanapalan 
> <sridhar at <mailto:sridhar at>> wrote:
>     On 9 November 2012 10:19, Tony Anderson <tony at
>     <mailto:tony at>> wrote:
>     > Hi, Sridhar
>     >
>     > Thanks for the clarification. I guess I was mislead by
>     statements such as:
>     >
>     > The platform for the One Network server is an ARMv7-based XO,
>     running the
>     > One Education OS (based on OLPC OS). This makes development, and
>     deployment
>     > and support far simpler than a standalone distribution. The OS
>     can be
>     > extended with server capabilities using a bootable USB
>     Customisation Stick
>     > (offline) or yum.
>     >
>     > Please accept my apology if any statement I have made seemed
>     uncivil, that
>     > was certainly not my intention. Communicating by email in
>     certainly much
>     > more hazardous in this regard than face-to-face.
>     Thank you, Tony. I was quite careful to take your needs into account
>     when I wrote the design doc, so I had trouble understanding your
>     opposition to the idea.
>     Maybe we can make the doc clearer somehow? I structured it as:
>       1. context
>       2. Community XS design
>       3. One Network server
>     The Community XS design itself is flexible enough to handle a variety
>     of different deployments' needs. One Network server is merely one
>     configuration of the Community XS, mentioned as an example of what can
>     be done.
>     > Just as the deployments you are supporting have specific and
>     urgent needs,
>     > so do the ones I am working with. I don't believe either of us
>     is pursuing
>     > personal desires. We certainly can easily differ on which is the
>     appropriate
>     > technical approach to solving the problems of a deployment.
>     I think we generally want the same thing in the end. I'm happy to
>     continue the conversation to improve the design and implementation. I
>     sincerely believe that this design can accommodate your needs.
>     > I really appreciate this specification:
>     >
>     >
>     >   * this is a flexible design, built on Fedora
>     >   * it will run anywhere where x86 or ARM Fedora will work
>     >   * it can be installed on top of an existing Fedora installation
>     > using 'yum groupinstall xsce'
>     >   * being designed in this way provides extreme flexibility for
>     deployments
>     >   * all current features of the XS (Moodle, etc.) will be
>     ported, but
>     > will be optional
>     >   * installation and configuration will be easy, but sysadmins
>     will be
>     > able to treat it like any Fedora installation
>     Awesome. I hope this also satisfies your desire to have it rebased to
>     Fedora to work on ARM systems. That's a key goal of this project,
>     while maintaining compatibility with x86.
>     > There is clearly a great deal to be gained by a community taking
>     > responsibility for the ongoing development and maintenance of
>     the school
>     > server as neither Daniel Drake nor Martin Langhoff are likely to
>     have
>     > adequate time for this in the foreseeable future.
>     Indeed. A motivating factor was to take some of the load off some of
>     these prolific people and spread it out to the community in a
>     sustainable way.
>     Cheers,
>     Sridhar
>     _______________________________________________
>     Devel mailing list
>     Devel at <mailto:Devel at>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Devel mailing list