<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 13, 2012 at 6:34 AM, H. Hirzel <span dir="ltr"><<a href="mailto:hannes.hirzel@gmail.com" target="_blank">hannes.hirzel@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":dw">Yes, and the inclusion of Colin's FileSystem into Squeak is planned<br>
for 4.5 as I<br>
understand the minutes of the board meetings.<br>
<div class="im"></div></div></blockquote></div><br></div><div class="gmail_extra">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. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">So really, the optional bits are FS-Memory, FS-Zip, FS-Git (by Max Leske and Camillo Buni), and FS-Xtreams. </div><div class="gmail_extra"><br></div><div class="gmail_extra">
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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Colin</div>