chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Code for parsing multipart/form-data


From: Jules Altfas
Subject: Re: [Chicken-users] Code for parsing multipart/form-data
Date: Wed, 21 Sep 2011 23:32:02 -0700

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]