Sat Jun 13 20:35:42 CEST 2009
Inline images now work.
Next: how to display the .tex stuff? It would be nice to do this as a
service, but this will lead into url length limits. So.. Maybe try to
turn the latex|dvipng command into a script and integrate it with sweb
for inline image generation.
Let's split it in two: allow to extract a post as a plain file, then
create a transformer for such extranctions (restricting all
conversions to locally defined content to prevent use/abuse).
Ok.. I didn't use the ? thingy in the url yet.. The subdirectory
structure is nice for giving context to the requests, but per post
there can be different operations tagged to this ? construct.. Let's
have a look at the scheme docs.
Ok. got queries as:
(url-query (request-uri req))))
Next: capture dependencies + store intermediates.. The question is
probably, do we store the .png in the memory image, or leave it on
In general, the problem is a disk-caching strategy: it's ok to have a
live program manage dependencies between data, but the data itself can
be stored externally.
The same could be done for the parsed form of the ramblings
file. Instead of keeping the parsed intermediates in memory, place
it in disk storage.
Also, it would be interesting to be able to split the problem in two:
external programs take data from memory, and place them back into
memory, but the actual location of the files could be made hidden.
So. it's not just a cache, it's also a database of (mime-tagged)
* write a transparent storage mechanism that uses scheme objects on
one side, and a directory+file structure on the other side.
* this database should be accessible over http (without sweb
running) meaning it needs a fully consistent on-disk
representation for forced data, and a simple way to display