[squeak-dev] FileSystem (was: About (backwards) Compatibility)

Colin Putney colin at wiresong.com
Thu Dec 13 14:52:21 UTC 2012


On Thu, Dec 13, 2012 at 6:34 AM, H. Hirzel <hannes.hirzel at gmail.com> wrote:

> Yes, and the inclusion of Colin's FileSystem into Squeak is planned
> for 4.5 as I
> understand the minutes of the board meetings.
>

Well, it was proposed, and a few board members were receptive to the idea,
but that's not a final decision. Just to be clear, the Board's job is to
manage the administrivia of community infrastructure, like servers and
mailing lists. Setting the development agenda falls the community at large.

I think the best way to introduce Filesystem in the base image would be to
include just the core packages (FS-Core, FS-Disk, FS-Tests-Core and
FS-Tests-Disk), and leave the others as optional, loadable additions. That
core would be sufficient to cover all the functionality provided by
FileDirectory, and parts of the system that deal with files can be
gradually migrated over.

I wrote a couple of paragraphs on why it wouldn't make sense to have an
implementation FileDirectory as a layer on top of Filesystem, but then I
came to the conclusion that it might not be a bad idea after all. The devil
is in the details, and we ought to look into the details. Either way, the
current implementation of FileDirectory should eventually be available as a
loadable package, so that we can still build images with legacy code that
depends on it.

Also, I wanted to point out that FS-AnsiStreams is basically obsolete. I
wrote it because FileStream and friends couldn't be adapted to work with
non-disk filesystems, and I wanted to have a single, uniform interface for
reading and writing files, regardless of the type of filesystem that
contained them. But then I discovered that Xtreams already does a way
better job of that than anything I could have written. There might be some
value in FS-AnsiStreams as an ANSI-compliant portability interface, but
AFAICT, no dialect supports this part of the ANSI standard correctly
anyway, so it wouldn't be much use.

FS-FileStream is more useful, but it's only meant as a stepping stone. It
lets existing applications use Filesystem for navigating around the
directory hierarchy (which should be a fairly easy port from FileDirectory)
while continuing to use FileStream for IO. It provides a FileStream-like
interface for IO operations on non-disk files. (Ultimately, a modern
application that does a lot of IO should use Xtreams, though. It's a
tremendous improvement over FileStream, SocketStream etc.)

So really, the optional bits are FS-Memory, FS-Zip, FS-Git (by Max Leske
and Camillo Buni), and FS-Xtreams.

Also, to address Chris' point about tiny images, it would be possible to
split FS-Core into two packages, one with just the minimal functionality
and then another with the advanced features. I don't think that's a high
priority, since we don't have a core image of the size where FS-Core would
make a difference. But If/when we do get there, I don't think Filesystem
will be an obstacle.

Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20121213/a777a699/attachment.htm


More information about the Squeak-dev mailing list