[Sugar-devel] How to deploy the webactivity libraries

[Daniel Narvaez]

Since I'm the one proposing the implementation, and I'm actually not too
keen about the idea itself, let me take a step back before I get blamed for
it forever :)

My feeling is that we should *not* implement this for 0.100 but rather
consider (very carefully) if it's something we need in one of the next
iterations. Cutting on philosophical considerations, I think we are not
going to be able to provide anything like a stable API for 0.100, for
several reasons including

* We are all too new to this game.
* The time is short and we are not seeing activities being developed yet.
* The web platform is a moving target.
* I have the feeling stable API on html+css+js might be harder than on
traditional interfaces.

Without a stable API, system libraries are just going to cause more issues
then benefits, with activities randomly breaking because the library is too
new or too old.



On 29 May 2013 13:30, Daniel Narvaez <dwnarvaez at gmail.com> wrote:

> Hi Simon,
>
> nice summary. I just got an idea...
>
> Our installed activities are "served" over a custom activity:// protocol,
> HTMLActivity is doing the mapping between the path in the url and the path
> on disk. If we include the volo package.json in the activity bundle we can
> map library paths to somewhere in the system for unversioned dependencies.
>
> This should give the best of both worlds because the bundles would still
> be self contained, but at the same time we would able to use the latest
> available version of the library installed in the system.
>
> For hosted activities I think the right solution is loading from a web
> url, but we don't even have to worry about that case until we actually have
> a permission system in place.
>
>
> On 29 May 2013 12:29, Simon Schampijer <simon at schampijer.de> wrote:
>
>> Hi,
>>
>> we talked yesterday on irc about how to handle the deployment of the
>> webactivity libraries like sugar-html-graphics. We came up with three basic
>> ways of dealing with it. It follows a summary. Please comment, fill in the
>> missing items. It is an interesting item that needs discussion and research
>> before we decide on using one or the other.
>>
>> Thanks,
>>    Simon
>>
>>
>> ===Include a copy of the library in each webactivity===
>> Each activity carries a copy of the libraries it uses. For example
>> sugar-html-activity and sugar-html-graphics. This has the advantage that
>> the activities are self contained. The downside is that for a change in the
>> library each activity has to be updated.
>>
>> This is the current common model for webapps. With nodejs for example
>> every library you install uses its own dependencies so that it can use
>> specific versions and not have to deal with API breaks etc. If webapp X,
>> needs a fix that is only available in sugar-html-graphics 1.5 it can pull
>> in that dependency and run on the same system as webapp Y with
>> sugar-html-graphics 1.3.
>>
>> An interesting case is when a library fix is made how to deploy that for
>> 20 webactivities. This could be made independent of the maintainers duty.
>> If a downstream wants to deploy webapp X when aggregating the webapps could
>> pull in their latest dependencies (unless a specific version is specified).
>>
>>
>> ===Import from a web url and pre caching===
>> This requires a permission system. This has general security concerns.
>>
>>
>> ===load the library from the filesystem===
>> The activity loads the library from the filesystem something like:
>> /usr/share/sugar/sugar-html-**activity/activity.js The advantage here is
>> that you only have to modify one place when a change to the library is made
>> and all the activities get it directly. There might be security concerns
>> here as well.
>>
>> In webOS the framework is available from the system "Unlike most
>> JavaScript frameworks, you won't need to include the Mojo framework with
>> your application code since Palm includes the framework in every webOS
>> device." [1].
>>
>>
>>
>> [1] webOS framework: https://developer.palm.com/**
>> content/resources/develop/**overview_of_webos/overview_of_**
>> webos_software_developer_kit.**html#c20332<https://developer.palm.com/content/resources/develop/overview_of_webos/overview_of_webos_software_developer_kit.html#c20332>
>>
>>
>> ______________________________**_________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.**org <Sugar-devel at lists.sugarlabs.org>
>> http://lists.sugarlabs.org/**listinfo/sugar-devel<http://lists.sugarlabs.org/listinfo/sugar-devel>
>>
>
>
>
> --
> Daniel Narvaez
>



-- 
Daniel Narvaez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130529/b36b9d26/attachment.html>