<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=iso-8859-1"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style></style></head><body lang=FR link=blue vlink=purple><div class=WordSection1><o:p> </o:p>> we are more or less understanding each other :) <o:p></o:p>Yes you’re right, great to hear that finally we talked about the same thing :-)<o:p></o:p> > My feeling is that we should target step 2 directly, because 1 -> 2 will waste too much work. The datastore and collaboration implementation is going to be pretty different, depending if we use Chromium or Webkit embedding. <o:p></o:p>Not so waste than that. The step 1 need only to map a set of JavaScript functions to a set of Sugar functions. Once the list of Sugar functions is write, it’s not very complex to do. Except for the UI part, the Sugar JavaScript framework the process is pretty dumb: call the right Sugar function. Step 2 will need more intelligence. <o:p></o:p>> Consider also that a better way to communicate then "console-message" is not going to come for free.<o:p></o:p>Good point. I must admit that I don’t know how to do that. BTW I wonder how PhoneGap/Cordoba is working. Because it has really the same thing to do: map a JavaScript API to system features (GPS, Phone, Camera, …). Plus PhoneGap/Cordoba is browser agnostic: it works on Android, Safari, BlackBerry, Windows Phone, webOS, … If we could retrieve and understand what sort of communication PhoneGap/Cordoba use, it could inspire us.<o:p></o:p> > The only real advantage I see with doing step 1 first is that it would give us more time to migrate Browse to the same backend. <o:p></o:p>Not the only advantage. Another advantages I see:<o:p></o:p><![if !supportLists]>- <![endif]>Easier to do for a student,<o:p></o:p><![if !supportLists]>- <![endif]>No need to change Sugar, so the framework will be compatible with Sugar 0.96/Sugar 0.98,<o:p></o:p> > I don't want to be stuck in our own html based framework. I explained in my first email why I think we should jump on one of the existing webapp frameworks train.<o:p></o:p>Yes you’re probably right. BTW others threads in this list (talking about Sugar unique features: Journal, Collaboration, …) make me thing that Sugar need a specific framework.<o:p></o:p> > Anyway I'm satisfied that we know what are the alternatives now. And we have a pretty decent idea of what they involve. I think when Simon is back we should meet and decide which direction to take. It also somewhat depends on who is interested to help out with this and what they would like to work on.<o:p></o:p>+1<o:p></o:p>I’m very happy of our exchange on this.<o:p></o:p> > In the meantime people can start hacking on the UI stuff :)<o:p></o:p>+1<o:p></o:p>The first work is probably to list Sugar specific controls and functions. I guess that a good start is sugar.graphics in <a href="http://doc.sugarlabs.org/epydocs/">http://doc.sugarlabs.org/epydocs/</a>.<o:p></o:p> Lionel.<o:p></o:p></div></body></html>