One of the Shoes 4 folks thinks my changes to download.rb doesn’t stink. Good for us. I’m not competing with Shoes 4. I’ll contribute when the internal venn diagram say I’m overlapping. Tis only fair – I used their download code to start with, I added to it, I should let them know.
The shoes command ‘image “http://a.website.com/funny.jpg”‘ will download the image and place it in the current slot (aka canvas). In Red Shoes, there are thousands of lines of code if you count the windows C interface, and the Linux curl interface and OSX objc interface. I don’t want that for Shoes 3.2 if I can get rid of it. My love of embedded curl borders on rage. It may not be rational but there it is.
It turns out that a lot of those lines of C have nothing to do with downloading and a whole lot to do with cacheing the downloaded images so they don’t reloaded from the file systems or from the network if used again. As best I can tell, Shoes 4 doesn’t have a cache for the downloaded images and I’ve thought hard about whether 3.2 should. I thought even harder when I saw that the download cache depends on Sqlite. I don’t distribute sqlite with Shoes 3.2 and I’m not going to unless I really, really have to.
Shoes uses Sqlite to provide a persistant cache that lasts between or across different Shoes invocations and even different programs. It’s a worthy thing. I think I can replace the Sqlite in data.rb using the built in sdbm gem. For now, data.rb says “don’t have” when Shoes queries that cache. It would be hard to debug the download if it’s already in the cache and my download never gets called.
So I added a rbload.c to shoes/http/ and modified the default line rakefile env.rb to compile it instead of shoes/http/curl.c There’s only 4 functions to implement in C by calling into the same download.rb I used for the download command. If done properly I can get all the Shoes per-process caching and the inter-processing, persistant caching.
Of course there are many ways to get this wrong. I’ll find some of them.