<div dir="ltr">On 9 April 2013 17:56, Manuel Quiñones <span dir="ltr"><<a href="mailto:manuq@laptop.org" target="_blank">manuq@laptop.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br><div class="im">
> We could start by adding a native "App store" activity, which would<br>
> basically be just a (UI less) Chrome browser window, pointing to a website<br>
> hosting web apps. The installation would be all managed by Chrome itself.<br>
> The sugar shell would communicate with Chrome through an extension to get<br>
> the list of installed activities, to request launching and uninstalling<br>
> them. We should be able to do that with these extension APIs:<br>
><br>
> <a href="http://developer.chrome.com/extensions/management.html" target="_blank">http://developer.chrome.com/extensions/management.html</a><br>
><br>
> <a href="http://developer.chrome.com/extensions/runtime.html#method-connect" target="_blank">http://developer.chrome.com/extensions/runtime.html#method-connect</a><br>
> <a href="http://developer.chrome.com/extensions/examples/extensions/native_messaging.zip" target="_blank">http://developer.chrome.com/extensions/examples/extensions/native_messaging.zip</a><br>
> (There is a connectNative method which is not yet documented. Rather than<br>
> connecting to another extension, it connects to a native process and<br>
> communicates via standard input and output).<br>
<br>
</div>Interesting.  Will this make the webapp activity installed so it<br>
appears in the spiral already?  At first glance it looks like a big<br>
task for the first step. But on the other hand, going through all this<br>
process will make us identify any issues.  This could be an<br>
"activities store" + "hello web" activity.<br></blockquote><div><br></div><div>Yeah, exactly. It doesn't actually need to be the first step, we can start developing activities inside Chrome even without this. But at some point we need to do it to figure out the issues.  The initial implementation is hopefully not going to be a huge amount of work, I'm planning to give it a try, perhaps after the IRC meeting.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We can start using the term "webact" meaning "web activity" instead of<br>
"webapp" :)<br></blockquote><div class="im"><br>:) <br><br>
<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We could also look at what Ubuntu is doing regarding this and other<br>
webapp things .  They have integration with both Firefox and Chrome:<br>
<br>
<a href="https://launchpad.net/webapps" target="_blank">https://launchpad.net/webapps</a><br>
<a href="http://developer.ubuntu.com/resources/technologies/webapps/" target="_blank">http://developer.ubuntu.com/resources/technologies/webapps/</a><br>
<div class="im"><br></div></blockquote><div><br></div><div>Great find! We should keep an eye on that.<br><br>They have patches we might need, like one to run chrome without any UI. I thought we could use --kiosk, but if they didn't  use it maybe there is something wrong with it. Upstreaming that kind of stuff is going to be much easier if more people are interested.<br>
<br></div><div>Their approach is very similar to what we are planning. They have a C library with a dbus daemon<br><br><a href="http://bazaar.launchpad.net/~webapps/libunity-webapps/trunk/files">http://bazaar.launchpad.net/~webapps/libunity-webapps/trunk/files</a><br>
<br>They are using npapi to bridge to the native libraries. They seem to have bits of generic code which might be interesting for us<br><br><a href="http://bazaar.launchpad.net/~webapps/unity-chromium-extension/trunk/files">http://bazaar.launchpad.net/~webapps/unity-chromium-extension/trunk/files</a><br>
<br></div><div>I'm not sure how using npapi compares to the native messaging stuff. Something to think about anyway.<br></div><div><br>As I said, whenever we can figure out how to use existing APIs (even if chrome/firefox specific) it's much better in my opinion. But, realistically, in some cases we will need our own custom APIs.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> 3 We could expose datastore access through the html5 filesystem API. The<br>
> application would request persistent storage, save both data and metadata<br>
> there and we would then somehow put that in our datastore.<br>
><br>
> <a href="http://www.html5rocks.com/en/tutorials/file/filesystem/" target="_blank">http://www.html5rocks.com/en/tutorials/file/filesystem/</a><br>
<br>
</div>Hmm looking at that tutorial, seems like each webapp can access it's<br>
own sandboxed filesystem.<br></blockquote><div><br></div><div>Yeah, so the idea would be the sandboxed filesystem to correspond to a journal entry. For example, we could have applications write two files there, data and metadata.<br>
<br></div><div>I have not looked how, implementation wise, the sandbox could be turned into a journal entry at all yet, it's just a vague API level idea :)<br></div></div></div></div>