Re: A virtual file system

Quoting Jon Wood <jon@jellybob.co.uk>: > I had a look at the code last night, and I've got the native file system > driver working without Horde now. Out of curiosity, how much did you end up changing? > I agree with Alan Knowles on the returning of arrays though Like I said, I have no problem with adding a more object-based API. > - and I'm also going to do some extending, because it seems to be missing > some features that I think should be there - such as the isFile() call in > Alan's code. Great, I look forward to seeing your patches. > Do we have a decision on where the VFS code is going to be stored yet - > I'd be happy to keep it in either PEAR, or Horde, although I'm not sure > how keeping it on the Horde cvs server would work, if your going to be > using a wrapper class to integrate the Horde code anyway, couldn't you use > VFS as a dependency like you do with the Log class. My guess is that users > are only going to find getting a pear module difficult once, and then they > just have to repeat the same process to get the vfs one, which they'll > already know how to do. This hasn't been our experience so far. And I'd really like to see PEAR take the step to components not in PEAR CVS - I'd like to provide other Horde components as PEAR packages this way eventually, and since there's interest, this one seems like a good one to start with. As I said, PEAR developers are welcome to get Horde CVS accounts or to just send us patches to work on this. -chuck -- Charles Hagenbuch, <chuck@horde.org> "After a few minutes the most aromatic and nice smelling Italian coffee will come out of the exhaustpipe." - Our stove-top espresso pot