liftSTM and the MonadSTM class are exported from Network.Framework.HVAC.Classes, which isn’t usually exposed. I suppose I could expose it, making clear that this was internal stuff provided.

The problem with this is that it is not strictly transactional, as a file may be added or deleted between the time you read the directory and the time you take the next action on the directory — i.e. if you’re creating a file if it does not exist, by the time you create the file, it may actually exist.

This problem exists on essentially all webapp frameworks, but most don’t force you to think about it. This being a Haskell framework that tries to act like Haskell, it does. After all, far too much web code is written with the assumption of atomic transactional semantics but without any implementation of it. :-)

You can look at the code for hvReadFile to get an idea of how I handle flocks. But to extend this treatment means that reading a directory, writing a file, and reading a file would all *also* (or, actually, only) need to lock on the directory level rather than the file level, which is somewhat inefficient. The point being that optimistic transactional semantics on a filesystem are a somewhat hard problem, although not massively so, and require some thinking about.

The safest and most efficient way would probably be to read your directory contents into a tvar at the start of an app, and every time a file is written to the directory (within hvac) to update the tvar. This keeps everything within the existent atomic and transactional bounds, and is actually probably faster to boot, whether or not one is worried about such things.

If the files are being written by an external process, then one would need to also launch a worker thread to periodically update the tvar with the most current information.

A bit more heavyweight, but similar to how “genuine” web galleries work is to keep your associations between file information and the actual filename in a database table.

A photo gallery sample app would be very useful to illustrate these techniques and explore the problem space.

Of course, there may be a simpler solution and I could just be overcomplicating things. Given that your hello world is a web gallery, you must have some experience thinking about this, and I’d appreciate your thoughts. :-)

One piece that hvac does lack at this point is a writeUniqueFile function that guarantees that the file written to does not already exist. It’s easy enough to implement one, I suppose, but it is something that should be handled transparently and behind-the-scenes, but I haven’t felt a strong pressure to. If you’d find that useful, I could move it up my priorities list.

I don’t know if it’s the correct place to ask you about your (nice) framework :).

From the type signature of the controller function, one would guess that you cannot do arbitrary IO operations ? (This is why you provide the hv*File function).

But, if I need to perform something like, listing the content of a directory (being a web developper discovering Haskell, my hello world is implementing a web gallery), what would I need to do that don’t use unsafePerformIO and it’s friends ?

Also, I’m not sure what platform you are developing on but here (on linux), case sensitivity is killing the import Examples.Common – the examples directory needs to be “Examples” and common.hs needs to be “Common.hs”. People on #haskell pointed out that both Windows and OSX wouldn’t have that problem…

Perhaps there is a better place to voice these concerns (bug tracker? email? #haskell?), but with the most recent patch (32), “hs for fastcgi”, linking is broken with the example hvac-board.hs – I can give you exact errors if you’d like, but for now I just am working with the previous revision… Perhaps you are just in the middle of changing things, and it will be resolved.

(I’ve temporarily given up getting it working on nginx, but I’ll get back to that).