[Server-devel] Fwd: [XSCE] XSCE Wish List

Adam Holt holt at laptop.org
Sat Oct 12 00:28:29 EDT 2013


Thanks Tony for this comprehensive summary below prep'ing all for SF's
XS(CE) sprint in 9 days!

Original Wish List:
https://docs.google.com/document/d/1FVUFl6vry8u9b_lNSXvcWKN6hgVB-7Je4aTBpvq0QVg

Sprint Starting Line:
http://wiki.laptop.org/go/XS_Community_Edition/0.5/Sprint



On Fri, Oct 11, 2013 at 2:40 PM, Tony Anderson <tony_anderson at usa.net>wrote:

>  Adam requested someone to attempt an organization of the XSCE-0.5 Wish
> list.
> I am totally unqualified for this, but made a stab anyway.
>
> The comments in the features portion are mine. The comments in the
> Workflow and Development sections are from the original.
>
> I hope this helps.
>
> Tony
>
> PS. Formatting is based on tiddly-wiki markup. I can supply a copy of the
> markup.
> Community and Workflow
>
>    1. *Feature proposal and selection*
>       - I propose we start following a feature proposal and selection
>       process similar to upstream sugar (or what it used to be).
>       - 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.
>     2. *Lets start using the bugtracker more (and formally so) [4].*
>       - 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.
>     3. *Volunteers for owning and maintaining different aspects of the
>    project*
>       - Some examples could be
>          - FAQ
>          - Wiki as a whole
>          - User-documentation
>          - Project development manager
>          - Coordinating with interested deployments
>          - Supported hardware platforms
>         4. *wiki support*
>       - 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.
>          - Post notification of every wiki change to the IRC channel.
>          - Post notification of every wiki change to the mailing list.
>         5. *Have a forum.*
>       - 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).
>     6. *Proposal-1 : Shifting from redmine to github*
>       - Move the xsce source code from the repository hosted on redmine
>       to a repository hosted on github.
>       - For open/public repositories, github offers an unlimited amount
>       of members and collaboration. This comes at a zero dollar cost.
>       - 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.
>       - The buildbot will be pointed to the github repo, so builds will
>       continue as usual.
>       - Eg: DXS is on github, Sugar has been on github for quite a while.
>          - From the experience of DXS team (Me, Santi, Anna, Miguel),
>          this is a recommended step.
>          - Pros:
>             - Github offers a much better collaborative workflow with
>             pull requests.
>             - Github offers better code visibility and reviews in the GUI
>             itself.
>             - Here's an explanatory video that Miguel created:
>             http://www.youtube.com/watch?v=CEE85F3Zjcs
>            - 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.
>     7. *Proposal-2 : Notifications for source code commits to IRC.*
>       - This is a well accepted practice to keep community members
>       informed and involved about code changes and the development process.
>     8. *Proposal-3 : Notifications for source code commits to the mailing
>    list.*
>       - This is a deliberate effort to again encourage better
>       transparency, collaboration.
>       - Option-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.
>       - Option-B : Send to a separate mailing list. Those who are
>       interested in development, may subscribe to it.
>       - Option-C : Github already offers the functionality to subscribe
>       to updates. Individual users can sign up to get notified about updates to
>       the repository.
>
> Development Procedure
>
>    1. *Switch to Ansible*
>       - 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.
>       - If the community at large decides that it is a sane idea to port
>       to ansible, doing it first makes sense.
>       - I have created a (WIP) feature page for the same[2].
>       - 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.
>
> Features
>
>    1. *xsce as vnc reflector ->multicast to clients -gjh*
>       - Provide a way for the server to broadcast files/web pages to the
>       XOs to improve performance when the teacher asks all students in
>       the class to request the same content.
>       - I suppose squid would be an alternative way to do this.
>       - I am not sure how this will work if the bottleneck is the router.
>     2. *slide show screencast/sound recorder activity -gjh*
>       - Not sure what is meant here.
>       - ShowNTell and ClassRoomViewer address the need for a way to
>       display the same information on all the XOs in a classroom.
>       - Screencast adresses the need to prepare a screencast from an XO
>       session.
>     3. *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*
>       - 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.
>       - IIAB does not work that way because it was designed for an
>       independent device on a network.
>       - I would think what is needed here is a home page with buttons to
>       access the various data components.
>     4. *SD card boot from an XO can register with schoolserver with
>    unique ID not link to XO serial-no -tk*
>       - 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.
>       - I assume the goal here is to support shared use of the XO by
>       separating the user from the serial-number.
>       - This would normally be done by a login: username and (optional)
>       password. The original goal of Sugar was to avoid logins.
>       - I am not sure how the sd-card fits here.
>     5. *Authentication across all services (similar to moodle) without
>    passwords -gjh*
>       - Authentication in XS-0.7 depends on the service.
>       - Most services are available to any connected XO.
>       - Services requiring authorization do so by public/private keys
>       (e.g. Journal backup).
>       - 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.
>     6. *Framework for user, and group, access control lists for web
>    applications -gjh*
>       - In a school context, the Karma Learning System requires the
>       school to create a list of all persons who have been assigned XOs.
>       There is also a list of XOs. 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).
>       - This 'framework' is based on Django for convenience. It is
>       available to any web application on the school server.
>     7. *“bonjour /avahi announce” on xsce, so that headless trimslice can
>    ssh in without console -gjh*
>       - In XS-0.7 this is done by creating a user with the privilege to
>       su.
>       - Assuming the trimslice is the server, the ssh would be issued by
>       a connected XO.
>       - 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.
>       - 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).
>     8. *suExec privilege escalation for cgi and html running on apache
>    (model and template) -gjh*
>       - 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.
>       - html has special security concerns to prevent malicious users
>       from doing damage. This often is exasperating for well-meaning users
>       wanting to do good.
>     9. *vlc multicast from xsce to xo’s -gjh*
>       - Normally, media files are streamed to clients.
>       - In the special case of a teacher requesting all students to play
>       a particular media file concurrently, multicast streaming could reduce the
>       network bandwidth.
>       - Do common routers support multicast? What impact would this have
>       on routers in other classrooms?
>       - In the case of school deployments, I expect that the media file
>       should be downloaded to the Journal and played by Jukebox.
>     10. *javascript version of vnc client on xsce serving XSCE console in
>    XFCE GUI window manager ->headless server admin -gjh*
>       - This capability is available by ssh from the Terminal Activity.
>       Javascript has security limitations which make this approach problematic.
>     11. *XSCE sleep functionality, for really low power situations,
>    automatically sleep and wake up for the school day -gjh*
>       - 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.
>     12. *Printer (GUI/queue) -tony*
>       - This requires cusp installed on the server. The XO could submit a
>       print job with Journal Share.
>       - 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.
>     13. *Email (offline support) [mail server for not-always-on internet,
>    store and forward] -tony*
>       - This needs a light-weight mail client on the XO.
>       - It needs pop3 and smtp service on the server.
>       - There has to be a email address assigned to each user with a
>       domain compatible with the Internet.
>       - Ideally, students and staff could send emails to each other.
>       - 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.
>       - Some corresponding mechanism to receive all mail to the school at
>       the internet cafe to store on the usb key.
>       - This mail would be loaded on the school server in the smtp
>       repository for ultimate delivery.
>     14. *Run on new intel/Atom (Classmate too?) hardware -tony*
>       - In addition to run, this includes install. With XS-0.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.
>     15. *Better ARM support -jon*
>       - Perhaps the community knows what problems 'better' refers to.
>
>       --
>       Unsung Heroes of OLPC, interviewed live @ http://unleashkids.org !
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/server-devel/attachments/20131012/794c4c10/attachment-0001.html>


More information about the Server-devel mailing list