On Sunday, 29 December 2013 at 16:06:32 UTC, Andrei Alexandrescu
wrote:
I think we (and others) have done a fine job so far at
abstracting away e.g. very different ways of figuring whether
an entry is a directory on Windows vs. Posix. Now we're to
throw all that away and go back to silex stones and bear claws?
I am not telling anyone what to do. I am saying what I would
prefer. I would prefer a standard low-level layer and a flexible
high-level layer.
Yah, it would be great if that were awfully more detailed :o).
I am not coming with a finished design, but I think it is doable.
That's exactly what they said when they designed iostreams.
Buffered i/o is another issue because you either have a high
interface-call/system call ratio, or make too many system-calls.
Again I think we'd need a ton of detail here to even assess
whether this has merit. So far it's an interesting brain dump.
Ok, let me give you some motivation:
Old software bases tend to evolve and make assumptions that do
not hold over time. I recently ported phpbb to App Engine, which
provides a read-only filesystem. Phpbb used the following:
1. templates: on filesystem, or if modified in mysql
2. avatar images: on filesystem
3. processed templates: cached on filesystem
In order to port I had to create my own filesystem abstraction
and map processed templates onto memcache and avatar images onto
Cloud Storage. Basically sifting through the code and hoping I
didn't overlook anything.
This file-system port would have been trivial if phpbb had
instantiated separate "virtual filesystems" for templates,
avatars and processed templates.
I could then have specified that the avatar-filesystem should
default to MIME-type 'image/jpeg' which would let me serve the
images directly from Cloud Storage (through Google's efficient
infrastructure) with little extra work (low chance of creating
bugs).
In most cases you don't need to know what filesystem different
entities reside on. When moving into the cloud you most likely
will gain access to a diverse set of storage mechanisms that are
optimized for different usage patterns (like on-the-fly rescaling
of images, direct http interfaces, memcaches, redundante
high-availability storage etc).
