On Wed, Jan 30, 2013 at 12:47 PM, 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">
thanks, lots of useful input. I will come back with a more complete<br>
answer, I need to take the time to look into some of the stuff you<br>
suggested...<br>
<div class="im"><br>
On 30 January 2013 17:35, C. Scott Ananian <<a href="mailto:cscott@laptop.org">cscott@laptop.org</a>> wrote:<br>
> These APIs should be written in a language-independent manner (think about<br>
> gobject) so that the same basic APIs can be used on multiple platforms.<br>
<br>
</div>In the meantime, could you elaborate on what you mean with<br>
language-independent here?<br></blockquote><div><br>Well, let's take JavaScript, Java, and Python as our example languages.<br>Let's say there's an API for peer-to-peer messaging. Define it something like:<br>
<br>class PeerToPeer {<br>   Peer[] getAllVisiblePeers();<br>   void sendMessage(Peer p, String message);<br>}<br><br>Now I can easily make a javascript version of this, something like:<br><br>var PeerToPeer = Object.create(null);<br>
PeerToPeer.getAllVisiblePeers = function() { return [ ... ]; }<br>PeerToPeer.sendMessage = function(peer, message) { ... }<br><br>I can also make a python version (exercise left to the reader).<br><br>In this case I chose to define the API using Java notation, since it is most explicit about argument and return types.<br>
<br>So basically all I'm saying is try to use good object-oriented practices, accessor functions, be careful about the types of arguments etc, so that you can implement basically the identical interface in multiple languages.  Try not to use clever language features (like accessor functions in javascript) which make it hard to translate your API to a different language.  Stick to the "common subset" of object-oriented languages.<br>
<br>If you wanted to be extreme about this, you'd write all your APIs in C, and use gobject bindings (or alternative implementations carefully written to export the same interfaces as gobject would use for the C API).  But I think Java is actually a better API-description language for the platforms likely to be useful for this generation of Sugar.  (Note that I've already implemented the Java-to-JavaScript bridge for the Android side, so you'd probably just write a single implementation of the APIs in Java for both Android-native activities and Web activities on Android.  You've got a number of different options for the Sugar implementation, but if you wrote as much as possible in JavaScript (and where necessary, C) you could reuse that code in a plugin for desktop browsers running in gnome, which might be convenient for development and some deployments.  Many interesting behaviors on the Sugar side are just dbus calls, and you ought to be able to trigger those from JavaScript.)<br>
  --scott<br><br></div></div>-- <br>       ( <a href="http://cscott.net" target="_blank">http://cscott.net</a> )