Owen Williams wrote:
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.
That's a good argument. We should seriously think about libcurl +
pycurl. The library itself is about 243k on disk.
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.
As Ivan says we might have other ways of handling search. I have no
experience with any of them, so I don't know if they are good/bad/ugly.
But that's a pretty big library. Do you need all of it? That would be
an example of the kind of thing that we probably don't want in the base
system to support a single app.
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.
That was just at the Gtk level. Not being able to just apt-get your
favorite lib is going to bother people more than any changes to gtk we make.
--Chris
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
