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 _______________________________________________ Sugar mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/sugar
