<div dir="ltr"><div><div><div><div>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 :)<br><br></div>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<br> <br>* We are all too new to this game.<br>* The time is short and we are not seeing activities being developed yet.<br></div>* The web platform is a moving target.<br></div>* I have the feeling stable API on html+css+js might be harder than on traditional interfaces.<br> <br></div><div>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.<br></div><div><br></div></div><div class="gmail_extra"> <br><br><div class="gmail_quote">On 29 May 2013 13:30, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr"><div><div>Hi Simon,<br><br></div>nice summary. I just got an idea...<br><br>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.<br> <br></div><div>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.<br> <br></div><div>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.<br></div></div><div class="gmail_extra"> <div><div class="h5"> <br><br><div class="gmail_quote">On 29 May 2013 12:29, Simon Schampijer <span dir="ltr"><<a href="mailto:simon@schampijer.de" target="_blank">simon@schampijer.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi,<br> <br> 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.<br> <br> Thanks,<br> Simon<br> <br> <br> ===Include a copy of the library in each webactivity===<br> 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.<br> <br> 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.<br> <br> 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).<br> <br> <br> ===Import from a web url and pre caching===<br> This requires a permission system. This has general security concerns.<br> <br> <br> ===load the library from the filesystem===<br> The activity loads the library from the filesystem something like: /usr/share/sugar/sugar-html-<u></u>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.<br> <br> 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].<br> <br> <br> <br> [1] webOS framework: <a href="https://developer.palm.com/content/resources/develop/overview_of_webos/overview_of_webos_software_developer_kit.html#c20332" target="_blank">https://developer.palm.com/<u></u>content/resources/develop/<u></u>overview_of_webos/overview_of_<u></u>webos_software_developer_kit.<u></u>html#c20332</a><br> <br> <br> ______________________________<u></u>_________________<br> Sugar-devel mailing list<br> <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.<u></u>org</a><br> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/<u></u>listinfo/sugar-devel</a><br> </blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br>Daniel Narvaez<br> </font></span></div> </blockquote></div><br><br clear="all"><br>-- <br>Daniel Narvaez<br> </div>