<div dir="ltr">Thanks Tony for this comprehensive summary below prep'ing all for SF's XS(CE) sprint in 9 days!<br><div class="gmail_quote"><div dir="ltr"><br>Original Wish List:<br><a href="https://docs.google.com/document/d/1FVUFl6vry8u9b_lNSXvcWKN6hgVB-7Je4aTBpvq0QVg" target="_blank">https://docs.google.com/document/d/1FVUFl6vry8u9b_lNSXvcWKN6hgVB-7Je4aTBpvq0QVg</a><br>
<br>Sprint Starting Line:<br><a href="http://wiki.laptop.org/go/XS_Community_Edition/0.5/Sprint" target="_blank">http://wiki.laptop.org/go/XS_Community_Edition/0.5/Sprint</a><br><br><div class="gmail_extra"><div><div class="h5">
<br><br><div class="gmail_quote">On Fri, Oct 11, 2013 at 2:40 PM, Tony Anderson <span dir="ltr"><<a href="mailto:tony_anderson@usa.net" target="_blank">tony_anderson@usa.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Adam requested someone to attempt an
organization of the XSCE-0.5 Wish list.<br>
I am totally unqualified for this, but made a stab anyway.<br>
<br>
The comments in the features portion are mine. The comments in the
Workflow and Development sections are from the original.<br>
<br>
I hope this helps.<br>
<br>
Tony<br>
<br>
PS. Formatting is based on tiddly-wiki markup. I can supply a copy
of the markup.<br>
<h1>Community and Workflow</h1>
<ol>
<li><b>Feature proposal and selection</b>
<ul>
<li>I propose we start following a feature proposal and
selection process similar to upstream sugar (or what it
used to be). </li>
<li>Basically,the person or group proposing the feature
creates a feature page following a template [3], which
contains all the necessary details to make a go-no-go
decision. Then it is discussed in a mailing list and if
need be, in an IRC meeting.</li>
</ul>
</li>
<li><b>Lets start using the bugtracker more (and formally
so) [4].</b>
<ul>
<li>A bugtracker can be a very valuable resource for new
developers wanting to contribute and looking for things to
do, and for keeping track of project development progress.</li>
</ul>
</li>
<li><b>Volunteers for owning and maintaining different
aspects of the project</b>
<ul>
<li>Some examples could be
<ul>
<li> FAQ</li>
<li> Wiki as a whole</li>
<li> User-documentation</li>
<li> Project development manager</li>
<li> Coordinating with interested deployments</li>
<li> Supported hardware platforms</li>
</ul>
</li>
</ul>
</li>
<li><b>wiki support</b>
<ul>
<li>Just like code, the wiki also needs a lot of love, and
there may be many contributors willing to pitch in, so I
propose that.
<ul>
<li>Post notification of every wiki change to the IRC
channel.</li>
<li>Post notification of every wiki change to the
mailing list.</li>
</ul>
</li>
</ul>
</li>
<li><b>Have a forum.</b>
<ul>
<li>A place where Q&A's can be asked and answered in
human-understandable formats. (thought: perhaps look at
how large we are as a community and then decide).</li>
</ul>
</li>
<li><b>Proposal-1 : Shifting from redmine to github</b>
<ul>
<li> Move the xsce source code from the repository hosted on
redmine to a repository hosted on github.</li>
<li> For open/public repositories, github offers an
unlimited amount of members and collaboration. This comes
at a zero dollar cost.</li>
<li> A xsce user will be created and the xsce repository
hosted under it. All people who have commit access
currently will have the same rights.</li>
<li> The buildbot will be pointed to the github repo, so
builds will continue as usual.</li>
<li> Eg: DXS is on github, Sugar has been on github for
quite a while.
<ul>
<li>From the experience of DXS team (Me, Santi, Anna,
Miguel), this is a recommended step.</li>
<li>Pros:
<ul>
<li> Github offers a much better collaborative
workflow with pull requests.</li>
<li> Github offers better code visibility and
reviews in the GUI itself.</li>
<li> Here's an explanatory video that Miguel
created: <a title="External link
to http://www.youtube.com/watch?v=CEE85F3Zjcs" href="http://www.youtube.com/watch?v=CEE85F3Zjcs" target="_blank">http://www.youtube.com/watch?v=CEE85F3Zjcs</a></li>
</ul>
</li>
</ul>
</li>
<li>I (Anish) strongly believe that we need to shift our
codebase to github. I'm saying that even though the code
is currently hosted on AC infrastructure. The biggest
benefit of moving to github would be much better code
visibility. It will make it easier for new developers to
join in the development process. We switched dextrose
server to github about a month and a bit ago, and will
never look back.</li>
</ul>
</li>
<li><b>Proposal-2 : Notifications for source code commits
to IRC.</b>
<ul>
<li>This is a well accepted practice to keep community
members informed and involved about code changes and the
development process.</li>
</ul>
</li>
<li><b>Proposal-3 : Notifications for source code commits
to the mailing<br>
list.</b>
<ul>
<li>This is a deliberate effort to again encourage better
transparency, collaboration.</li>
<li><a title="The
tiddler 'Option-A' doesn't yet exist">Option-A</a> : Send the
notifications to server-devel. Since the mailing list is
the single static archived place where everyone is
subscribed,it makes sense to send notifications here.</li>
<li><a title="The
tiddler 'Option-B' doesn't yet exist">Option-B</a> : Send to a separate
mailing list. Those who are interested in development, may
subscribe to it.</li>
<li><a title="The
tiddler 'Option-C' doesn't yet exist">Option-C</a> : Github already offers
the functionality to subscribe to updates. Individual
users can sign up to get notified about updates to the
repository.</li>
</ul>
</li>
</ol>
<h1>Development Procedure</h1>
<ol>
<li><b>Switch to Ansible</b>
<ul>
<li>Many folks have suggested quite a number of valuable
features for the 0.5 iteration [1], but I believe it will
be easier to get to that goal if we switch to ansible.
George has also supported this proposal.</li>
<li>If the community at large decides that it is a sane idea
to port to ansible, doing it first makes sense. </li>
<li>I have created a (WIP) feature page for the same[2]. </li>
<li>A lot of the ansible port has already been done under
the DXS project, so it should ideally be a matter of some
coding and a lot of testing.</li>
</ul>
</li>
</ol>
<h1>Features</h1>
<ol>
<li><b>xsce as vnc reflector ->multicast to clients -gjh</b>
<ul>
<li>Provide a way for the server to broadcast files/web
pages to the <a title="The
tiddler 'XOs' doesn't yet exist">XOs</a>
to improve performance when the teacher asks all students
in the class to request the same content. </li>
<li>I suppose squid would be an alternative way to do this.</li>
<li>I am not sure how this will work if the bottleneck is
the router.</li>
</ul>
</li>
<li><b>slide show screencast/sound recorder activity -gjh</b>
<ul>
<li>Not sure what is meant here. </li>
<li><a title="The
tiddler 'ShowNTell' doesn't yet exist">ShowNTell</a> and <a title="The
tiddler 'ClassRoomViewer' doesn't yet exist">ClassRoomViewer</a> address the need
for a way to display the same information on all the <a title="The tiddler 'XOs' doesn't
yet exist">XOs</a> in a classroom.</li>
<li>Screencast adresses the need to prepare a screencast
from an XO session.</li>
</ul>
</li>
<li><b>Plug & play to broadcast presentation available
from XSCE (like IIAB availability, when a USB is plug-in it
XSCE will search default assign folder to display files for
viewing -tk</b>
<ul>
<li>I assume this means that at least some of the data on
the school server is provided by a removable storage
device. Normal server design assumes that the content is
available whether it is on a removable device or an
internal storage device. This requirement is usually met
by a url which accesses a service. </li>
<li>IIAB does not work that way because it was designed for
an independent device on a network. </li>
<li>I would think what is needed here is a home page with
buttons to access the various data components.</li>
</ul>
</li>
<li><b>SD card boot from an XO can register with
schoolserver with unique ID not link to XO serial-no -tk</b>
<ul>
<li>Registration with the school server (XS maybe not XSCE)
creates a user and a folder based on the serial-number.
This is done once. This registration is only used for
Journal backup and Moodle login.</li>
<li>I assume the goal here is to support shared use of the
XO by separating the user from the serial-number.</li>
<li>This would normally be done by a login: username and
(optional) password. The original goal of Sugar was to
avoid logins.</li>
<li>I am not sure how the sd-card fits here.</li>
</ul>
</li>
<li><b>Authentication across all services (similar to
moodle) without passwords -gjh</b>
<ul>
<li>Authentication in <a title="The
tiddler 'XS-0' doesn't yet exist">XS-0</a>.7
depends on the service. </li>
<li>Most services are available to any connected XO. </li>
<li>Services requiring authorization do so by public/private
keys (e.g. Journal backup). </li>
<li>Moodle is an exception because it was designed to
support enrollment in university courses requiring
tuition. Martin Langhoff came up with the current scheme
to enable login to be authenticated by serial number using
mechanisms already in Moodle.</li>
</ul>
</li>
<li><b>Framework for user, and group, access control lists
for web applications -gjh</b>
<ul>
<li>In a school context, the Karma Learning System requires
the school to create a list of all persons who have been
assigned <a title="The
tiddler 'XOs' doesn't yet exist">XOs</a>.
There is also a list of <a title="The tiddler 'XOs' doesn't yet exist">XOs</a>. This information is used to
recognize staff members who have special privileges and to
provide appropriate lessons to students based on their
grade (actually, like Moodle, the courses in which they
are enrolled - which in primary school is the same thing).</li>
<li>This 'framework' is based on Django for convenience. It
is available to any web application on the school server.</li>
</ul>
</li>
<li><b>“bonjour /avahi announce” on xsce, so that headless
trimslice can ssh in without console -gjh</b>
<ul>
<li>In <a title="The
tiddler 'XS-0' doesn't yet exist">XS-0</a>.7
this is done by creating a user with the privilege to su.</li>
<li>Assuming the trimslice is the server, the ssh would be
issued by a connected XO. </li>
<li>If the trimslice DHCP service doesn't start (i.e.
connection via the LAN is not possible), then the server
needs a head to resolve the issue. </li>
<li>It would be great if the schoolserver had a direct
connect method (e.g. a crossover ethernet connect via the
WAN port to an XO which is the technique used by OLE
Nepal).</li>
</ul>
</li>
<li><b>suExec privilege escalation for cgi and html running
on apache (model and template) -gjh</b>
<ul>
<li>I assume this is a user with superuser privileges. This
is normally available by ssh to admin and then su to root.
The goal is to allow modification to files requiring root
permission.</li>
<li>html has special security concerns to prevent malicious
users from doing damage. This often is exasperating for
well-meaning users wanting to do good.</li>
</ul>
</li>
<li><b>vlc multicast from xsce to xo’s -gjh</b>
<ul>
<li>Normally, media files are streamed to clients. </li>
<li>In the special case of a teacher requesting all students
to play a particular media file concurrently, multicast
streaming could reduce the network bandwidth. </li>
<li>Do common routers support multicast? What impact would
this have on routers in other classrooms?</li>
<li>In the case of school deployments, I expect that the
media file should be downloaded to the Journal and played
by Jukebox.</li>
</ul>
</li>
<li><b>javascript version of vnc client on xsce serving
XSCE console in XFCE GUI window manager ->headless server
admin -gjh</b>
<ul>
<li>This capability is available by ssh from the Terminal
Activity. Javascript has security limitations which make
this approach problematic.</li>
</ul>
</li>
<li><b>XSCE sleep functionality, for really low power
situations, automatically sleep and wake up for the school
day -gjh</b>
<ul>
<li>The easiest solution is human. Have someone turn off the
server at the end of the day - one push on the power
button. Have that person turn it on at the start of the
day - one push of the power button.</li>
</ul>
</li>
<li><b>Printer (GUI/queue) -tony</b>
<ul>
<li>This requires cusp installed on the server. The XO could
submit a print job with Journal Share. </li>
<li>A teacher or administrator could authorize the print job
via a separate service (e.g Django view). **The big
problem with school printers is the cost of paper and ink.
Most schools must control print volume.</li>
</ul>
</li>
<li><b>Email (offline support) [mail server for
not-always-on internet, store and forward] -tony</b>
<ul>
<li>This needs a light-weight mail client on the XO. </li>
<li>It needs pop3 and smtp service on the server. </li>
<li>There has to be a email address assigned to each user
with a domain compatible with the Internet. </li>
<li>Ideally, students and staff could send emails to each
other. </li>
<li>Emails to recipients on the Internet could be
sent/received during periodic access (dial-up modem style)
or by a mechanism to put the email messages on a usb drive
to be sent from an internet cafe.</li>
<li>Some corresponding mechanism to receive all mail to the
school at the internet cafe to store on the usb key. </li>
<li>This mail would be loaded on the school server in the
smtp repository for ultimate delivery.</li>
</ul>
</li>
<li><b>Run on new intel/Atom (Classmate too?) hardware
-tony</b>
<ul>
<li>In addition to run, this includes install. With <a title="The tiddler 'XS-0' doesn't
yet exist">XS-0</a>.7, the install
is done by Anaconda, kickstart from a usb-drive. Once the
school server is running, the content is loaded from an
external usb drive.</li>
</ul>
</li>
<li><b>Better ARM support -jon</b>
<ul>
<li>Perhaps the community knows what problems 'better'
refers to.<br clear="all"><br>-- <br><div dir="ltr">Unsung Heroes of OLPC, interviewed live @ <a href="http://unleashkids.org" target="_blank">http://unleashkids.org</a> !</div>
</li></ul></li></ol></div>
</div></blockquote></div></div></div></div></div></div></div>