<div dir="ltr">On 9 October 2013 22:51, NoiseEHC <span dir="ltr"><<a href="mailto:noiseehc@gmail.com" target="_blank">noiseehc@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Now I will not give you constructive criticism as that would allow answering that "I should not tell others what to do" and it would be getting old... Instead here is some nonconstructive criticism:<br></blockquote>
<div><br></div><div>I don't know if it's constructive or not, but I'd say it's certainly useful. You are identifying the major limitations of the current sugar-web framework. Just some notes about them.<br>
<br></div><div>1 Inability to do OAuth<br><br></div><div>This has been discussed for Firefox OS too and as far as I know there is no good solution for it yet. I won't claim to understand all the security implications, tough the basic issue seems to run content from the web inside an higher privileged application. In our case it's worst because we don't support hosted web applications at all.<br>
<br></div><div>2 Journal<br><br></div><div>This is probably the issue we have been most aware of. I've been thinking in the per activity datastore direction too and I think it's probably the best one. Though as you say that involves UI redesign and we would need to figure out compatibility with existing activities. (Please share the webkit code, I don't know if I'll have time to hack on it but I did think to write something like that at some point, it would be interesting to look at it if nothing else).<br>
<br></div><div>3 Collaboration<br></div><div><br></div><div>One of the reasons we haven't tackled it yet is that we think something like what you proposed might be a better solution than trying to wrap the current native framework (which is also known to be very unreliable).<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So as I see you either create a framework which mimics Sugar and no web developer will use it or create a framework which implements what a web developer is already using or at least tries to somehow emulate it. So the web developer does not have to modify his/her code and will consider porting his/her application for a smaller platform.<br>
</blockquote><div><br></div><div>We probably all agree that it would be awesome to have something  that integrates well with Sugar and works transparently by reusing existing web technologies. I don't think that's easy to achieve though. It has been said in previous discussions that without the close integration between activities and system, Sugar would be just yet another suite of educational applications (and likely not the best of them). I very much agree and I think it's tricky to preserve that while moving to frameworks which are supposed to work everywhere. <br>
<br></div><div>We could have started with something more web developer friendly and incrementally integrated it into the native Sugar platform, for example by redesigning the Journal in the way you described, and somehow adapting native activities to the new design. Instead we went for something targeted at the current Sugar developers with the idea of making it incrementally more web friendly.<br>
<br></div><div>I have been on the fence on what was the best approach and I still am. Something to consider is that we barely have the resources to maintain the existing native code. I doubt, for example, that we would be able to ship a redesigned Journal. Consider also that the people most involved with this work has all a 
good knowledge of the Sugar platform but are not really web developers.<br><br></div><div>Just my $0.02. Manuel might want to post his perspective too.<br></div></div></div></div>