Preferred end user 3rd party app installation method
Mike C. Fletcher
mcfletch at vrplumber.com
Thu Apr 5 01:35:03 EDT 2007
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
* 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.
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Devel