[IAEP] [POLL] Non Sugar Platform activities in Activity Library

[Aleksey Lim]

Gary,

I guess here is the core misunderstanding, in my mind situation is not (or shouldn't) look like 

    "Lets make all education software sugar"

but

    "Lets provide sugar features (Journal, collab intergration etc) for
    existed education software (and of course write new, within sugar,
    software) via instruments like dbus (e.g.) how it happens in etoys."

For me, there is no intention to move every peace of education
software under sugar umbrella. But creating DE with education related
features like Journal etc. (and we have this DE even today).

So, something like "Gnome/KDE/etc for any arbitrary software" but with
education emphasis.

On Mon, Mar 01, 2010 at 07:05:07PM +0000, Gary C Martin wrote:
> Hi Aleksey,
> 
> Getting off topic for IAEP so just replying to you (but feel free to include IAEP again if you see fit).
> 
> On 1 Mar 2010, at 10:52, Aleksey Lim wrote:
> 
> > On Mon, Mar 01, 2010 at 11:31:14AM +0100, Bert Freudenberg wrote:
> >> On 01.03.2010, at 10:07, Aleksey Lim wrote:
> >>> 
> >>> 
> >>> Should sugar be closed education environment with activities created(in
> >>> python) only for sugar or sugar provides programming languages agnostic
> >>> services (Journal, Collab oriented features) that could be used by
> >>> *existed* education applications (via tools like dbus etc.).
> >> 
> >> Is there really any doubt that Sugar should be an open platform?
> > 
> > For me it was so from beginning (but iirc it wasn't implicitly titled
> > somewhere and I'm just trying to check what others think).
> > 
> > Since declaring openness and providing openness are two big differences
> > problem comes when are we trying to deploy activities with non Sugar Platform
> > dependencies (here java).
> 
> I'd say I would rather not see burning of limited cycles trying to deploy activities with significant non-Sugar Platform dependencies. But they are your cycles to burn ;-) I just worry when the rest of us start dealing with support feedback from folks trying to go down this additional path (both developer support, user support, long term maintenance and testing).

Well I'm sure Gnome developers don't bother about majority of gnome/gtk
based applications they just provide basic infrastructure which let
existed (and any new) applications work together.

> > Our main deployment agnostic activities portal
> > is ASLO and it(like idea of .xo itself) doesn't work well here. So we
> > are failed with providing openness.
> 
> No, we are not failing to provide openness, though you can say Sugar is not providing tool chain support for every possible type of developer project (a C tool-chain would seem a better thing to fight over vs. Java). I know this is not much help but FWIW I've been trying to sum up my thoughts on this and they seem to boil down to:
> 
> "Everything possible we provide as part of Sugar should be open source software; this is not the same as trying to argue that every open source software project should be part of Sugar."

As I said there is no such intention, the majority of sugar work could
lie on low level - provide dbus services to datastore/shell/journal/etc,
native sugar theming for gtk/qt/java/etc.

At the end one of major issues I had in mind from beginning is that from
one side sugar is DE thus to get all its benefits user should be inside
(be logged in to sugar X session) from other hand sugar has very small
amount of native sugar applications thus users have to relogin to "regular"
DEs to run software they need (I guess it is the issue in case of special
education software written for particular region) or have many problems
(like lack of regular applications menu and explicit access to file
system).

The idea I came to is pretty obvious (I guess I'm not only one who
thinks so) instead of creating/reimplementing "new" education software
stack, provide sugar killing features via proper API/services/etc, wrap
all these features to sugar DE and be ready to start any application
which support sugar services like Gnome vs. gnome/gtk applications.

Another part of this strategy is 0install (I picked up from m_stone
serving) and ASLO thus create distribution agnostic education software
repository. "Distribution agnostic" means here not just reinvent
GNU/Linux distribution/create new one but reuse all existed
distributions since 0install can install software we need from native
packages (via PackageKit) and provide powerful method to deploy not
(well)packaged software.

-- 
Aleksey