Re: Virtual Filesystem

Jon Parise wrote:

On Fri, Sep 27, 2002 at 11:53:54AM +0800, Alan Knowles wrote:

If a new driver is written for the object one, then the Horde_VFS, could provide a wrapper to it in a similar way...

I really only have one general comment on the current state of this discussion: why do we need an object-based VFS system? For horde, there is no need.. - I'm working on an application here, that benefits greatly from a Object based API, and would be a pig to write (and read) as a array based one.(eg. 2-3x more code) = the VFS in phpmole is mostly array based, and is something that works (most of the time), but I would never do it that way again...

To flesh that out a bit more: I can see why some may prefer an object-based system over an array-based system for various reasons. In fact, it's an important decision to make when designing a _new_ interface. However, the VFS code already exists, and it happens to be array-based. And If somebody likes it, they will use it.. - But it would have been a considerable amount of work to use it with the design I had in place for my project.., (others may vary with opinion and descision.)

So, before people on this list start re-engineering an existing code base (almost always a waste of time, in my experience, especially when the original code is in now way broken), can someone _please_ make a list of the reasons why all of this work is necessary? Like all open source, cause people want to do it, and people think they have a need for it.., (If this where a business, I would call someone stupid for a reason like that - but it's not..)

Some other reasons? - It isnt suitable for a project I'm working on. - Since I've got to write a new VFS, it may as well reuse as much of the current code as possible - It will be done, and may be useful to others..

Is the current interface really lacking in any way that makes it unusable? Is it not possible to expand the array-based system to fill those needs? - I like clean simple API's - the current VFS has one, the one I sketched out was getting there... - something that tries to do both in one.. will not...

In short, please don't complicate this system simply because there is a belief that "objects would be better" without providing some real evidence. In my personal opinion, if the current VFS system works for nearly all cases, there's no reason to increase the size of the code base at the expense of conciseness and maintainability. Again its a personal preference, I saw phpmole grow, and had real problems with the array based data structures for the VFS (unexpected changes, difficult to decide on a single location for documentation) Therefore I've grown to prefer working with objects more. (And I know theres alot of developers out there who cant stand objects either... - so there is always going to be a wide varienty of views on this)

Let's see a real needs assessment first! I have a need, Jon has a need??, it will be coded... so the question was really where should we put it, and what should it be called.. - and how should it interact with exisiting code...

Or have I become too involved in my software engineering literature and dependable systems coursework? Python, C#, Java are all dependable systems :) - but I still love PHP :)... (well maybe not C#)

- open source is always about somebody building a better or different solution to the same problem.. - exim, sendmail, qmail.. all mail relays.. - all answer needs of different users.. If i desparely needed a VFS today - I would probably try and plug in Hordes VFS somehow.. but since I have a pet project that needs one, and the timescale is flexible.. Its a good time to attempt to build one I like... In conclusion, I dont expect horde to need, or ever want to use a Object based API, but If one was available, I would download it and use it.. - especially if it was a GnomeVFS wrapper :) Regards Alan