What is the rationale behind std.file.setAttributes ?

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

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).