Well, Arc is still starting. In more-established languages, such approaches are unnecessary: there are libraries which will handle caching of data etc. properly, releasing unused memory for garbage collection once they are no longer accessed for some time, and rebuilding objects from permanent store if they have been disposed. In Arc it's still not yet implemented, so that approach works fine.
That said you might be interested in the so-called "Anarki" repository, which contains some of the elements I and others have built so that the server works a little better. For example: being able to serve files in subdirectories of your Arc installation, instead of the Arc installation; table-like data structures for caching data, or for persistent disk-based data; a slightly more extensible language, with some of the more common methods of extension already prepackaged in macros; etc.
Can you give an example of such libraries, off the top of your head?
I am basically interested in small multi-user applications that don't sit on top of relational databases. There really isn't too much information out there on the matter. Everyone seem to want to use a database, even for the simplest things. I suppose that given the pedigree of arc, this flat file storage business seems sensible enough.
Anyway, thanks for the pointer to anarki. I'll take a look at it.
For that matter, most languages prefer db's because of the fact that file storage operations don't have, umm, structure.
In fact the canonical Arc web app, news.arc, has a list structure to store in the "flat" file. Thus for simple apps where entities only have a few not very complex fields, textual representations of lists seem to be enough.
In other languages however their "array" syntax (which is approximately what lists are in Arc) is usually not readable by a built-in function a la lisp 'read. Also, their array syntax is usually not the center of attention, unlike in Lisp where the code syntax is itself the "array" syntax.
