[Sugar-devel] How to deploy the webactivity libraries

[Simon Schampijer]

Hi Daniel,

thanks for the feedback, a few questions about your proposal:

On 05/29/2013 01:30 PM, Daniel Narvaez 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.

Yes: 
https://github.com/sugarlabs/sugar-toolkit-gtk3/blob/master/src/sugar3/activity/htmlactivity.py#L46

  If we include the volo package.json in the activity bundle we can
> map library paths to somewhere in the system for unversioned dependencies.

Don't we include it already in the activity bundle? 
https://github.com/sugarlabs/sugar-html-template/blob/master/package.json

I looked at the volojs docs but couldn't figure out how exactly the 
version comes into play here.
https://github.com/volojs/volo/wiki/Library-best-practices#wiki-volodependencies

Is that part of the url, like in "github:requirejs/domReady/2.0.1"?
Maybe that example can help: 
https://github.com/volojs/create-responsive-template/blob/master/package.json

Can you elaborate on who would do the mapping?

> 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.

So a copy of the library is included into the activity bundle, and if no 
version is specified for that dependency it is checked if a newer 
library is installed in the system for usage.

Thanks,
    Simon

> 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>
>>
>
>
>