<div dir="ltr"><div><div>Hello,<br><br></div>when Simon is back, it would be good to have an IRC meeting to kickoff the work on HTML5 activities. I generally prefer mailing list discussions, but in this case I think it would be useful to chat about it to start things off... <br>
<br>Anyway I've been researching more and I thought I'd post about what I have in mind at the moment.<br clear="all"></div><div><div><div><br></div><div>I think if we are able to jump on one of the existing web applications trains it's going to be much better than doing our own thing based on Webkit embedding. All the major browsers are implementing their web apps stuff at a level which is higher than their embedding frameworks. On the long term, I don't think it's sustainable with our scarce resources to maintain an embedding + web apps framework. Also it would be great to be fully compatible with existing apps.<br>
<br></div><div>With Agora I've been exploring the Firefox OS framework. There are a lot of things I like in it but I don't think it's viable for Sugar on the short time because, being fully web based, it would require to rewrite the shell and all activities in HTML. It's also not particularly mature, for example multiple processes works only on Android at the moment.<br>
<br></div><div>In the last couple of days I've been looking at Chromium and I've found several good things<br><br></div><div>* The web apps API seems pretty mature and well documented.<br></div><div>* Their approach with ChromeOS is to have a native application launcher and window manager (aura). It's a cross platform, custom thing, so I don't think we could adopt that layer. But still it's more similar to what we need compared to Firefox OS.<br>
</div><div>* Chrome already has an application mode, activated by command line switches, which hides the browser chrome.<br></div><div>* The extensions and applications API seems to provide everything we need.<br></div><div>
* The multiple process framework is certainly more mature then Firefox and perhaps then WebKit too.<br></div><div><br></div><div>So here is more or less what I have in mind<br><br></div><div>1. Add support for Chrome web apps to Sugar.<br>
<br>We could start by adding a native "App store" activity, which would basically be just a (UI less) Chrome browser window, pointing to a website hosting web apps. The installation would be all managed by Chrome itself. The sugar shell would communicate with Chrome through an extension to get the list of installed activities, to request launching and uninstalling them. We should be able to do that with these extension APIs:<br>
<br><a href="http://developer.chrome.com/extensions/management.html">http://developer.chrome.com/extensions/management.html</a><br><br><a href="http://developer.chrome.com/extensions/runtime.html#method-connect">http://developer.chrome.com/extensions/runtime.html#method-connect</a><br>
<a href="http://developer.chrome.com/extensions/examples/extensions/native_messaging.zip">http://developer.chrome.com/extensions/examples/extensions/native_messaging.zip</a><br>(There is a connectNative method which is not yet documented. Rather than connecting to another extension, it connects to a native process and communicates via standard input and output).<br>
</div><div><br>In the UI web apps would just look like normal activities. We need to 
figure out the window manager bits which might be a bit tricky but I'd 
think possible.<br>We need a way to start Chrome without windows to be able to get a list of installed applications. I have not investigated it but I suppose at worst we would have to add a command line option. Or... we could keep the store always running.<br>
<br></div><div>2 Implement html/css/javascript UI controls following the HIG. <br></div><div><br></div><div>I'm pretty happy with the approach I've taken in Agora<br><br><a href="https://github.com/ayopa/xi-graphics">https://github.com/ayopa/xi-graphics</a><br>
<a href="https://github.com/ayopa/xi-artwork">https://github.com/ayopa/xi-artwork</a><br><a href="https://github.com/ayopa/xi-activity">https://github.com/ayopa/xi-activity</a><br><br></div><div>3 We could expose datastore access through the html5 filesystem API. The application would request persistent storage, save both data and metadata there and we would then somehow put that in our datastore.<br>
<br><a href="http://www.html5rocks.com/en/tutorials/file/filesystem/">http://www.html5rocks.com/en/tutorials/file/filesystem/</a><br></div><div><br></div><div>4 We could expose collaboration using WebRTC.<br><br><a href="https://hacks.mozilla.org/2013/03/webrtc-data-channels-for-great-multiplayer/">https://hacks.mozilla.org/2013/03/webrtc-data-channels-for-great-multiplayer/</a><br>
</div><div><br><br></div><div>I have not really explored 3 and 4 much. The point is that if we can use existing APIs rather than cooking up our own, it's of course better.<br>I think 1 and 2 can be worked on in parallel. Even if we find that we can't really do 1, the work on 2 would not be wasted because it will be fine on other browsers too.<br>
</div><div><br></div><div>Anyway just brainstorming here! It would be useful to have more people investigating this stuff. Or starting to write more of the UI bits :)<br></div><div><br>-- <br>Daniel Narvaez<br>
</div></div></div></div>