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