Hi NoiseEHC,
No, it won't... It already happened when Bryan Berry moved OLPC Nepal's
lessons from EToys to Flash, then to HTML5 and there were not any more
contributors. I mean, there are much more JS developers, so if you pay them
you can get cheaper talent, but there will be not too much more contributors
IMHO. The problem is that the current HTML5 work goes into a direction which
I am not sure that needed by anyone other than existing Sugar developers.
Well we are trying to go in the direction you mention below, that is
standard web development. So thanks for jumping in.
It all boils down to this simple question:
If you are a potential contributor wanting to develop some educational
activity (not a framework but some concrete lesson or stuff usable in a
lesson!!!) then which one would you use?
1. A HTML5 + JavaScript activity model called Sugar Web Activity, which
reaches 2-3 million children? (lets call it SWA)
2. A HTML5 + JavaScript activity model called HTML5 + JavaScript, which
reaches 1 billion children? (lets call it WEB)
I have not seen any compelling reason why would a potential contributor
(software developer from a developed country who has/likes children) choose
option 1 instead of 2...
Yes, option two... ideally. We should tend to zero Sugar specific
functionallities. I think it is a good compromise what we did: start
from simple web activities that already work side by side with GTK
ones, and tend to standard webapps.
Now I will not give you constructive criticism as that would allow answering
that I should not tell others what to do and it would be getting old...
Instead here is some nonconstructive criticism:
I think each of the following items deserve a thread on its own. Feel
free to continue discussion.
Some months ago I wanted to create a sample activity to present my point but
I have run out of time so unfortunately I cannot show it to you. It would
have been a Google Drive backed game with shared state (so the same as a
typical shared activity in Sugar) called Scrabble what I try to port to SWA.
It uses the following things which are trivial to use on the WEB but cannot
be found in SWA:
As far as I understand, Google Drive is an online service. Please
note that we are targetting offline webapps, as Sugar is meant to work
without an Internet connection. Of course it is not forbidden. And
Drive could be a nice datastore backend. But not the only one.
1. Sign in. There is no authorization API in SWA so using anything than the
local journal is problematic. Using Google's OAuth authentication from a
file:// protocol is impossible so if you want to support existing code then
you have to serve the activity from http://localhost...
https://developers.google.com/drive/about-auth
Daniel gave a good reply to this one.
2. Datastore. There is no way to access the Google Drive if you cannot
authenticate. I do not see why would anyone use a new JavaScript lib which
accesses only the journal when they are already familiar with some WEB
technology. Like WEBDAV or the OpenStack's SWIFT API.
http://docs.openstack.org/api/openstack-object-storage/1.0/content/storage-object-services.html
Nice. Reading about the WebDAV protocol and OpenStack SWIFT API.
Or simply using POST for uploading:
https://developers.google.com/drive/manage-uploads
Yeah, good point.
3. Collaboration. Using the Google Drive Realtime API is dead simple. It is
the most missing feature from SWA BTW.
https://developers.google.com/drive/realtime/
Interesting. It requires Internet.
I have looked at several open source Operational Transformations libraries
but did not have time to test their performance on an XO...
4. Using WebSockets for simple tasks. The autosaving can be implemented by
the almost standard webkitvisibilitychange event (but you have to compile
webkit with the appropriate parameters) and standard timers. Activity
startup is simplified with per activity data store (POST-ing to the same
server is the default on the WEB). I think it eliminates the communication
with Sugar so no need for WebSockets...
5. Android port. There already exists a multi-platform technology called
PhoneGap. It can target 100-200 million children so it can be called option
3 if you want... It can become obsolete as HTML5 provides more and more of
its features though.
http://phonegap.com/
So as I see you either create a framework which mimics Sugar and no web
developer will use it or create a framework which implements what a web
developer is already using or at least tries to somehow emulate it. So the
web developer does not have to modify his/her code and will consider porting
his/her application for a smaller platform. Of course that would require
OLPC/Sugarlabs to run free OpenStack/OAuth/OT servers for contributors
otherwise everybody will go with Google APIs which cannot easily be emulated
on an XO machine...
So, running and using those servers is what
