Moritz,
Thanks for your interest in using the web server's mime-parsing module.
I thought I should clarify a few points about what I've done, just in case
there are questions :)
1) The mime-parse module makes use of two modules: common and IOport. Common
is a collection of aliases, and utility functions. The common module
definitely needs cleanup, but as far as mime-parse goes, most of common can be
ignored.
Use of aliases is optional. I invented the shorter forms because typing on
the keyboard is difficult for me, so shortcuts are useful. My aim was making
them short but not too cryptic. I tried to not mimic K.
2) I've been long planning to factor out all the gnutls-related stuff into a
separate module, and organize it so it can be compiled in optionally. Not very
hard to do, just haven't yet gotten to it since, up to now, this had been a
personal project. I thought the mime-parse module might be useful, and since
it didn't use gnutls, wrongly didn't give it much attention.
The reason I used gnutls at all, vs. openssl, was that I was familiar with
gnutls and knew it was adaptable to my purpose. To support https, I needed to
have i/o that would work with either standard socket calls, or equivalent
gnutls calls. This lead to the development of IOport (see below), which
transparently handles either type of transmission (that is, encrypted or not)
in a port-like way.
openssl is a BSD alternative to gnutls I need to learn to use; I still plan to
do that. The API's are different--I just have to work on it.
3) IOport module was a solution to two problems, https, and mime-parsing within
http, i.e., finding text data in binary input, and to be able to do so
transparently across https, http, files, string data. Since using low level C
i/o API was quite familiar to me, it was most straightforward to develop i/o
facilities to do what I needed, then create the Scheme interface that provides
higher level functionality.
The most important procedure in IOport wrt mime-parsing is (read-to-bnd ...)
(reads binary input until reaching a string boundary). In keeping with its
task, the procedure is a little convoluted. Nonetheless, it may not be too
difficult to convert to regular in/out ports, though I vaguely remember having
some problems with buffering or timeouts when I tried this before. (That was
a couple of years ago--things may have changed.) Another issue with regular
ports is whether they will work with https, if that is important.
4) The server also has pgsql modules that don't wrap the C pgsql library but
rather send/receive frontend/backend protocol messages via socket connection
to a pgsql server. The method works well for database access, however
potential for pgsql code to be portable across scheme implementations is still
a goal to be reached.
The server is a work in progress, but even so makes clear the merit of Chicken
Scheme. After all, with modest effort, it's possible to construct applications
which are not only unique, even surprising, but also efficient and reliable.
In the realm of programming what could be better?
Thanks
Jules
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
