I'm not sure about Gears, but I have worked with the Flash persistence stuff before - you're right, it's quite convenient.  It would be great to build support for finding the storage file and copying it to/from the Journal.  It could even be done automatically by the WebActivity class (or else a separate FlashActivity class if we want to avoid loading Firefox) class, making it transparent to the Flash programmer.  -Wade <div class="gmail_quote"> On Fri, Jan 2, 2009 at 2:46 PM, Bryan Berry <<a href="mailto:bryan@olenepal.org">bryan@olenepal.org</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> this is neat Wade. It is a little more heavy weight for some activities. both google gears, flash, and the flash framework flex have some nice lightweight persistence functionality. <div><div></div><div class="Wj3C7c"> On Fri, 2009-01-02 at 14:32 -0500, Wade Brainerd wrote: > The work we did for WikiBrowse (the WikipediaES and WikipediaEN) > activities would make a good starting point. > > First of all the Browse code should be integrated into Sugar.  This > has been discussed before, and makes sense since you guys are > maintaining the Browse activity anyway. > > The Browse code would be provided as a base > sugar.activity.webactivity.WebActivity class.  Currently, "web-based" > activities (not content bundles) need to manually find the path to the > Browse installation (assuming there is one!) and import its modules > which feels rather hacky. > > The sugar.activity.webactivity module should also provide a WebServer > class.  This class is a SimpleHTTPServer derivative which supports > iterating and finding and returning an unused local port to serve > over.  The server would  handle GET/POST requests to a special > '/journal/' URL prefix, allowing DHTML scripts access to the > activity's Journal entry. > > Finally, a web-activity launcher script should be created.  This > script launches the Sugar Browse code and supports a variety of > command line options to control what parts of the Browse UI are > enabled, and to set the home page.  It should be possible to launch a > Browse instance with nothing but the Activity toolbar for example. > > These steps will allow for three (or more!) different variations on > "web-based" activities: > > 1) Static HTML and/or DHTML ala the existing .xol system.  A > collection of .html, css and .js files can be bundled as a .xo file. > The included <a href="http://activity.info" target="_blank">activity.info</a> exec line calls web-activity with > appropriate command line options. > > The advantage of this approach over .xol files is that the "web-based > activity" appears as a first class object in the Sugar UI with an > independent icon on the Home view.  Further, since the > sugar.activity.webactivity.WebServer is used, DHTML code can > read/write from the activity's Journal entry. > > 2) Static HTML and/or DHTML with custom UI.  In WikiBrowse, I > subclassed WebActivity and added a new Search toolbar, which searches > the wiki DB and retrieves a page of results.  This is the same as > variation 1, except instead of calling "web-activity", a new Python > activity class is derived from sugar.activity.webactivity.WebActivity > and modifies the UI in some way - adding toolbars, etc. > > 3) Static HTML and/or DHTML with custom server.  In WikiBrowse, a > custom webserver attaches to a local port and serves wiki pages.  It > decompresses and formats wiki pages before serving them up as XHTML. > So in this variation, a simple Python WebServer class is derived from > sugar.activity.webactivity.WebServer and the appropriate page request > handing methods are added.  The base WebServer class additionally > handles GET/POST request to access the Journal entry for the activity. > > Doing this work would allow us to rewrite WikiBrowse in a much cleaner > fashion, and would allow a whole range of first class Web-based Sugar > activities. > > Cheers, > Wade > > On Fri, Jan 2, 2009 at 1:18 PM, Tomeu Vizoso <<a href="mailto:tomeu@sugarlabs.org">tomeu@sugarlabs.org</a>> > wrote: >         Hi, > >         without needing to get into what is better for our >         deployments, I do >         see value in making easier to make Sugar activities using >         technologies >         such as HTML, CSS, etc > >         Bryan, can we get into a more detailed view on what it would >         take >         ideally to create a new activity using such activities? Which >         would be >         the steps that an experienced web designer would need to take >         in order >         to create a Sugar activity? > >         I'm sure that someone with basic knowledge of python could >         create some >         tools that make it much more easier than it is today. Also >         have some >         ideas about how those activities could interact with the >         journal and >         other Sugar features. > >         Thanks, > >         Tomeu > >         On Fri, Jan 2, 2009 at 02:50, Bryan Berry <<a href="mailto:bryan@olenepal.org">bryan@olenepal.org</a>> >         wrote: >         > This is a draft of a multi-part article I plan to post to >         OLPC News. >         > >         > It is very long but I would very much appreciate your >         opinions and >         > feedback. Your input will make it a better article once >         published. >         > >         >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >         > >         > This OLPC project seems to be going pretty well as of late >         December >         > 2008. G1G1 v2 is well underway, there are a number of >         successful pilots >         > going on, and a number of larger-scale pilots will come >         online this >         > spring and coming summer. >         > >         > Still, there is a big gaping whole in the middle of our >         little education >         > project. There just aren't enough activities. Mind you, we >         have some >         > seriously awesome activities such as Etoys, Scratch, TamTam, >         and others. >         > We have tremendous depth but very limited breadth. >         > >         > By breadth, I mean interactive activities for language, >         history, >         > geology, health, etc. In order to expand the range of >         activities, we >         > need to recruit a lot more activity developers and make it >         dead-simple >         > for them to contribute. >         > >         > But Which Developers? >         > >         > Let's think about who we want to recruit. We're talking >         about breadth >         > here so we need experts on Nepali grammar, Pashto >         vocabulary, Philippine >         > history, and Andean  geography. The good news is that there >         are >         > technically-oriented people out there that know these things >         and want to >         > help. >         > >         > We already have a hardcore team of dedicated hackers. We >         need them for >         > the work that hackers excel at: building infrastructure, >         testing the >         > limits of new systems. But now we need a different class of >         developer, >         > those that are focused on the presentation, game play and >         not system >         > internals. >         > >         > Based on these characteristics, let's call these people >         > designers. The good news is that there are lots of >         > designers-particularly in developing countries-that want to >         contribute >         > to OLPC. The bad news is that they don't know python. or GTK >         +. They may >         > not even be familiar with linux. They do know HTML, CSS, >         Javascript, and >         > Adobe Flash. Allow me to explain. >         > >         > Due to rise of the Internet and related boom in outsourcing, >         the vast, >         > vast majority of programmers in developing countries are web >         developers >         > (according to my own grossly unscientific survey). The rise >         of the >         > Internet has also led a lot of talented graphic designers in >         developing >         > and developed countries to learn web technologies. I even >         > wager that CSS/HTML/Javascript will become the de facto GUI >         technologies >         > in a few years time. <a >         > href="<a href="http://en.wikipedia.org/wiki/Pygtk" target="_blank">http://en.wikipedia.org/wiki/Pygtk</a>">PyGTK</a> won't >         take over the >         > world nor will VB.net. >         > >         > The popular term for this triumvirate of technologies is <a >         > href="<a href="http://en.wikipedia.org/wiki/AJAX" target="_blank">http://en.wikipedia.org/wiki/AJAX</a>">AJAX</a>, with the >         difference >         > that AJAX applications typically require communication with >         a remote >         > server. I propose using web technologies for completely >         offline >         > activities. Adobe's Flash is basically a variant of AJAX >         that uses >         > dialects of Javascript (<a >         > >         href="<a href="http://en.wikipedia.org/wiki/Actionscript" target="_blank">http://en.wikipedia.org/wiki/Actionscript</a>">Actionscript</a>) and >         > XML (<a href="<a href="http://en.wikipedia.org/wiki/MXML" target="_blank">http://en.wikipedia.org/wiki/MXML</a>">MXML</a>). >         > >         > Very few programmers in the developed world get paid to >         write desktop >         > linux apps. Still, open-source developers find learn and >         build pygtk, >         > mono, and KDE apps in their free-time. Developers in the >         developing >         > world are extremely enthusiastic about FOSS but not nearly >         as prolific >         > in creating open-source software due to a phenomenon I >         > call the "FOSS-Nepal Paradox." >         > >         > The <a >         > >         href="<a href="http://wiki.fossnepal.org/index.php?title=The_FOSS_Nepal_Community" target="_blank">http://wiki.fossnepal.org/index.php?title=The_FOSS_Nepal_Community</a>">FOSS Nepal</a> community has <a href="<a href="http://softwarefreedomday.org/Competition2008" target="_blank">http://softwarefreedomday.org/Competition2008</a>">won the award</a> for best celebration of Software Freedom day for two years in a running.  Despite all this enthusiasm the FOSS Nepal community is not very prolific in producing open-source code. The reason for this is that Nepal is not a wealthy country and that Open-Source is expensive to produce. >         > >         > Open-Source is Expensive >         > >         > Open-source software voraciously consumes a resource even >         more valuable >         > than hard cash, programmer time. Linus Torvalds could afford >         to spend >         > some of the most productive years of his life working >         without immediate >         > financial benefit. He could slack off in his classes without >         fear of >         > unemployment upon graduation. I doubt his parents were >         counting on him >         > to support them financially once he got a job. >         > >         > Most talented Nepali programmers I know do not have those >         luxuries. They >         > are under a lot of pressure to support their parents and >         extended >         > families, financially and otherwise. So Nepalis, >         Bangladeshis, Peruanos, >         > etc. certainly have the passion and ability to contribute to >         open-source >         > but their free time is significantly more limited. >         > >         > This doesn't mean that we should rely on developers from >         rich countries. >         > We simply need to radically lower the amount of time >         required to create >         > learning activities. I believe that many, many developers in >         the >         > developing world can contribute 3-5 hours per week. To make >         those few >         > hours productive we need to rework the default activity >         framework. >         > >         > >From what I can tell, the primary design goals of the >         default PyGTK >         > activity >         > framework are as follows: >         > >         > <ol><li>Give the programmer maximum >         flexibility</li><li>Fully exploit >         > the XO's hardware features </li><li>Mesh nicely with >         Sugar</li></ol> >         > >         > These three goals are laudable and their hacker roots are >         obvious. The >         > problem is that these goals maximize the technology's >         potential rather >         > than programmer productivity. We need reach beyond the >         vi/emacs crowd >         > (Note: I wrote this article using emacs) to thos folks that >         the masters >         > of Photoshop, Adobe Illustrator, Eclipse, and GIMP. >         > >         > I propose a new set of design goals: >         > >         > <ol> >         >        <li>Allow activity designers to quickly build >         activities utilizing >         > widely-used tools.</li> >         >        <li>Quickly reward effort with working behavior</li> >         >        <li>Mesh nicely with the Sugar UI</li> >         > </ol> >         > >         > It's OK to be Opinionated >         > >         > We need an opinionated activity framework that makes >         infrastructure >         > choices for the designer so that she can focus presentation >         and >         > gameplay. Some may recognize this as the principle of <a >         > >         href="<a href="http://en.wikipedia.org/wiki/Convention_over_Configuration" target="_blank">http://en.wikipedia.org/wiki/Convention_over_Configuration</a>">Convention Over Configuration</a>, a principle that two of the most popular web frameworks, Django and RubyOnRails, adhere to. Now a lot of geeks don't like Convention over Configuration--perl hackers especially--but they sure do allow you to create nice applications very quickly. >         > >         > Establishing an "opinionated" activity framework will in no >         way limit >         > the freedom of those hackers who want to go their own way. >         They can >         > always build their own activities from whatever tools they >         choose. The >         > whole point of a framework is to help people get started >         quickly but it >         > doesn't constrain anyone. >         > >         > This concludes part I. Here are some tantalizing morsels >         from Part II >         > of "How to Make Activity Designers Happy," >         > >         > <ul> >         >        <li>Where it's at: HTML, CSS, Javascript, and *gasp* >         Flash</li> >         >        <li>Nepal's Content Development Experience</li> >         >        <li>Aren't Kids going to create all learning >         activities so we don't >         > have to?</li> >         > </ul> >         > >         > >         > Bryan Berry is the Technology Director of <a >         > href="<a href="http://www.olenepal.org" target="_blank">http://www.olenepal.org</a>">OLE Nepal</a> and deadbeat >         co-editor of >         > OLPCNews.com. Christopher Marin contributed his knowledge >         about all >         > things web to this article >         > >         > >         > >         > In part 1, I talked about the paradoxical >         > nature of open-source communities in developing countries, >         flaws in >         > the current default activity development framework, and the >         urgent >         > need for a new framework that makes activity designers >         happy. >         > >         > By happy, I mean that the framework rewards their efforts >         almost >         > immediately (roughly 15 minutes of effort) and it lets them >         focus on >         > presentation and gameplay rather than infrastructure. Last >         time I >         > offered some vague ideas how this framework might function. >         This time >         > I will provide more details how this framework could work >         and why. >         > >         > Let's Ride The Internet Wave >         > >         > The Internet is the 300-pound gorilla in the >         software-engineering room >         > it will eat virtually everything, including your favorite >         desktop GUI >         > framework. All of the IDE's bend over backwards to support >         coding of >         > webapps, whether it is emacs, eclipse, or even vim. The >         software >         > industry is making huge investments into web technologies >         that support >         > the triumvirate of HTML/CSS/Javascript, witness Google's >         investment in >         > <a href="<a href="http://code.google.com/p/v8/" target="_blank">http://code.google.com/p/v8/</a> ">V8 javascript</a> >         compiler and >         > Apple's investment in <a >         > href="<a href="http://en.wikipedia.org/wiki/WebKit" target="_blank">http://en.wikipedia.org/wiki/WebKit</a>">Webkit</a>. I >         speculate >         > that there are many, many more developers working on GUI >         toolkits for >         > the web browser- such as JQuery, Prototype, >         Script.aculo.us-than for >         > GNOME or KDE desktop frameworks. >         > >         > The web will keep innovating at a breakneck pace. We need to >         ride that >         > wave of innovation. >         > >         > In the early days of OLPC, we all had a lot of grandiose and >         > impractical ideas. The educational systems of developing >         countries >         > would change overnight into constructionist hotbeds. Kids >         would build >         > their own activities, eliminating the need for large >         investments in >         > content development. A million PyGTK apps with built-in >         collaboration >         > and "View-Source" key would spontaneously bloom . . . Well, >         we're >         > older and wiser now. School systems anywhere are not blank >         slates that >         > we can redraw from scratch using cheap laptops and Etoys. >         Similarly, >         > we cannot expect thousands of developers to flock to a >         framework >         > (PyGTK) that is not commercially popular. >         > >         > Developing Country Developer Economics >         > >         > As I wrote in Part I, the economics of open-source in >         developing >         > countries is quite different than that in the developed >         > world. Developers there have ample enthusiasm for >         open-source but much >         > less time to contribute. >         > >         > We need to lower the barrier of entry significantly in order >         to use >         > their talents. In fact, we need to entice non-programmers >         such as >         > graphic designers. In my limited experience, graphic >         designers are >         > much better at designing learning activities than >         programmers. They >         > better appreciate aesthetics and visual story-telling. >         > >         > Web designers layout their work using CSS and (X)HTML. They >         implement >         > user interaction and animations using Javascript. They >         design their >         > work using Photoshop, GIMP, Adobe Illustrator, and sometimes >         > Eclipse. They know the features and dark areas of the >         Firefox web >         > browser. Sugar infrastructure developers, these people are >         your >         > customers. We need KARMA to enable them to quickly buidl >         activities >         > for the XO without having to learn a whole new skillset. >         From a >         > programmatic point of view, Browse needs to behave as much >         as possible >         > like Firefox. Any discrepancy will distract activity >         designers from >         > the more rewarding parts of activity development. >         > >         > Building Good KARMA >         > >         > Before we get too far, let's give this new activity >         framework a name >         > so I can save us all a lot of excess verbiage. I call it >         KARMA, >         > because the word is loosely-related to Nepal, my current >         residence, >         > and I like to think creating open-source learning activities >         gives an >         > individual good karma. Coincidentally, it is also the first >         two >         > syllables of Rabi Karmacharya's last name--an individual put >         a ton of >         > hard work and personal sacrifice into the OLPC project in >         Nepal. >         > >         > Well, I haven't actually made up my mind what the core >         technologies of >         > KARMA >         > should be. I need your help to work it out. Before I get >         into the >         > technologies, here are my priorities. 1) These tools >         maximize >         > programmer productivity and 2) are open-soure. Priority #1 >         is much >         > more important than #2. 100% purely open-source activities >         that don't >         > exist don't help kids learn. The current pygtk framework is >         purely >         > open-source but you have to become a unix programmer to use >         it. As I >         > noted in Part I, the vast, vast majority of programmers in >         the >         > developing world are web developers and a successful >         activity >         > framework will allow them to re-use their existing skills >         and tools. >         > >         > I have settled on HTML and CSS for the presentation but it >         is tougher >         > to decide on the scripting toolset and on persistent data >         > storage. Flash handles animations really well and it is easy >         to >         > integrate audio into the animations. Adobe sells some really >         nice >         > WYSIWYG tools for editing animation and adding audio. A lot >         of >         > developers know flash so there is a large pool of talent we >         can draw >         > from. Did I forget to mention that Flash is proprietary? >         > >         > The closed-source issue not withstanding, Flash is the tool >         to >         > use. Some may be upset that Flash doesn't lend itself to >         "View Source" >         > functionality but learning programming is not the sum total >         of >         > education. Kids can do all the programming they ever want to >         w/ the >         > excellent Etoys and Scratch. Sorry to sound like a broken >         record, but >         > Afghani kids won't be able to view the source of Pashto >         grammar >         > activities that don't exist, let alone interactively learn >         the rules >         > of Pashto grammar. >         > >         > Flash Ain't Open-Source >         > >         > Flash is not _as_ closed-source as other software >         applications like >         > Windows. The Adobe has published the specification for their >         SWF file >         > format and the ActionScript 3.0 compiler is open-source. >          However, the >         > Adobe's development tools such as Adobe Animator, >         Illustrator, >         > Photoshop, etc. are not open-source. Nor is Adobe's flash >         player >         > plugin. There is the open-source Gnash player but it does >         not fully >         > support Actionscript 3 or Flash version 9. Rob Savoye and >         his team at >         > Open Media Now do a great job but they seriously lack >         resources. Note: >         > Rob >         > Savoye, please correct my egregious errors. >         > >         > Javascript Isn't Ready >         > >         > I put in a good number of research hours into this article. >         I really, >         > really wanted to find a pure javascript framework that could >         compete >         > with Flash. I couldn't find one that does. There are >         libraries like >         > DOJO, JQuery, and Processing.js >         > <a href="http://ejohn.org/blog/processingjs/" target="_blank">http://ejohn.org/blog/processingjs/</a>. Unfortunately, there >         aren't any >         > IDE's that provide WYSIWYG animation editing for these >         tools. Every >         > try to edit photos from a text editor? It's painful, really >         > painful. So while real programmers use emacs (or vi, joe, >         sam, etc.), >         > designers use WYSIWYG GUI's. >         > >         > Sadly, Javascript can't use the Graphics Processing Unit >         like Flash >         > can. Ouch, it's a pain in the ass to couple animations with >         sound >         > files. Based on my research so far, pure javascript won't be >         able to >         > compete with Flash for at least the next several years. >         Please prove >         > me wrong. Please post a comment to this article linking to >         some >         > Javascript wonderfulness that pulls even with Flash. >         > >         > >         > I will continue with the assumption that KARMA will use >         flash. I will >         > happily revise this article ex post facto if someone in >         cyberspace >         > points me to a pure javascript solution that makes activity >         designers >         > happy. >         > >         > Building Momentum for Gnash >         > >         > I believe that the best way to increase interest in fully >         open-source >         > flash is to make Flash more central in the evolving >         open-source >         > education stack rather than minimizing its role. We >         definitely cannot >         > wait for Gnash to fully support every feature of the >         proprietary flash >         > before we begin using it. Open-Source starts when a single >         developer >         > "scratches an itch" as the proverb goes. It follows then >         that the best >         > way to bring Gnash up to speed we need to create a nasty, >         festering >         > sore that irritates the open-source community into action. >         > >         > Moving the Conversation Forward >         > >         > Many people will likely hate my promotion of Flash for >         learning >         > activities. It's OK if you hate me and Flash. I do hope you >         recognize >         > that we need a more developer-centric activity framework >         that uses web >         > technologies. >         > >         > I have a lot more to write about Nepal's experiences >         developing >         > learning activities and my ideas on Convention over >         Configuration in >         > sugar activities. I will save those for another day. >         > >         > >         > -- >         > Bryan W. Berry >         > Technology Director >         > OLE Nepal, <a href="http://www.olenepal.org" target="_blank">http://www.olenepal.org</a> >         > >         > _______________________________________________ >         > IAEP -- It's An Education Project (not a laptop project!) >         > <a href="mailto:IAEP@lists.sugarlabs.org">IAEP@lists.sugarlabs.org</a> >         > <a href="http://lists.sugarlabs.org/listinfo/iaep" target="_blank">http://lists.sugarlabs.org/listinfo/iaep</a> >         > >         _______________________________________________ >         Sugar-devel mailing list >         <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> >         <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> > </div></div>-- <div><div></div><div class="Wj3C7c">Bryan W. Berry Technology Director OLE Nepal, <a href="http://www.olenepal.org" target="_blank">http://www.olenepal.org</a> </div></div></blockquote></div>