On Wed, May 28, 2008 at 1:47 AM, Greg Smith (gregmsmi) <[EMAIL PROTECTED]> wrote: > On the school server plan, keep us posted on identity scheme. I'm moving > ahead with EduBlog project. One intern (Tarun) is on board and a > probably a few volunteer programmers in Montevideo. I hope we can send > much more details on the design proposal and get your comment and buy in > soon. Current thinking (Spanish and English below) is at: > http://wiki.laptop.org/go/Blog_Educativo_Plan_del_Proyecto > > Comments and questions welcome.
Here's my notes Blogging proj review Good blueprint :-) My notes are complementary to what you have there. Most are general webapp "XS-fication" rules :-) we should polish a bit and move to a wikipage • Don't count on an admin UI. I am trying to minimise those - and "no special admin UI" is a goal here. Technical options must be automatically preset (perhaps with the country customisation of the XS), less technical options are under the control of teachers. • Users can just go to "school" (resolves to homepage of the XS - we should have that localised - escuela - too) and click on the "blog" link :-) • Keep track of dependencies - be conscious of whether F7 has the modules/libraries you need or they need to be packaged, and whether the current XS build has them. • Webserver - assume apache for the time being, but we may change this later. Not a big problem hopefully - • DB - assume Postgres 8.x series, support mySQL. This is what we have right now, performance is on par w mySQL and has an excellenttrack record where it comes to data preservation in the face of power loss and kernel panics. Bonus points if you can support Pg 8.3 (which changes some CAST semantics - ouch) • Languages: XS will have mod_php and mod_python, as well as libs to make both languages usable. If you can, stick to those. • Avoid daemons and heavy cronjobs - if you have cronjobs, make them check whether there's a job for them to do in the cheapest way possible. Blog sync notes: When you are working on the sync of blog entries, I would suggest to keep a queue of actions/blogs/comments that need to be sync'd from the XS to the external blog. Assuming the XS-to-internet connection is unreliable, high latency and low bandwidth, that queue can drive the proces with minimum traffic, and simple "retry" strategies. The remote end should make the retries safe because the XS could be retrying actions that succeeded (but that the XS never heard the ACK for). Perhaps something in the protocol that identifies the "transaction" uniquely (so the remote end keps track of recent successful transactions). If you do use an identifier, don't make them sequential :-) Im not sure what the editing/publish-to-XS UI will look like, but you might want to have a simple version of the above strategy in the XO. One thing conspicuously missing (not from your plan but from mine :_-) ) is "how do we identify teachers and administrators", "how do we relate teachers with 'courses'" which is something we are trying to flesh out ATM. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Server-devel mailing list [email protected] http://lists.laptop.org/listinfo/server-devel
