Xtreams file handles
Locked
 
|
Hi folks,
This is addressed mainly to Martin Kobetic and Nicholas Cellier, who've done the Squeak port of Xtreams from VisualWorks, but I thought I'd post here in case anybody else has an opinion to share. I've been working on integrating Filesystem and Xtreams, and I'm a bit puzzled by the XTExternalResourceHandle hierarchy. In particular, I can't figure out why XTIOHandle exists. It seems to have functionality needed by XTIOSocketHandle, plus some indirection for hiding which classes are used for file or socket handles, even though there's only one choice for either of those. I'm guessing this has to do with the need for Xtreams-Terminals to be VW-compatible, and that this hierarchy is needed on VW. What I need to do is create different versions of XTIOFileHandle that can provide access to data in alternate filesystems - in-image, inside a zip file, on a remote host etc. Ideally, I'd extract the primitives into a separate object, and provide alternate sets of "primitives" for non-native filesystems. I don't want to get into changing things without understanding the status quo, though. Thoughts? Colin |
|
|
Hmmm, hard to remember...
I started from a previous work of David Lewis. I think the main reason of the indirection was to connect - either a class with just an obfuscated handle - see (IOHandle makeNonviewableInstances) - or a class exposing structural details of the handle ByteArray known by the VM - I presume for debug purposes Then I stripped out the classes exposing details, and only XTIOHandle now does not seem that usefull indeed... Nicolas 2011/8/13 Colin Putney <[hidden email]>: > Hi folks, > > This is addressed mainly to Martin Kobetic and Nicholas Cellier, > who've done the Squeak port of Xtreams from VisualWorks, but I thought > I'd post here in case anybody else has an opinion to share. > > I've been working on integrating Filesystem and Xtreams, and I'm a bit > puzzled by the XTExternalResourceHandle hierarchy. In particular, I > can't figure out why XTIOHandle exists. It seems to have functionality > needed by XTIOSocketHandle, plus some indirection for hiding which > classes are used for file or socket handles, even though there's only > one choice for either of those. I'm guessing this has to do with the > need for Xtreams-Terminals to be VW-compatible, and that this > hierarchy is needed on VW. > > What I need to do is create different versions of XTIOFileHandle that > can provide access to data in alternate filesystems - in-image, inside > a zip file, on a remote host etc. Ideally, I'd extract the primitives > into a separate object, and provide alternate sets of "primitives" for > non-native filesystems. I don't want to get into changing things > without understanding the status quo, though. > > Thoughts? > > Colin > > |
|
|
2011/8/13 Nicolas Cellier <[hidden email]>:
> Hmmm, hard to remember... > I started from a previous work of David Lewis. > I think the main reason of the indirection was to connect > - either a class with just an obfuscated handle - see (IOHandle > makeNonviewableInstances) > - or a class exposing structural details of the handle ByteArray known > by the VM - I presume for debug purposes > > Then I stripped out the classes exposing details, and only XTIOHandle > now does not seem that usefull indeed... > > Nicolas > This is confirmed by http://www.squeaksource.com/XTream/SqueaXTream-OS-nice.1 (The SqueaXTream experiments) There was indeed an alternate IOFileHandle subclass: #ViewableIOFileHandle instanceVariableNames: 'sessionID file fileSize lastOp' classVariableNames: '' poolDictionaries: '' category: 'SqueaXTream-OS' ViewableIOFileHandle class instanceVariableNames: '' "I represent an IO channel on a file system object, such as a file. I keep a ByteArray which corresponds to an SQFile data structure in the Squeak virtual machine. My instance variables are updated to reflect the current value of this data structure, allowing the data structure to be indirectly viewed with a normal Smalltalk inspector. My implementation depends on knowledge of data structures in the virtual machine. For a safe implementation, use IOFileHandle." and IOHandle was mostly a factory providing the indirection IOHandle class>>makeViewableInstances "Instances can be watched with an inspector. This works for Unix and probably for Mac, but probably does not work on Windows, which uses a different SQFile data structure format." "IOHandle makeViewableInstances" ConcreteFileClass := ViewableIOFileHandle. ConcreteSocketClass := ViewableIOSocketHandle For original work, see http://wiki.squeak.org/squeak/996 Nicolas > 2011/8/13 Colin Putney <[hidden email]>: >> Hi folks, >> >> This is addressed mainly to Martin Kobetic and Nicholas Cellier, >> who've done the Squeak port of Xtreams from VisualWorks, but I thought >> I'd post here in case anybody else has an opinion to share. >> >> I've been working on integrating Filesystem and Xtreams, and I'm a bit >> puzzled by the XTExternalResourceHandle hierarchy. In particular, I >> can't figure out why XTIOHandle exists. It seems to have functionality >> needed by XTIOSocketHandle, plus some indirection for hiding which >> classes are used for file or socket handles, even though there's only >> one choice for either of those. I'm guessing this has to do with the >> need for Xtreams-Terminals to be VW-compatible, and that this >> hierarchy is needed on VW. >> >> What I need to do is create different versions of XTIOFileHandle that >> can provide access to data in alternate filesystems - in-image, inside >> a zip file, on a remote host etc. Ideally, I'd extract the primitives >> into a separate object, and provide alternate sets of "primitives" for >> non-native filesystems. I don't want to get into changing things >> without understanding the status quo, though. >> >> Thoughts? >> >> Colin >> >> > |
|
|
In reply to this post by Nicolas Cellier
On Sat, Aug 13, 2011 at 09:31:10AM +0200, Nicolas Cellier wrote:
> Hmmm, hard to remember... > I started from a previous work of David Lewis. > I think the main reason of the indirection was to connect > - either a class with just an obfuscated handle - see (IOHandle > makeNonviewableInstances) > - or a class exposing structural details of the handle ByteArray known > by the VM - I presume for debug purposes There is a "home page" for my earlier IOHandle work here: <http://wiki.squeak.org/squeak/996> The purpose of IOHandle is: * Separate the representation of external IO channels from the represention of streams and communication protocols. * Provide a uniform representation of IO channels similar to the unix notion of treating everything as a 'file'. * Simplify future refactoring of Socket and FileStream. * Provide a place for handling asynchronous IO events. Refer to the aio handling in the unix VM. Files, Sockets, and AsyncFiles could (should) use a common IO event handling mechanism (aio event signaling a Smalltalk Semaphore). Loosely speaking, you can think of this as analogous to the separation of file handles (the integer handle number) from streams (FILE *) in a C stdio library. By keeping these conceptually separate, it becomes possible to apply a given streaming behavior to more than one kind of low level IO channel. For example, you might want to have a stream that understands HTTP or how to decode a ReferenceStream, and it would be nice if that higher level stream worked properly regardless of whether it happened to be streaming over a TCP session, a file stream, or an anonymous pipe. It's hard to achieve that without some conceptual separation of the low level IO channel from the higher level steaming behaviors, and that is the purpose of IOHandle. Dave > > Then I stripped out the classes exposing details, and only XTIOHandle > now does not seem that usefull indeed... > > Nicolas > > 2011/8/13 Colin Putney <[hidden email]>: > > Hi folks, > > > > This is addressed mainly to Martin Kobetic and Nicholas Cellier, > > who've done the Squeak port of Xtreams from VisualWorks, but I thought > > I'd post here in case anybody else has an opinion to share. > > > > I've been working on integrating Filesystem and Xtreams, and I'm a bit > > puzzled by the XTExternalResourceHandle hierarchy. In particular, I > > can't figure out why XTIOHandle exists. It seems to have functionality > > needed by XTIOSocketHandle, plus some indirection for hiding which > > classes are used for file or socket handles, even though there's only > > one choice for either of those. I'm guessing this has to do with the > > need for Xtreams-Terminals to be VW-compatible, and that this > > hierarchy is needed on VW. > > > > What I need to do is create different versions of XTIOFileHandle that > > can provide access to data in alternate filesystems - in-image, inside > > a zip file, on a remote host etc. Ideally, I'd extract the primitives > > into a separate object, and provide alternate sets of "primitives" for > > non-native filesystems. I don't want to get into changing things > > without understanding the status quo, though. > > > > Thoughts? > > > > Colin > > > > |
|
|
2011/8/13 David T. Lewis <[hidden email]>:
> On Sat, Aug 13, 2011 at 09:31:10AM +0200, Nicolas Cellier wrote: >> Hmmm, hard to remember... >> I started from a previous work of David Lewis. >> I think the main reason of the indirection was to connect >> - either a class with just an obfuscated handle - see (IOHandle >> makeNonviewableInstances) >> - or a class exposing structural details of the handle ByteArray known >> by the VM - I presume for debug purposes > > There is a "home page" for my earlier IOHandle work here: > <http://wiki.squeak.org/squeak/996> > > The purpose of IOHandle is: > > * Separate the representation of external IO channels from the represention > of streams and communication protocols. > * Provide a uniform representation of IO channels similar to the unix notion > of treating everything as a 'file'. > * Simplify future refactoring of Socket and FileStream. > * Provide a place for handling asynchronous IO events. Refer to the aio > handling in the unix VM. Files, Sockets, and AsyncFiles could (should) > use a common IO event handling mechanism (aio event signaling a Smalltalk > Semaphore). > > Loosely speaking, you can think of this as analogous to the separation > of file handles (the integer handle number) from streams (FILE *) in a > C stdio library. By keeping these conceptually separate, it becomes > possible to apply a given streaming behavior to more than one kind of > low level IO channel. For example, you might want to have a stream > that understands HTTP or how to decode a ReferenceStream, and it would > be nice if that higher level stream worked properly regardless of > whether it happened to be streaming over a TCP session, a file stream, > or an anonymous pipe. It's hard to achieve that without some conceptual > separation of the low level IO channel from the higher level steaming > behaviors, and that is the purpose of IOHandle. > > Dave > Thanks Dave. Yes the separation of Stream from the IOHandle is a good thing IMO. Current architecture is - ExternalRessourceHandle - - IOHandle - - - IOFileHandle - - - IOSocketHandle The question as I understand it is whether the IOHandle level by itself is required or not, and what does it bring. Maybe it could bring common behaviour between socket and files, but currently it does not. In current implementation the common behaviour is captured by the Stream level. Nicolas > >> >> Then I stripped out the classes exposing details, and only XTIOHandle >> now does not seem that usefull indeed... >> >> Nicolas >> >> 2011/8/13 Colin Putney <[hidden email]>: >> > Hi folks, >> > >> > This is addressed mainly to Martin Kobetic and Nicholas Cellier, >> > who've done the Squeak port of Xtreams from VisualWorks, but I thought >> > I'd post here in case anybody else has an opinion to share. >> > >> > I've been working on integrating Filesystem and Xtreams, and I'm a bit >> > puzzled by the XTExternalResourceHandle hierarchy. In particular, I >> > can't figure out why XTIOHandle exists. It seems to have functionality >> > needed by XTIOSocketHandle, plus some indirection for hiding which >> > classes are used for file or socket handles, even though there's only >> > one choice for either of those. I'm guessing this has to do with the >> > need for Xtreams-Terminals to be VW-compatible, and that this >> > hierarchy is needed on VW. >> > >> > What I need to do is create different versions of XTIOFileHandle that >> > can provide access to data in alternate filesystems - in-image, inside >> > a zip file, on a remote host etc. Ideally, I'd extract the primitives >> > into a separate object, and provide alternate sets of "primitives" for >> > non-native filesystems. I don't want to get into changing things >> > without understanding the status quo, though. >> > >> > Thoughts? >> > >> > Colin >> > >> > > > |
|
|
On Sat, Aug 13, 2011 at 05:22:10PM +0200, Nicolas Cellier wrote:
> 2011/8/13 David T. Lewis <[hidden email]>: > > On Sat, Aug 13, 2011 at 09:31:10AM +0200, Nicolas Cellier wrote: > >> Hmmm, hard to remember... > >> I started from a previous work of David Lewis. > >> I think the main reason of the indirection was to connect > >> - either a class with just an obfuscated handle - see (IOHandle > >> makeNonviewableInstances) > >> - or a class exposing structural details of the handle ByteArray known > >> by the VM - I presume for debug purposes > > > > There is a "home page" for my earlier IOHandle work here: > > ?<http://wiki.squeak.org/squeak/996> > > > > The purpose of IOHandle is: > > > > * Separate the representation of external IO channels from the represention > > ?of streams and communication protocols. > > * Provide a uniform representation of IO channels similar to the unix notion > > ?of treating everything as a 'file'. > > * Simplify future refactoring of Socket and FileStream. > > * Provide a place for handling asynchronous IO events. Refer to the aio > > ?handling in the unix VM. Files, Sockets, and AsyncFiles could (should) > > ?use a common IO event handling mechanism (aio event signaling a Smalltalk > > ?Semaphore). > > > > Loosely speaking, you can think of this as analogous to the separation > > of file handles (the integer handle number) from streams (FILE *) in a > > C stdio library. By keeping these conceptually separate, it becomes > > possible to apply a given streaming behavior to more than one kind of > > low level IO channel. For example, you might want to have a stream > > that understands HTTP or how to decode a ReferenceStream, and it would > > be nice if that higher level stream worked properly regardless of > > whether it happened to be streaming over a TCP session, a file stream, > > or an anonymous pipe. It's hard to achieve that without some conceptual > > separation of the low level IO channel from the higher level steaming > > behaviors, and that is the purpose of IOHandle. > > > > Dave > > > > Thanks Dave. > Yes the separation of Stream from the IOHandle is a good thing IMO. > Current architecture is > - ExternalRessourceHandle > - - IOHandle > - - - IOFileHandle > - - - IOSocketHandle > The question as I understand it is whether the IOHandle level by > itself is required or not, and what does it bring. > Maybe it could bring common behaviour between socket and files, but > currently it does not. > In current implementation the common behaviour is captured by the Stream level. > > Nicolas I have not looked at this in a few years, so I'll probably embarrass myself here, but the basic idea is to e.g. move the primitive access code out of StandardFileStream and into IOFileHandle, and let StandardFileStream hold on to an instance of IOHandle. Currently a StandardFileStream has a fileID instance variable that is an opaque reference to a sqFile data structure in the VM, so I replaced that variable with a reference to the IOHandle object and moved the data structure reference into IOFileHandle. Sockets use a different data structure in the VM, so the reference to that is moved to IOSocketHandle. Normally a file stream would hold on to an instance of IOFileHandle, but if you give it an IOSocketHandle, it should still more or less work as expected (reading and writing should work, #position: would fail). Protocol is defined in IOHandle, and subclasses handle the differences between sockets and files. Of course StandardFileStream and friends have some issues, but hopefully that is what Xtreams is trying to address :) Dave |
|
|
In reply to this post by Nicolas Cellier
On Sat, Aug 13, 2011 at 8:22 AM, Nicolas Cellier
<[hidden email]> wrote: > Thanks Dave. > Yes the separation of Stream from the IOHandle is a good thing IMO. > Current architecture is > - ExternalRessourceHandle > - - IOHandle > - - - IOFileHandle > - - - IOSocketHandle > The question as I understand it is whether the IOHandle level by > itself is required or not, and what does it bring. > Maybe it could bring common behaviour between socket and files, but > currently it does not. > In current implementation the common behaviour is captured by the Stream level. That's exactly right. And here's one other thing I just noticed: IOSocketHandle isn't being used at all. Socket itself serves as a handle for Xtreams that read or write to the network. I guess there's no reason not to make the changes I need. Thanks, Colin |
|
|
In reply to this post by David T. Lewis
On Sat, Aug 13, 2011 at 10:42 AM, David T. Lewis <[hidden email]> wrote:
> Normally a file stream would hold on to an instance of IOFileHandle, > but if you give it an IOSocketHandle, it should still more or less > work as expected (reading and writing should work, #position: > would fail). Protocol is defined in IOHandle, and subclasses > handle the differences between sockets and files. > > Of course StandardFileStream and friends have some issues, but > hopefully that is what Xtreams is trying to address :) Yup. It looks like we're not quite at that vision yet, but getting closer. Colin |
|
|
In reply to this post by Colin Putney-3
2011/8/14 Colin Putney <[hidden email]>:
> On Sat, Aug 13, 2011 at 8:22 AM, Nicolas Cellier > <[hidden email]> wrote: > >> Thanks Dave. >> Yes the separation of Stream from the IOHandle is a good thing IMO. >> Current architecture is >> - ExternalRessourceHandle >> - - IOHandle >> - - - IOFileHandle >> - - - IOSocketHandle >> The question as I understand it is whether the IOHandle level by >> itself is required or not, and what does it bring. >> Maybe it could bring common behaviour between socket and files, but >> currently it does not. >> In current implementation the common behaviour is captured by the Stream level. > > That's exactly right. > > And here's one other thing I just noticed: IOSocketHandle isn't being > used at all. Socket itself serves as a handle for Xtreams that read or > write to the network. I guess there's no reason not to make the > changes I need. > > Thanks, > > Colin > Yes Socket and IOSocketHandle are twin classes... I note that the structure of Flow does not have the IOHandle level, but have a zoo of sockets defined as ExternalResource http://netjam.org/flow/architecture/ Nicolas > |
|
|
Hi Nicolas-- > I note that the structure of Flow does not have the IOHandle level, > but have a zoo of sockets defined as ExternalResource > http://netjam.org/flow/architecture The Flow streaming model has streams, and "resources" which provide the content for those streams (either internal collections or "external resources" like files, sockets, and serial ports). An ExternalResource in Flow has a handle instance variable, which is known to the virtual machine. Basically, I've gone for "has a" rather than "is a" where handles are concerned. In the interest of minimalism, it didn't seem necessary to model external resource handles as anything more articulated than opaque identifiers. Is something missing this way? I just updated [1-3]; thanks for reminding me. thanks again, -C [1] http://netjam.org/flow/architecture [2] http://netjam.org/flow [3] http://netjam.org/flow/schedule -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547 |
|
|
2011/8/14 Craig Latta <[hidden email]>:
> > Hi Nicolas-- > >> I note that the structure of Flow does not have the IOHandle level, >> but have a zoo of sockets defined as ExternalResource >> http://netjam.org/flow/architecture > > The Flow streaming model has streams, and "resources" which provide > the content for those streams (either internal collections or "external > resources" like files, sockets, and serial ports). An ExternalResource > in Flow has a handle instance variable, which is known to the virtual > machine. Basically, I've gone for "has a" rather than "is a" where > handles are concerned. > I think we are reaching a common agreement on such architecture. (Too many years of maturation to my taste...) > In the interest of minimalism, it didn't seem necessary to model > external resource handles as anything more articulated than opaque > identifiers. Is something missing this way? > It sounds fair and that matches the ExternalResourceHandle of David pretty well (which I recycled in Squeak flavour of Xtreams XTExternalResourceHandle ). David had some variants for copying internal VM implementation details of the opaque handle into some ivars for file and sockets, but I have abandonned this feature, and now have a void indirection level XTIOHandle causing all this discussion... > I just updated [1-3]; thanks for reminding me. > > > thanks again, > > -C > > [1] http://netjam.org/flow/architecture > [2] http://netjam.org/flow > [3] http://netjam.org/flow/schedule > IMO the ExternalResource could be a common denominator used by various Stream implementations. I would not be amazed to see such class hierarchy both in trunk & Pharo core before a few months. This also makes me think to the work of Noury on Ocean - a FFI interface on sockets. To me, Ocean should just provide a variant of these external resources. Nicolas > -- > Craig Latta > www.netjam.org/resume > +31 6 2757 7177 > + 1 415 287 3547 > > > > |
|
|
In reply to this post by ccrraaiigg
On Sun, Aug 14, 2011 at 01:53:35PM +0200, Craig Latta wrote:
> > Hi Nicolas-- > > > I note that the structure of Flow does not have the IOHandle level, > > but have a zoo of sockets defined as ExternalResource > > http://netjam.org/flow/architecture > > The Flow streaming model has streams, and "resources" which provide > the content for those streams (either internal collections or "external > resources" like files, sockets, and serial ports). An ExternalResource > in Flow has a handle instance variable, which is known to the virtual > machine. Basically, I've gone for "has a" rather than "is a" where > handles are concerned. Conceptually, this is the same approach I used with IOHandle. So I think we are in agreement that a stream has-a external resource (or IOHandle or whatever one chooses to call it). > > In the interest of minimalism, it didn't seem necessary to model > external resource handles as anything more articulated than opaque > identifiers. Is something missing this way? Given that you are supporting the low level things in the VM, no you are not missing anything. If you wanted to use existing primitives with no changes to the VM or plugins, then you would probably want to add something like IOHandle for that purpose. Dave > > I just updated [1-3]; thanks for reminding me. > > > thanks again, > > -C > > [1] http://netjam.org/flow/architecture > [2] http://netjam.org/flow > [3] http://netjam.org/flow/schedule > > -- > Craig Latta > www.netjam.org/resume > +31 6 2757 7177 > + 1 415 287 3547 > > |
|
|
In reply to this post by Nicolas Cellier
On Sun, Aug 14, 2011 at 03:51:25PM +0200, Nicolas Cellier wrote:
> > IMO the ExternalResource could be a common denominator used by various > Stream implementations. > I would not be amazed to see such class hierarchy both in trunk & > Pharo core before a few months. That sounds good to me. I should mention two things that I learned when doing IOHandle back in 2002: 1) There was a small but measurable performance impact related to the extra level of indirection. I believe that this was due to the large number of single-byte IO operations that were happening in file streams, and IMO this would be an acceptable tradeoff. However, we should measure the impact on a modern Squeak image to make sure we do not cause a performance problem. 2) The only difficult part about implementing IOHandle was the upgrade stream. This is a case of changing the tires while the car is moving, and it is necessary to ensure that the file streams on the changes file and any source files continue to function as the updates are performed. For IOHandle I did this with two change sets with preamble/postscript actions. Something similar would be needed for the Squeak trunk update stream, as well as for the Pharo updates (I'm not sure how they work). BTW, I'd be happy to help with this, but my time will be quite limited for the next few months so I don't know how much help I can provide. Dave |
|
|
In reply to this post by Colin Putney-3
"Colin Putney"<[hidden email]> wrote:
> Date: August 14, 2011 2:57:21 AM > From: Colin Putney <[hidden email]> > To: "The general-purpose Squeak developers list"<[hidden email]> > Subject: Re: [squeak-dev] Xtreams file handles > > On Sat, Aug 13, 2011 at 8:22 AM, Nicolas Cellier > <[hidden email]> wrote: > > > Thanks Dave. > > Yes the separation of Stream from the IOHandle is a good thing IMO. > > Current architecture is > > - ExternalRessourceHandle > > - - IOHandle > > - - - IOFileHandle > > - - - IOSocketHandle > > The question as I understand it is whether the IOHandle level by > > itself is required or not, and what does it bring. > > Maybe it could bring common behaviour between socket and files, but > > currently it does not. > > In current implementation the common behaviour is captured by the Stream level. > > That's exactly right. > > And here's one other thing I just noticed: IOSocketHandle isn't being > used at all. Socket itself serves as a handle for Xtreams that read or > write to the network. I guess there's no reason not to make the > changes I need. It sounds to me that there is at least a partial overlap of responsibilities between "Handles" and what we call "Terminals" in Xtreams. A terminal stream is meant to smooth over the differences between various kinds of "sources" or "destinations" to provide a common "streaming" facade. But there aren't any hard rules about the implementation, if there is a suitable "handle" hierarchy that can already eliminate any significant differences, there's nothing wrong with having a single terminal stream taking advantage of that. But if there isn't such a thing available, having different terminal streams for different things is fine too. In VW we ended up with an ExternalRead/WriteStream which handles sockets and pipes and separate FileRead/WriteStream for files. Martin |
|
|
In reply to this post by Colin Putney-3
"Colin Putney"<[hidden email]> wrote:
> I've been working on integrating Filesystem and Xtreams, and I'm a bit > puzzled by the XTExternalResourceHandle hierarchy. In particular, I > can't figure out why XTIOHandle exists. It seems to have functionality > needed by XTIOSocketHandle, plus some indirection for hiding which > classes are used for file or socket handles, even though there's only > one choice for either of those. I'm guessing this has to do with the > need for Xtreams-Terminals to be VW-compatible, and that this > hierarchy is needed on VW. Actually the Terminals were meant to be dialect specific. It just worked out that way that most of the VW ones were fairly compatible with Squeak. So if we can keep them close, that certainly can help with maintenance going forward, but it's by no means a hard requirement. Martin |
|
|
On Sun, Aug 14, 2011 at 11:54 AM, <[hidden email]> wrote:
> "Colin Putney"<[hidden email]> wrote: >> I've been working on integrating Filesystem and Xtreams, and I'm a bit >> puzzled by the XTExternalResourceHandle hierarchy. In particular, I >> can't figure out why XTIOHandle exists. It seems to have functionality >> needed by XTIOSocketHandle, plus some indirection for hiding which >> classes are used for file or socket handles, even though there's only >> one choice for either of those. I'm guessing this has to do with the >> need for Xtreams-Terminals to be VW-compatible, and that this >> hierarchy is needed on VW. > > Actually the Terminals were meant to be dialect specific. It just worked out that way that most of the VW ones were fairly compatible with Squeak. So if we can keep them close, that certainly can help with maintenance going forward, but it's by no means a hard requirement. Oh, of course. The "proper" way to do it would be to write a new terminal stream for each kind of filesystem. I'll try it that way and see how it goes. Colin |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |