[Bese-devel] UCW file upload example

[Marco Baringer]

Mac Chan <lispweb at mac.e4ward.com> writes:

> Hi,
>
> I was unable to run the file upload example. Upon playing around
> with the sample code for a while I figured it out.
>
> Please see the attached diff.

thakn you.

> I'm building a site for teachers to upload multimedia contents which
> can be upward of 100mb+ files. The way ucw stores uploaded content in
> memory cannot cut it.

no, it definetly can't. but even if it could wouldn't it be better to
use something like ftp (or any protocol which allows resumes) for
files that big?

> TBNL implemented a hack (write-content-to-file t) where they put a
> hook in cl-rfc2388 to allow writing uploaded content to file directly.
> Since it's a hack (TBNL manages the file creation, uploaded contents
> itself) for TBNL only, it is not usable for other frameworks.
>
> Even if it does, I do not have a good idea of how to incorporate 
> this into ucw cleanly.

just change the mime-part object (i took a quick walk through the
backend code it shouldn't be very hard at all).

> Right now code in UCW can access the file content with slot-value
> directly, which is very simple but it doesn't scale for large files.
>
> If we put a pathname there instead, then everyone that access the slot
> will have to examine the tag first (much like the bug fix I submit
> below), which complicates things.

only a little bit, and it makes something possible which is currently
impossible. looks like a worthy tradeoff to me.

what about putting a stream (tied to a file on disk) in the slot?

> Another drawback is when session expires, those files need to be
> cleaned up. Right now GC handles that and if we put the pathname in
> there, ucw has to do the cleanup.

this is not a big deal, stick all the generated pathnames in the
session object and define an :after method on ucw:expire-session (that
function exists for the very purpose of allowing this type of clean up
to happen). you have no guarntee over exactly when expire-session will
be called but you can sure that it will be called (assuming the
machine doesn't crash).

> I'm soliciting opinions how to architech this as I'm not all too
> familiar with the underneath framework.
>
> (Araneida right now doesn't support multipart MIME form post.
> aserve however do support this.)

would it be too hard to add mime support to araneida?

> BTW There are certain things that can be done in a more straightforward way
> in aserve / TBNL / araneida.

like what? why aren't these straight forward in ucw?

> I think that UCW cannot share objects with Araneida or other backend directly.
> Can we hack both and so that they share a unique session id and some hooks
> to access objects created in both sides?

UCW currently calls the generic function FIND-SESSION on the current
application object, it gets the passed the application and the
context, since the context contains backend specific request objects
there's no reason why you could not create your own application class
which uses an araneida specific session object (or mod_lisp's
HTTPS_SESSION_ID).

the reason ucw has a RERL protocol is to make this kind of stuff easy,
i've tried to put in as many hooks as was reasonably possible. if
you're missing something i'd be happy to see about adding it.

> In that case I might be able to handle the boring file upload in
> aserve and let ucw handle all the other cool stuff :-)
>
> Does anyone have any experience to share, regarding using both
> UCW and other backends in your app?
>
> I heard that drewc runs cliki & ucw in the same image. I wonder
> how that works.

afaik the now run in the same image but are completly independant.

-- 
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
	-Leonard Cohen