[Sugar-devel] Activity Central's Sugar related priorities.

[Daniel Narvaez]

On 9 October 2013 22:51, NoiseEHC <noiseehc at gmail.com> wrote:

> 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:
>

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.

1 Inability to do OAuth

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.

2 Journal

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).

3 Collaboration

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).

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.
>

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.

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.

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.

Just my $0.02. Manuel might want to post his perspective too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20131010/a7585274/attachment.html>