Hi Ben, On Fri, Dec 30, 2005 at 03:18:12PM -0800, Ben Wiley Sittler wrote:
yes!let me know when the c translation is uploaded and i will gladly take a look. i have investigated the mp3 thing further, and basically dillo is not well-prepared to deal with very long uris, especially not ones handled by a dpi. probably a maximum should be chosen (max. pipe buffer size less the size of the overhead bytes for the rest of the dpi request, maybe?) and anything longer should generate an error message inside dillo.
The patch took some time because it uncovered a subtle parsing bug in Dpip. It's fixed now in CVS. Both the new datauri.c and the dpip fix were commited. This is a no-frills datauri dpi version. There're things to polish. For instance: URI="data:;,test" // empty base64 and media type, ";" should be ignored
separately, much of the dillo core is unprepared to handle data: URIs; for instance, it tried to generate filenames when saving that are longer than the OS and filesystem maximum length, and also slow down the GUI to unusable speeds due to font metric calculations. furthermore it did not use the mime-types database to select a filename extension, so they ended up with very cryptic names.
Yes, this can also be improved.
as for the python dpi, maybe keep it as an example in the source tree but don't install it when doing 'make install', and use the new C implementation as the default? maybe some python programmer will take it and turn it into something more useful...
It didn't work for me so currently it's not in CVS.
also, do the dpi-handling functions in the python dpi seem correct, or did i misunderstand the protocol? i was not so sure about the quoting/escaping mechanisms...
This was a bit fuzzy... I changed it a bit and commented much more in dpip/dpip.c. Data URIs are a bit delicate with regard to security. This also needs some work. Although datauri is enabled now, it may be disabled for the next release unless security is stronger. -- Cheers Jorge.-