[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