Preferred end user 3rd party app installation method

[Mike C. Fletcher]

Dan Williams wrote:
...
>> We'll likely want to fix that so that Sugar doesn't *rely* on the dbus 
>> responses to track the applications.  That should be a straightforward 
>> change AFAICS.
>>     
>
> I'm not really sure we're going to do that.  There's only going to be
> more specific interfaces in the OLPC environment, not just in the shell.
>
> You already have to modify your application, if only for screen size,
> rotation support, B&W operation, memory consumption, look & feel,
> spurious wakeups, graphics depth, aggressive timers, etc. You are also
> not guaranteed to be able to write files anywhere you want, access
> devices any time you want, or talk to the network any time you want.
> Adding a few D-Bus calls is trivial.
>   
We seem to have a disconnect here between the ideal of an embedded 
platform where "everything is custom" is the rule, and a desktop 
platform, where "everything is standard" is the rule.  I obviously fall 
more into the desktop style.  I figure that if a child wants to run 
"gcalc" on the machine, they should just install and run it and Sugar 
should track the window.  BitFrost can get involved by using an 
aufs/chroot environment, but the application should be able to *try* to 
run with little or no modification.  It may not be ideal, but it should 
*run*.  The extra bits that Sugar is providing here are not *critical* 
requirements for running the application AFAICS.

Sugar is doing approximately the following (there may be other items I'm 
missing, but these are the big things):

    * Managing the creation, tracking, switching and overall control of
      Windowed applications
    * Providing a "presence service" plug-in similar to an Instant
      Messaging application and lets other applications use it's "tubes"
    * Providing a "network service" plug-in that's mesh-networking aware
    * Providing a clipboard (with a viewing applet)

which is to say, it looks a *lot* like a regular Linux Window Manager 
with a few common plug-ins built into it.

My goal over the next 4 months is to try to get us to 300 external 
developers working on Sugar applications, btw.  With 300 external 
developers we *might* have 100 applications for the platform in 6 
months.  If a child needs to run one of the thousands of *other* 
applications I'd rather have them able to do it less than optimally than 
not able to do it at all.  Making the porting process easier makes both 
the number available in 6 months likely to be larger and the likelihood 
that a missing application can be brought in higher.

> The point here is that this is not a traditional desktop machine.  If
> people think they can just change window size and throw their app onto
> the OLPC, they are wrong.
>   
Particularly when dealing with external developers whose commitment to 
porting may be minimal to start, being able to just copy over the Linux 
port to an XO (or an emulator) and run it on day one without code 
modifications is a *huge* benefit.  Sure, they may need to make 
adjustments to the application, but the benefits of not requiring 
*specific* customisations can be significant.  If you try to run a gcalc 
RPM and the only problem is that the icons are too small and it wakes up 
too often you can readily make the changes or even ask the upstream 
developer to make them for you.

If it takes days and days of setup to get the build environment set up 
it may just be too much work to get started.  We ran into the same 
problem with Sugar itself.  It was taking days of work in many cases 
just to get to the point where you could start working on what you 
wanted to work on.  For those of us who have made a solid commitment to 
the project, that's doable, but it's a serious barrier to external 
developers who just want to try porting their application and maybe 
cleaning up some issues if they appear.

I'm not saying that we just want applications *thrown* on the OLPC, I'm 
saying that we want to make the porting process as simple and 
straightforward as possible.  And we particularly want the "day one" 
situation to be as rewarding as possible.  That is, someone interested 
in developing for the OLPC should have a positive reinforcement 
("something works") on day one.  Developers tend to do spike tests in 
order to decide whether to commit to a platform.  We want that day-one 
spike test to go extremely well, and we want the extra services and 
mechanisms to be orthogonally and easily added when they want to polish 
the operation of the application on the platform, whether it be using 
the presence service to initiate networked connections or providing 
introspection mechanisms for Sugar's UI to query.

Which brings up the question of quality control, of course... but if we 
can get the developers "in the front door", they're far more likely to 
want to integrate fully (assuming it's not a "rewrite the whole 
application" situation) and adopt the platform's requirements than if 
the whole project was abandoned on day one.
> We may end up with a "classic" activity which runs traditional
> applications within a Xephyr instance as an activity.  A non-native
> application would run there, not in the normal Sugar environment.
>   
Why?  Sugar is basically functioning as a window manager as far as 
applications are concerned.  There are some services that take care of 
launching applications in the back-end, presumably so that they will 
eventually use BitFrost to do the security management, but why doesn't 
Sugar simply allow for tracking the top-level windows without 
*requiring* the dbus introspection mechanism?

After all, the Sugar activities are separate processes running in 
separate root windows anyway, why introduce a second X server just to 
host them simply because we can't get their bundle information (which we 
already had to launch them, after all) via a dbus query?  Sugar includes 
a number of platform services, and I'm quite happy to see those provided 
via dbus, but I don't think that "what I just launched" really needs to 
be a service without which no application can run on the platform.

Sorry if I'm speaking out of turn on this, but I really do think that 
this is a significant developer relations issue.

Take care,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com