Preferred end user 3rd party app installation method

[sbspammagnet at aol.com]

>> 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 would strongly urge that this is the way forward adopted by the 
project.

> 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.
> ...
> If you want access to the presence service, easy collaboration
> features, data store and/or journal, clipboard, etc, you will need to 
> use D-Bus.

I would disagree with the above quite strongly. We have an application
which runs on more than 20 platforms (including desktops, PDAs and
embedded devices) and, precisely because it has to run on 20 platforms, 
takes cares of all the above (including screen size, rotation support, 
B&W operation, etc., etc.) itself independently of the OS on which it is
running. The harder you make applications to port the less likely it is 
that people will bother. By all means expose your special features via
a documented API, but the list of special features that you say
D-Bus support will be necessary for aren't that important for many
applications. 

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

Maybe - but no platform ever succeeded by making it harder to write for!
Seriously, for many applications as long as they can be easily installed,
launched, given a window to draw in and somewhere to save their state, 
it doesn't matter what OS/environment the app is running on and 
especially in the early stages of a new OS/environment you want it as 
easy as possible to get content on. If I can do some small tweaks to
an existing Linux port rather than a full new port then it is far more
likely to happen.
 
Anyway, just some random thoughts from someone who needs to sell the
concept of porting to a new platform to a sceptical management with
no additional budget.
 
SB
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20070404/ba6c6748/attachment.html>