On Thu, Jan 31, 2013 at 5:56 AM, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > e) polyglot support<br><div class="im"> <br> </div>Yeah I pretty much agree about a-d like, I suspect, a lot of people on<br> this list. I'd probably move b a bit higher, but not quite sure where.<br> I have never thought about e.<br></blockquote><div><br><a href="http://cscott.net/Publications/OLPC/sugarcamp-i18n.pdf">http://cscott.net/Publications/OLPC/sugarcamp-i18n.pdf</a> has some thoughts about multiple language support. It can be a compelling feature for bilingual communities; Sugar has so far only scratched the surface of its potential.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I like the idea of a full fallback implementation a lot. Do you have<br> any idea on how to implement the fall back mechanism? Anything better<br> than<br> <br> <script src="nativelib.js"></script><br> <script><br> some_lib_method || document.write('<script src="fallbacklib.js"></script>')<br> </script><br></blockquote><div class="im"><br>There are two basic cases. Where the correct behavior is to "do nothing" on a non-sugar platform, you can implement the API as a fire-and-forget postMessage. ie:<br> <br>Journal.recordActivityStart() = function() { window.postMessage('org.sugarlabs.Journal/start', ...); }<br><br>This is harmless if no one is listening to the message.<br><br>In cases where you need two different sets of behavior, you will need to do some feature probing. Since window.postMessage is asynchronous, this is tricky to do directly. I'd suggest instead setting properties on the window object. For example: (pseudo-coding this a bit)<br> <br>// note that all the APIs we add are under window.sugarlabs so that we don't inadvertently conflict with other properties of 'window'<br>if (window.sugarlabs && window.sugarlabs.collaboration) {<br> // XXX maybe we would also do some version checking here to ensure the API was new enough (but not too new)<br> exports.PeerToPeer = window.sugar.collaboration.PeerToPeer;<br>} else {<br> exports.PeerToPeer = require('WebCollaboration'); // reduced-functionality "pure browser" implementation, (eg using WebRTC)<br> }<br><br>I believe it is straightforward to add methods to the window object on Android and when using Firefox add-ons (at least).<br>The alternative is doing a 'feature request' postMessage (asynchronously), and then using a timeout to determine whether we get an affirmative answer that the particular feature is implemented. That would work fine, but it seems clumsier than exporting a property on window.<br> <br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think you and Lionel almost convinced me on this. I need to look<br> more into the offline web app stuff into html5. An explanation of how<br> you implemented the offline web cache would certainly be interesting.<br></blockquote><div><br>It's actually not very hard: Firefox implements a new profile directory for every installed web app. We just install the webapp once on-line, and then tar up the profile directory. Installing the app offline is just untarring the profile directory and tweaking the .js file which tells firefox which profiles/webapps it has. Firefox should have better mechanisms for this in the future; <a href="http://mozbugs.github.cscott.net/">http://mozbugs.github.cscott.net/</a> lists some bugzilla bugs tracking useful features in this regard (for example <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=790456">https://bugzilla.mozilla.org/show_bug.cgi?id=790456</a> ) -- but you don't have to wait for upstream, you can make it work now.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I didn't really do a proper comparison of the three frameworks but a<br> couple of things I noticed... Component *seems* to depend on github?<br> I'm not sure I like that. Volo is suggested for Firefox OS<br> applications.<br></blockquote><div><br>I don't have a strong preference yet either. There are also some namespacing issues involved -- you might want to load the sugar apis from some URL rooted at sugarlabs, for example:<br> <script src='<a href="http://sugarlabs.org/api/1.2/peer2peer.js">http://sugarlabs.org/api/1.2/peer2peer.js</a>'><br>This would be put in the offline cache along with the other files, of course, but it specifies a canonical source for the library and makes it easy to distribute API-compatible updates to connected devices.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">> 5) I have written a plugin for Firefox/Android which allows access to<br> > Android' native Java APIs from web app code. This is a good way to<br> > implement (for example) a collaboration API on top of Android's native<br> > peer-to-peer wifi APIs. I'm interested in working on this.<br> <br> </div>Link to the plugin?<br></blockquote><div><br><a href="https://github.com/cscott/skeleton-addon-fxandroid/tree/jni">https://github.com/cscott/skeleton-addon-fxandroid/tree/jni</a> for just the JNI binding skeleton,<br> <a href="https://github.com/cscott/intent-addon">https://github.com/cscott/intent-addon</a> for a full plugin built from this skeleton.<br>(see in particular <a href="https://github.com/cscott/intent-addon/blob/master/lib/main.js">https://github.com/cscott/intent-addon/blob/master/lib/main.js</a> which does low-level binding of the Android Intent API)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Feel free to get started on the collaboration API :)<br></blockquote><div><br>I am going to attempt to draft a simple multiplayer game using JavaScript bindings to the Android Wifi Direct APIs. This should inform the design of the collaboration API, as well as point the way to a JavaScript-with-native-bindings implementation of the Sugar network view. (Reading <a href="http://developer.android.com/training/connect-devices-wirelessly/nsd-wifi-direct.html">http://developer.android.com/training/connect-devices-wirelessly/nsd-wifi-direct.html</a> reminds me of how the sugar network and friends view is supposed to work!)<br> --scott<br><br>-- <br></div></div> ( <a href="http://cscott.net" target="_blank">http://cscott.net</a> )