<meta http-equiv="content-type" content="text/html; charset=utf-8"><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Hello Sridhar,</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">I'm glad you are interested in this effort. I agree with you, what is missing is making the activity discovery process smoother. This is one of our objectives. I am in process of finishing a Technology Preview of our WebSDK. With this component ready I expect to work on the design of the Catalogue user experience during this month (offline and online). The WebSDK will allow me to use the same code base for both front-ends. August I expect to work on the backend - wether it is thru the updater (like Martin suggests) or using the 0install infrastructure (which Aleksey just described).</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Anyhow I expect this project to make the activity ecosystem more like the "marketplace" metaphor. </span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div>WebSDK RoadMap<br><ul><li> Initial Hello World of Sugar WebSDK - Beginning of July <br>
<b>(this week: Technology Preview 1)</b></li></ul><ul><li> Interface Design of Activity Pack Catalogue - July</li><li> Implementation of Catalogue functionality - August</li></ul></span><div>Greets</div><div>
Sebastian<br>
<br><div class="gmail_quote">2011/7/7 Aleksey Lim <span dir="ltr"><<a href="mailto:alsroot@activitycentral.org">alsroot@activitycentral.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Jul 07, 2011 at 11:26:04PM +1000, Sridhar Dhanapalan wrote:<br>
> I like the notion of making activities easier to find and install. The<br>
> feedback that we've received is that ASLO is too messy, and the<br>
> process isn't smooth enough.<br>
<br>
</div>Yeah, current ASLO is not good enough but we might keep in mind<br>
different things where it is bad :). What are your points?<br>
<div class="im"><br>
> The idea I had was to have an Activity Market, similar to the Android<br>
> Market or the Apple App Store. This would be a place where activities<br>
> could be easily managed directly on the XO. You should be able to<br>
> easily browse through, search for, install and remove activities. I<br>
> think that this model would work well,<br>
<br>
</div>You mean having non-web based UI on XO? If I got Sebastian right, his<br>
idea is exactly about that (though Implementation might be different).<br>
<br>
> usually self-contained.<br>
<br>
Thats the one of problems in current ASLO and Sugar distribution methid<br>
(.xo) at all. Not all activities are flat (have only sugar deps), and if<br>
we are talking about "create your activitiy" we will get more and more<br>
activities w/ non-sugar deps. Another problem is binary based activities<br>
(the same point as w/ "create your activitiy").<br>
<br>
Well, some people prefer<br>
having self-contained activities in that case (having all deps and all,<br>
for binary based activities, blobs bundled), in my mind that eventually<br>
we will have situation when there is no any guaranties that particular<br>
.xo will run in current environment - it is hard to ask any activity<br>
developer (maybe a kid) to take care what deps he needs to bundle (some<br>
sugar environments might have them preinstalled, another might not, etc.),<br>
for binary based activities it is even worse (ABI/arches mess).<br>
<br>
In my mind it is faulty to think that activities are self-contained,<br>
of course if we talking to people "lets create your activity" and not<br>
"lets create your activity with current sugar dependencies" (the last<br>
"lets" sounds to me pretty non sugar way). But..<br>
<div class="im"><br>
> How does your idea differ from this?<br>
<br>
</div>..there is another idea - 0install[1] based distribution method[2].<br>
It is not yet described properly on the wiki, but the basic idea is:<br>
<br>
to split the whole system of activities distribution/sharing to:<br>
1 hosting/building(for binary based activities)<br>
all files and metadata about activity will be handled on the<br>
server w/ only API (no any UI)<br>
2 activities catalog repsentation might be different - web (like aslo),<br>
local sugar UI (analog of F3 view but w/ access not only to local<br>
activities, eg, like Ubuntu App Center, and w/ having stuff like<br>
ranks/reviews), or even CLI access<br>
<br>
the 1st part is started more than a year ago and it turned to start<br>
being a regular package management system based on 0install, it is named<br>
Sweets. It works in some initial stage (sugar, since there is no tech<br>
difference between sugar iteself and sugar activities, runs more or less<br>
from sweets; there is also a sweet based launcher for sugar shell).<br>
<br>
imho, it might be useful to think about new/old/old-modified<br>
activities catalog not in *AppStore way (when it behaves like ASLO, ie,<br>
directly handles activity bundles and its metadata) but having just<br>
a catalog of activities to let people launch activities and see/change<br>
metadata like ranks/reviews, and delegate all not trivial stuff (like<br>
handling deps and binaries) to the Sweets.<br>
<br>
[1] <a href="http://0install.net/" target="_blank">http://0install.net/</a><br>
[2] <a href="http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Doers_Kit" target="_blank">http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Doers_Kit</a><br>
<div><div></div><div class="h5"><br>
> Cheers,<br>
> Sridhar<br>
><br>
><br>
> On 18 June 2011 16:58, Sebastian Silva <<a href="mailto:sebastian@somosazucar.org">sebastian@somosazucar.org</a>> wrote:<br>
> > "The most important part of a christmas gift is the packaging." - My<br>
> > father-in-law (acording to my wife)<br>
> ><br>
> > Dextrose Activity Pack<br>
> ><br>
> > As maybe you know, we started giving some maintenance to a collection of<br>
> > activities - the Dextrose Activity Pack. These activities will come with<br>
> > Dextrose but you will also be able to download them as a pack.<br>
> ><br>
> > My plan is you will be able to download an activity catalogue. Think of<br>
> > "Add & Remove Activities" like in Ubuntu, except activity bundles may come<br>
> > precached so that you can download an entire "Activity Pack" into USB or<br>
> > otherwise distribute offline or online as a single download.<br>
> ><br>
> > Currently ASLO, Sugar Labs's Activity Library does not cover this.<br>
> > Obtaining/updating several activities at once over a slow link is a pain.<br>
> ><br>
> > Deployments could use this mechanism to distribute new activities / updates.<br>
> ><br>
> > The Catalogue<br>
> ><br>
> > Looking at the catalogue, I think it should be visually attractive, have<br>
> > screenshots, authors, a description. It could even offer a way to provide<br>
> > feedback for each activity and/or interact with other users.<br>
> ><br>
> > In order to provide an interesting package system for deployers and end<br>
> > users, I think I need to focus on building this Catalogue, make it really<br>
> > nice and user friendly.<br>
> ><br>
> > The Sugar WebSDK<br>
> ><br>
> > I've decided to develop a framework for the approach I'm taking with the<br>
> > Catalogue. The pattern is known as Model-View-Controller and is widely used<br>
> > in web industry and other places [0].<br>
> ><br>
> > In short, we provide a View layer that is powered by Webkit. This layer is<br>
> > connected thru events with the Controller layer, which is implemented in<br>
> > Python. The Controller interacts with the Model, also in Python, the layer<br>
> > which handles data. In turn, the View may be updated. Javascript will also<br>
> > be available.<br>
> ><br>
> > The good part is that all the components are already there. I've been doing<br>
> > research and I found Python Webkit DOM Bindings [1]. The point of Sugar<br>
> > WebSDK is not making Web .xo bundles, but implementing the GUI part of the<br>
> > activity (except for sugar toolbars) as a Webkit window, effectively turning<br>
> > it into a GUI toolkit engine. A similar approach was taken by "Titanium<br>
> > Appcelerator Desktop SDK" [2] which powers the Status.Net Desktop client<br>
> > [3].<br>
> ><br>
> > I believe the ability to effectively make attractive interfaces in PyGTK is<br>
> > pretty scarce. Doing so is also very time consuming. OTOH there is a<br>
> > huge, mature offering of talented web designers out there. Embedded<br>
> > javascript might allow for interesting visual tricks like jquery's fade<br>
> > effects, or even full HTML5 gadgets/widgets.<br>
> ><br>
> > I expect the Activity ecosystem can make good use of a framework which<br>
> > allows to distribute the production of an Activity among a team that<br>
> > can include traditional HTML/CSS designers. I know we can.<br>
> ><br>
> > I intent to make this WebSDK a Sugar Labs project. This framework will be<br>
> > shared to the developer community with a tutorial and of course, will be<br>
> > used to build the Activity Pack Catalogue.<br>
> ><br>
> > RoadMap<br>
> ><br>
> > Initial Hello World of Sugar WebSDK - Beginning of July<br>
> > Interface Design of Activity Pack Catalogue - July<br>
> > Implementation of Catalogue functionality - August<br>
> ><br>
> > This would be enough for a first "beta" release.<br>
> ><br>
> > Focus after that should be on polish and documentation for a release of both<br>
> > the WebSDK and the Activity Pack Catalogue.<br>
> ><br>
> > Help appreciated<br>
> ><br>
> > Currently I'm done with researching and ready to implement. If I missed<br>
> > something it'd be nice to know, as well as general feedback on the WebSDK<br>
> > idea. I especially appreciate prior experience and gotchas that may save me<br>
> > time.<br>
> ><br>
> > Open questions remain with the back-end package functionality: How it all<br>
> > interacts with ASLO and the Sugar update mechanism.<br>
> ><br>
> > I'm inspired partly by some insights Lucian had with Webified. Also Alsroot,<br>
> > with the brilliant sweets project.<br>
> ><br>
> > My impression: ASLO+ project and Sweets packaging system could probably be<br>
> > the backend medium term. An implementation reusing Anish's metadata updater<br>
> > code is probably the lowest hanging fruit.<br>
> ><br>
> > Sincerely,<br>
> ><br>
> > Sebastian<br>
> > Somos Azucar<br>
> > Activity Central Activity Team<br>
> ><br>
> > [0] - <a href="http://en.wikipedia.org/wiki/Model_View_Controller" target="_blank">http://en.wikipedia.org/wiki/Model_View_Controller</a><br>
> > [1] - <a href="http://www.gnu.org/software/pythonwebkit/" target="_blank">http://www.gnu.org/software/pythonwebkit/</a><br>
> > [2] - <a href="http://developer.appcelerator.com/doc/desktop/python" target="_blank">http://developer.appcelerator.com/doc/desktop/python</a><br>
> > [3] - <a href="http://status.net/desktop" target="_blank">http://status.net/desktop</a><br>
> ><br>
> > _______________________________________________<br>
> > Dextrose mailing list<br>
> > <a href="mailto:Dextrose@lists.sugarlabs.org">Dextrose@lists.sugarlabs.org</a><br>
> > <a href="http://lists.sugarlabs.org/listinfo/dextrose" target="_blank">http://lists.sugarlabs.org/listinfo/dextrose</a><br>
> ><br>
> ><br>
</div></div>> _______________________________________________<br>
> OLPC-AU mailing list<br>
> <a href="mailto:OLPC-AU@lists.laptop.org">OLPC-AU@lists.laptop.org</a><br>
> <a href="http://lists.laptop.org/listinfo/olpc-au" target="_blank">http://lists.laptop.org/listinfo/olpc-au</a><br>
<br>
--<br>
<font color="#888888">Aleksey<br>
</font></blockquote></div><br></div>