<HTML><BODY>
<div><SPAN contentEditable=false style="DISPLAY: inline-block"></SPAN>
<div><TT>>> We'll likely want to fix that so that Sugar doesn't *rely* on the dbus <br>
>> responses to track the applications. That should be a straightforward <br>
>> change AFAICS.</TT></div>
<div><TT></TT> </div>
<div><TT>I would strongly urge that this is the way forward adopted by the </TT></div>
<div><TT>project.</TT><TT><br>
<br>
> I'm not really sure we're going to do that. There's only going to be<br>
> more specific interfaces in the OLPC environment, not just in the shell.<br>
><br>
> You already have to modify your application, if only for screen size,<br>
> rotation support, B&W operation, memory consumption, look & feel,<br>
> spurious wakeups, graphics depth, aggressive timers, etc. You are also<br>
> not guaranteed to be able to write files anywhere you want, access<br>
> devices any time you want, or talk to the network any time you want.<br>
> Adding a few D-Bus calls is trivial.<br>
> ...</TT></div>
<div><TT>> If you want access to the presence service, easy collaboration</TT></div>
<div><TT>> features, data store and/or journal, clipboard, etc, you will need to </TT></div>
<div><TT>> use D-Bus.<br>
</div>
</TT>
<div><TT>I would disagree with the above quite strongly. We have an application</TT></div>
<div><TT>which runs on more than 20 platforms (including desktops, PDAs and</TT></div>
<div><TT>embedded devices) and, precisely because it has to </TT><TT>run on 20 platforms, </TT></div>
<div><TT>takes cares of all the above (including screen </TT><TT>size, rotation support, </TT></div>
<div><TT>B&W operation, etc., etc.) itself independently of the OS on which it is</TT></div>
<div><TT>running. The harder you make </TT><TT>applications to port the less likely it is </TT></div>
<div><TT>that people will bother. </TT><TT>By all means expose your special features via</TT></div>
<div><TT>a documented API, but the list of special features that you say</TT></div>
<div><TT>D-Bus support will be necessary for aren't that important for many</TT></div>
<div><TT>applications. </TT><TT><br>
<br>
> The point here is that this is not a traditional desktop machine. If<br>
> people think they can just change window size and throw their app onto<br>
> the OLPC, they are wrong.<br>
</TT></div>
<div><TT>Maybe - but no platform ever succeeded by making it harder to write <TT>for!</TT></TT></div>
<div><TT><TT>Seriously, for many applications as long as they can be easily installed,</TT></TT></div>
<div><TT><TT>launched, given a window to draw in and somewhere to save their state, </TT></TT></div>
<div><TT><TT>it doesn't matter what </TT></TT><TT><TT>OS/environment </TT></TT><TT><TT>the app is running on and </TT></TT></div>
<div><TT><TT>especially in the early stages </TT></TT><TT><TT>of a new OS/environment you want it as </TT></TT></div>
<div><TT><TT>easy as possible to get content </TT></TT><TT><TT>on. If I can do some small tweaks to</TT></TT></div>
<div><TT><TT>an existing Linux port rather than a full new port then it is far more</TT></TT></div>
<div><TT><TT>likely to happen.</TT></TT></div>
<div><TT><TT></TT></TT> </div>
<div><TT><TT>Anyway, just some random thoughts from someone who needs to sell the</TT></TT></div>
<div><TT><TT>concept of porting to a new platform to a sceptical management with</TT></TT></div>
<div><TT><TT>no additional budget.</TT></TT></div>
<div><TT><TT></TT></TT> </div>
<div><TT>SB</TT></div>
<div><TT> </div>
</TT><!-- end of AOLMsgPart_2_f2617470-1987-4343-8ab5-0ac5f8ca2858 --></div>
</BODY></HTML>