[sugar] penguintv progress on sugar

[Owen Williams]

On Sat, 2006-10-28 at 20:55 -0400, Christopher Blizzard wrote:
>That's a pretty agressive goal. :D  I would love it if you would be
able 
> to take the time to document what you had to do to make that happen.

> 
> It's a little ugly but not bad at all considering you're just getting 
> started.  :D

As I see how other activities are designed I'll be tweaking the
interface.  Right now all I have is the web app and etoys.

> This is an example of where we end up with a bundles vs. rpms 
> discussion.  Are 60% of the apps on the machine going to use that 
> functionality?  Are 80%?  Is it critical functionality that's required 
> on the laptop or is it something that _has_ to be installed in system 
> directories?  Where do you draw the line between a cost that everyone 
> has to pay to support a certain subset of apps?
>
> Just as a measurement, how big is the on disk footprint of pycurl?  (We 
> don't have that in extras, which I find shocking considering how useful 
> it's been to me in the past as well.)  How about pyLucene?

On my system, pycurl has a 50K python library that links to two 200K
libcurl libraries as well as other basic system libraries like libkrb.  

I think having curl around makes a lot of sense for the olpc because it
supports threaded downloading, resume, timeouts, forwarding, and other
http minutia. In an environment where always-on connectivity is not
guaranteed, the ability to pause and resume downloads is going to be
crucial.  It may take days or multiple attempts to grab a moderately
large file, with many false starts and timeouts in between.  

If every application writer is given this library by default, it means
there will be that many fewer developers hacking around the deficiencies
of urllib to do http file transfers.  (Hello, timeoutsocket.py.)  

As for pylucene, it's 6 megs.  I had picked it because the API is very
high-level and I didn't need to write much code to get it working.  But
I can feel that it's meant for larger use-cases.  I don't expect to
include it on olpc and I'm keeping an eye out for a lighter-weight
solution.

> 
> That it is.  We were pretty explicit up front that we're going to 
> include all of Gtk.  There was some discussion of "subsetting" at the 
> embedded GNOME conference, but I think that we should include all of Gtk.

I agree.  Forcing developers to figure out what's supported and what
isn't will make for frustrated developers.

owen