vfs-devel

Re: [Vfs-devel] It's been a few days.

[Tony K. <tk...@ca...>]

----- Original Message -----
From: "Abdul-Wahid Paterson" <ee...@we...>
To: <vfs...@li...>
Sent: Thursday, June 15, 2000 2:16 PM
Subject: Re: [Vfs-devel] It's been a few days.


> Hi,
>
> I know what you mean. I have been really busy the last few days and
> haven't managed to get much done. I should be able to finish the porting
> to class.DBI in the next couple of days.
>
> Did you get your CVS access working? Please try so that you can update
> directly to the CVS. Prephaps test it on the README file by inserting a
> blank line or somthing.

I'm installing cvs 1.10.8 right now on both of my linux systems and one of
my windows boxes. Up until now I've just used the web interface to cvs to
grab the source.

>
> There seems to be a lot of interest in a mySQL version so I think we
> should try to finish it off quickly. Also, someone wrote to me saying that
> they have written something similar to what we are doing using mySQL. I
> have their source code if you would like to take a look at it. I need to
> install mySQL first before I can do anything with it. I would like to
> persuade the guy to join forces with us if he wants to.

Send the source on over! EMail it, upload it somewhere.. whatever.. I'd love
to check it out.

Regards,
Tony Kirk

Re: [Vfs-devel] It's been a few days.

[Abdul-Wahid P. <ee...@we...>]

Hi,

I know what you mean. I have been really busy the last few days and
haven't managed to get much done. I should be able to finish the porting
to class.DBI in the next couple of days.

Did you get your CVS access working? Please try so that you can update
directly to the CVS. Prephaps test it on the README file by inserting a
blank line or somthing.

There seems to be a lot of interest in a mySQL version so I think we
should try to finish it off quickly. Also, someone wrote to me saying that
they have written something similar to what we are doing using mySQL. I
have their source code if you would like to take a look at it. I need to
install mySQL first before I can do anything with it. I would like to
persuade the guy to join forces with us if he wants to.

Regards,

AW


On Thu, 15 Jun 2000, Tony Kirk wrote:

> Hey all!
> 
>     Just an update on my status. I'm playing around with the DB storage of
> the directory structure and a few misc. other things when I have the time.
> I've been put on 4 deadlines for my work.. The first two are damn near
> impossible but I should be able to pull them off with as little sleep as my
> body can handle :) I'll post updates and/or info when I have them.
> 
> Regards,
> Tony Kirk
> 
> 
> 
> _______________________________________________
> Vfs-devel mailing list
> Vfs...@li...
> http://lists.sourceforge.net/mailman/listinfo/vfs-devel
> 

[Vfs-devel] It's been a few days.

[Tony K. <tk...@ca...>]

Hey all!

    Just an update on my status. I'm playing around with the DB storage of
the directory structure and a few misc. other things when I have the time.
I've been put on 4 deadlines for my work.. The first two are damn near
impossible but I should be able to pull them off with as little sleep as my
body can handle :) I'll post updates and/or info when I have them.

Regards,
Tony Kirk

Re: [Vfs-devel] class.DBI progress + new structure

[Tony K. <tk...@ca...>]

----- Original Message -----
From: "Abdul-Wahid Paterson" <ee...@we...>
To: "VFS Developement" <vfs...@li...>
Sent: Saturday, June 10, 2000 8:32 PM
Subject: [Vfs-devel] class.DBI progress + new structure


> Hi,
>
> I have ported the vfs_auth, db_wrapper and header to use class.DBI. Also,
I
> have changed some of the main features over to use class.DBI. The rest is
> still broken until I can complete the transfer.
>
> I have also rearranged the code. You will find things here:
>
> lib/
> - header.inc.php3
>
> lib/db/
> - db_wrapper.inc.php3
> - pg_wrapper.inc.php3
> - class.DBI
> - class.DBD::Pg
>
> lib/auth/
> - vfs_auth.inc.php3
>
> config/
> - config.inc.php3
>
>
> Note:
>
> 1. I have change the .inc files to be called .inc.php3 This is because it
is
> more secure as the webserver can read the .php3 because they don't return
any
> text. The .inc files are returned as text by Apache. I blocked this before
> using mod_rewrite but since we don't want to use mod_rewrite any more this
is
> a better way of doing it.
>
> 2. db_wrapper loads pg_wrapper for Postgres specific functions. It loads
> class.DBI which in turn loads class.DBD::Pg.
>
> 3. I have made a couple of minor changes to class.DBD::Pg and I may make
some
> more. One thing $sth->rows didn't work. Also, loads of white space (see
> previous mail) had to be trimmed out. I might edit it further because
> transaction support isn't there. I know mySQL doesn't do transactions but
> Postgres needs them for BLOBs.

Just a quick note on the above item. I'll comment on the other stuff later
tonight or tomorrow. The Latest versions of MySQL support Transactions now.
But it's purely optional. Just a note. The standard Atomic operations will
do perfectly though.

>
>
> Question:
>
> 1. Where should we put things that end users might want to edit like
header
> html and footer html?
> 2. I think we should think of allowing different language interfaces. How
are
> we going to do that?
> 3. Where should the button bar inc file go?
>
>
>
> See ya,
>
>
>
> AW
>
>
>
>
> _______________________________________________
> Vfs-devel mailing list
> Vfs...@li...
> http://lists.sourceforge.net/mailman/listinfo/vfs-devel
>

[Vfs-devel] class.DBI progress + new structure

[Abdul-Wahid P. <ee...@we...>]

Hi,

I have ported the vfs_auth, db_wrapper and header to use class.DBI. Also, I
have changed some of the main features over to use class.DBI. The rest is
still broken until I can complete the transfer.

I have also rearranged the code. You will find things here:

lib/   
- header.inc.php3

lib/db/
- db_wrapper.inc.php3
- pg_wrapper.inc.php3
- class.DBI
- class.DBD::Pg

lib/auth/
- vfs_auth.inc.php3

config/
- config.inc.php3


Note:

1. I have change the .inc files to be called .inc.php3 This is because it is
more secure as the webserver can read the .php3 because they don't return any
text. The .inc files are returned as text by Apache. I blocked this before
using mod_rewrite but since we don't want to use mod_rewrite any more this is
a better way of doing it.

2. db_wrapper loads pg_wrapper for Postgres specific functions. It loads
class.DBI which in turn loads class.DBD::Pg. 

3. I have made a couple of minor changes to class.DBD::Pg and I may make some
more. One thing $sth->rows didn't work. Also, loads of white space (see
previous mail) had to be trimmed out. I might edit it further because
transaction support isn't there. I know mySQL doesn't do transactions but
Postgres needs them for BLOBs.



Question:

1. Where should we put things that end users might want to edit like header
html and footer html?
2. I think we should think of allowing different language interfaces. How are
we going to do that?
3. Where should the button bar inc file go?



See ya,



AW

[Vfs-devel] Watch our for white space

[Abdul-Wahid P. <ee...@we...>]

Hi,

This is just a warning email really. When editing any of the inc files make
sure that you don't leave any white space outside of the <?php and ?> tags.
That is because the get_file.php3 has to insert HTML headers and they have to
be done before anything is sent to the browser. I have trimmed out the
whitespace from all the current inc files and the class.DBI and class.DBD::Pg
files. The problem is likely to come back to haunt us though. Especially with
users who edit the config files.

Seeya,

AW

[Vfs-devel] CVS status

[Abdul-Wahid P. <ee...@we...>]

Hi guys,

I have started reorganising and playing around with the code in the CVS.
Currently there is a lot of broken stuff whilst I try to move some of the
code over to use class.DBI. I will let you know when I have finished the
reorganisation. If you want to play around with the code for now I suggest
you try to use the 0.1.2 code.

See ya,

AW

[Vfs-devel] VFS 0.1.2

[Abdul-Wahid P. <ee...@we...>]

Hi guys,

I have release 0.1.2 to incorporate the changes that get rid of the
dependency on mod_rewrite. It should now let us get on with sorting out
the mySQL functionality and the move over to using class.DBI. I will try
to get some coding done on this over the weekend.

Regards,

AW

Re: [Vfs-devel] Directories

[Tony K. <tk...@ca...>]

> As for the techincal structure of the database. I had something like this
in
> mind:
>
... [Long bits of tech talk cut out :) ] ...
>
> If the user had an entry for a dir_id in read_dir he would be able to see
all
> files in that directory. Note, he would still need download permission to
> actually get any of the files so he might be able to see that a file
exists
> but not have permission to download it.
>
> Similarly for the write. If he had an entry he could create directories
and
> upload files into that directory.
>

This all sounds good to me. In fact it is exactly like my first of two ideas
for this. I'm using this same structure for the app I'm writing for the
company I work for. Using it to store tasks and sub-tasks for employees. It
works out very well unless you try to display the entire tree :). The SQL
behind that call (trying to let the server put the whole tree in order for
you) can be a pain to get working. I wonder if Postgres or MySQL has
functions to help out there. MSSQL7 doesn't. Besides sorting by $parent_id
then $child_id and then grouping here and there and... ARG!! bad flashback
to a late night working this out one night. OK, I'm over it now. :)

Regards,
Tony Kirk

Re: [Vfs-devel] class.DBI status and what to do next.

[Tony K. <tk...@ca...>]

Hey AW,

> I think to start off with probably you could work on a way to store the
files
> on the filesystem. I think the 'VFS + $file_id' is fine. Probably we just
need
> something in the config file to specify that we are going to store the
files
> on the filesystem and not in the database and another option to say where
the
> directory is on the filesystem to store them. We could probably have a
nice
> function that will check the directory has writable permission to the
current
> web process. I think if you can work on this idea I will try to start
porting
> the exisiting code over to class.DBI.
>
> Later, we could try to work out a way that mySQL can store the files in
the
> database.
>
> BTW, what do you think about releasing 0.1.2 to fix the mod_rewrite thing?
It
> could bring in more users as some people can't use it if they aren't using
> Apache. I have also fixed another bug where a null file is uploaded it
gave a
> SQL error.

By all means, release it. This *is* the current CVS code correct? With the
code changed in get_file.php3 to select files by $file_id not by file name
right?

Regards,
Tony Kirk

Re: [Vfs-devel] class.DBI status and what to do next.

[Abdul-Wahid P. <ee...@we...>]

> 
> We still need to sort out the file storage issue. So I know HOW to write the
> MySQL code. Did you want to go with the 'VFS + $file_id' file names and do
> file system storage or do you want me to work on a better way for MySQL to
> store the files in the DB?


I think to start off with probably you could work on a way to store the files
on the filesystem. I think the 'VFS + $file_id' is fine. Probably we just need
something in the config file to specify that we are going to store the files
on the filesystem and not in the database and another option to say where the
directory is on the filesystem to store them. We could probably have a nice
function that will check the directory has writable permission to the current
web process. I think if you can work on this idea I will try to start porting
the exisiting code over to class.DBI.

Later, we could try to work out a way that mySQL can store the files in the
database.

BTW, what do you think about releasing 0.1.2 to fix the mod_rewrite thing? It
could bring in more users as some people can't use it if they aren't using
Apache. I have also fixed another bug where a null file is uploaded it gave a
SQL error.

Regards,

AW

[Vfs-devel] Directories

[Abdul-Wahid P. <ee...@we...>]

Hi,

I think that the directory interface should be kept quite conentional so that
it is obvious to users how the interface works. This is probably mainly
achieved by using good grahpics like folders that open and close. (Wonder
where that comes from?)

One thing I did mention to Adis was that we could use the mime type of the
file to display a icon particular to that file type. I don't think we want
thousands of different icons. I mean just one for image and not one for each
of .gif, .jpg, .tif, .png etc.

I would like the user to have the option to change the order that the files
are listed according to size, user, date, name etc. This would be inline with
directory browsing that you see on websites.

Apart from that, it would be nice to be slightly innovative. The whole point
of VFS is to offer extra feature than existing solutions so we might want to
scratch our heads over this one (watch out for the dandruff though). ;)


As for the techincal structure of the database. I had something like this in
mind:

CREATE TABLE directory (
   int4 dir_id PRIMARY KEY,
   int4 parent_dir_id NOT NULL,
   text dir_name,
   text vfs_user,
   abstime creation_date );

The system would have one top level directory set up when the system is first
setup. It would have something like dir_id = 1 and parent_dir=1. That is, the
fact that dir_id == parent_dir_id shows that it is the top level.

Each user would have its own top-level directory created when the user was
created. That is dir_id=x and parent_dir_id = 1. We know which directory is
the user's toplevel by select the directory where parent_dir_id = 1 and
vfs_user='this user'.

Users can then setup sub-directories within their directory. The directories
would always link back through the parent_dir_id. Am I making sense so far?


We would then have something like two link tables:

CREATE TABLE read_dir (
   int4 dir_id,
   text vfs_user);

and similar for write.

If the user had an entry for a dir_id in read_dir he would be able to see all
files in that directory. Note, he would still need download permission to
actually get any of the files so he might be able to see that a file exists
but not have permission to download it.

Similarly for the write. If he had an entry he could create directories and
upload files into that directory.


Probably a system administrator could create further top-level directories
along side the user directories for archives that are open to everyone.

What do you think? Please comment, I am just writing this down off the top off
my head.

See ya,

AW

Re: [Vfs-devel] class.DBI status and what to do next.

[Tony K. <tk...@ca...>]

Sounds like a plan.

>
> version 0.2 (2-3 weeks) - convert existing code to class.DBI add mySQL
code +
> button bar graphics and VFS logo

We still need to sort out the file storage issue. So I know HOW to write the
MySQL code. Did you want to go with the 'VFS + $file_id' file names and do
file system storage or do you want me to work on a better way for MySQL to
store the files in the DB?

Regards,
Tony Kirk

Re: [Vfs-devel] class.DBI status and what to do next.

[Abdul-Wahid P. <ee...@we...>]

Hi,


>     I like it, and it seems to work well. It's actually a lot like the DB
> class I was thinking about creating a while back but never got the time to
> take on another project. I think I may add the additional features to it

Ok, so i think we are agreed on using class.DBI.

>     As for what's next - how soon would you want to get the directory
> structure implemented? I'd say the sooner the better. So all things that
> need to be coded around that won't need to be re-coded after the feature is
> injected into the code later on down the line. Unless you've already started
> looking at ways to do this, I can start on some test code for database
> storage of the structure of the directories and getting directories / sub
> directories linked properly.

I think that directories are a vital feature that need to be worked on soon. I
think though that we should try to convert the existing code over to using
class.DBI first. This is my planned road map...what do you think?

version 0.1.2 (1 week) - not sure about this release but would be bug fix and
to do away with mod_rewrite code in favour of the header function.

version 0.2 (2-3 weeks) - convert existing code to class.DBI add mySQL code +
button bar graphics and VFS logo

versions 0.2.x (as needed) - any bug fixes or tidying up of the class.DBI
transfer

version 0.3 (4 weeks) - basic directory support

version 0.3.1 (5 weeks) - grahpical directory browser

version 0.3.x (as needed) - any bug fixes to directory support

[Vfs-devel] class.DBI status and what to do next.

[Tony K. <tk...@ca...>]

Hey AW,

    I like it, and it seems to work well. It's actually a lot like the DB
class I was thinking about creating a while back but never got the time to
take on another project. I think I may add the additional features to it
that I wanted to add to mine and create my own side project out of it.
Adding methods like ->movenext, ->moveprev, ->movefirst and ->movelast. Then
have a row object that moves with those methods. Basically something that
acts just like microsoft's DAO, RDO and ADO database objects. But that's
another project :)

    As for what's next - how soon would you want to get the directory
structure implemented? I'd say the sooner the better. So all things that
need to be coded around that won't need to be re-coded after the feature is
injected into the code later on down the line. Unless you've already started
looking at ways to do this, I can start on some test code for database
storage of the structure of the directories and getting directories / sub
directories linked properly.


Regards,
Tony Kirk

[Vfs-devel] New get_file.php3 test status.

[Tony K. <tk...@ca...>]

Hello AW, (I'll use the AW from now on :) )

NS 4, 4.51 (Linux) works.
IE 4, 5, 5.5 (Win32/NT) works.
IE 5 (Mac) works.

I'm playing with the idea of setting up an original Win95 box to test out IE
3, as I have two spare boxes here and all the parts to complete them. And
maybe setting up other browsers like Opera to test out as well. I'll let you
know if I get to do that. But it looks like using the new header will work
out perfect.

Regards,
Tony Kirk

Re: [Vfs-devel] Code issue in get_file.php3?

[Abdul-Wahid P. <ee...@we...>]

I changed the selection of the file to be id based in version 0.1.1 and
that is the current state of the CVS. I did that for the reason you
mentioned. That is, we may want multiple files with one name (definately
when we introduce directories :) ) so by selecting by the file_id (found
in the new db schemea in 0.1.1) we can have multiple files by the same
name.

I suggest you do one of two things. First, get the latest version out of
CVS, or secondly change file_id=$file to file_name=$file for doing the
testing.

Regards,

Abdul-Wahid



On Wed, 7 Jun 2000, Tony Kirk wrote:

> Hey there Abdul-Wahid,
> 
> Here is the line of code in question.
> 
> $sql = "select file, mime, size from files where file_id='$file'";
> 
> Found on line 13 of the new get_file.php3 you sent out today to be tested.
> Does this line of code work for you on your system? The original
> get_file.php3 had a different line.
> 
> $sql = "select file, mime, size from files where file_name='$file'";
> 
> The first sql statement makes sense to me being used as there may be
> multiple files with the same name. Changing file_id=$file to file_name=$file
> in the new get_file.php3 works of course. But did you want to recode that to
> use the files ID instead?
> 
> Regards,
> Tony Kirk
> 
> 
> _______________________________________________
> Vfs-devel mailing list
> Vfs...@li...
> http://lists.sourceforge.net/mailman/listinfo/vfs-devel
> 

RE: [Vfs-devel] Look-n-feel

[Adis B. <bu...@to...>]

Hello to all,

I have made some images for the menu bar.I would like to keep all images in a 
folder /Images so if you all agree with that structure I can upload them 
there.
AW's suggestion to move bars into .inc filesnis good.

I'll make some logos so we can decide which one would be best for VFS project.

 
Adis




Original Message From vfs...@li... =====
>I propose that we move the menu bars into .inc files so that if we make
>changes to them (like adding a new item) we don't have to change it all
>through the site.
>
>I understand Adis has already done some images for the menu bar. Adis, can 
you
>upload them somewhere where we can look at them?
>
>I think that we should try to keep the interface as "filesystem" like as
>possible so that users feel comfortable uploading/downloading files. These 
are
>some of the features that I had thought of.
>
>1. Directory browsing (once directories have been implemented).
>2. Ordering of files according to name, data, user, size etc. (we need to add
>date as an attribute in the files table.
>3. Javascript pop-up window (ie browser with no border or widgets) for
>uploading of files (This feature would probably be best as a 
user_configurable
>option so that Lynx users (and other Javascript haters) don't get annoyed.
>4. Some (nice) colour on the page somewhere. The colour at the moment is 
plain
>and a bit yucky. Possibly a VFS logo.
>
>
>Regards,
>
>AW
>
>
>
>_______________________________________________
>Vfs-devel mailing list
>Vfs...@li...
>http://lists.sourceforge.net/mailman/listinfo/vfs-devel

[Vfs-devel] Code issue in get_file.php3?

[Tony K. <tk...@ca...>]

Hey there Abdul-Wahid,

Here is the line of code in question.

$sql = "select file, mime, size from files where file_id='$file'";

Found on line 13 of the new get_file.php3 you sent out today to be tested.
Does this line of code work for you on your system? The original
get_file.php3 had a different line.

$sql = "select file, mime, size from files where file_name='$file'";

The first sql statement makes sense to me being used as there may be
multiple files with the same name. Changing file_id=$file to file_name=$file
in the new get_file.php3 works of course. But did you want to recode that to
use the files ID instead?

Regards,
Tony Kirk

Re: [Vfs-devel] class.DBI

[Tony K. <tk...@ca...>]

----- Original Message -----
From: "Abdul-Wahid Paterson" <ee...@we...>
To: <vfs...@li...>
Sent: Tuesday, June 06, 2000 7:53 PM
Subject: Re: [Vfs-devel] class.DBI


> Tony Kirk <tk...@ca...> said:
>
> > All of the databases we want to support already have DBD files.
>
> There isn't an Oracle DBD and I wouldn't mind supporting Oracle (or
'Orable as
> it is sometimes known) as use it at work. I might be able to write a
> DBD::Oracle though it doesn't look to hard. When I find the time ;)
>

Oh yeah I missed that one :) Another server I want to install. Although I
still have to pick up a copy of Oracle8i first.

Regards,
Tony Kirk

Re: [Vfs-devel] Look-n-feel

[Tony K. <tk...@ca...>]

----- Original Message -----
From: "Abdul-Wahid Paterson" <ee...@we...>
To: "VFS Developement" <vfs...@li...>
Sent: Tuesday, June 06, 2000 7:42 PM
Subject: [Vfs-devel] Look-n-feel


> I propose that we move the menu bars into .inc files so that if we make
> changes to them (like adding a new item) we don't have to change it all
> through the site.
>
> I understand Adis has already done some images for the menu bar. Adis, can
you
> upload them somewhere where we can look at them?
>
> I think that we should try to keep the interface as "filesystem" like as
> possible so that users feel comfortable uploading/downloading files. These
are
> some of the features that I had thought of.

I second this one.

>
> 1. Directory browsing (once directories have been implemented).

A must!

> 2. Ordering of files according to name, data, user, size etc. (we need to
add
> date as an attribute in the files table.

Another must if we have a directory type display.

> 3. Javascript pop-up window (ie browser with no border or widgets) for
> uploading of files (This feature would probably be best as a
user_configurable
> option so that Lynx users (and other Javascript haters) don't get annoyed.

As long as it's a option to the operator of the script I say let's do it.

> 4. Some (nice) colour on the page somewhere. The colour at the moment is
plain
> and a bit yucky. Possibly a VFS logo.

If we can't get a logo done, I know someone who would more-than-likely be
willing to do one for us.

BTW. I'm in the process of finishing an install of Postgres 6.5.3 on one of
my Linux systems here. I'm up to the InitDB and User account stage and
recompile of PHP to handle it. Once that's done I'll test the new HEADER
function idea.

Regards,
Tony Kirk

Re: [Vfs-devel] class.DBI

[Abdul-Wahid P. <ee...@we...>]

Tony Kirk <tk...@ca...> said: 

> All of the databases we want to support already have DBD files. 

There isn't an Oracle DBD and I wouldn't mind supporting Oracle (or 'Orable as
it is sometimes known) as use it at work. I might be able to write a
DBD::Oracle though it doesn't look to hard. When I find the time ;)

[Vfs-devel] Look-n-feel

[Abdul-Wahid P. <ee...@we...>]

I propose that we move the menu bars into .inc files so that if we make
changes to them (like adding a new item) we don't have to change it all
through the site.

I understand Adis has already done some images for the menu bar. Adis, can you
upload them somewhere where we can look at them?

I think that we should try to keep the interface as "filesystem" like as
possible so that users feel comfortable uploading/downloading files. These are
some of the features that I had thought of.

1. Directory browsing (once directories have been implemented).
2. Ordering of files according to name, data, user, size etc. (we need to add
date as an attribute in the files table.
3. Javascript pop-up window (ie browser with no border or widgets) for
uploading of files (This feature would probably be best as a user_configurable
option so that Lynx users (and other Javascript haters) don't get annoyed.
4. Some (nice) colour on the page somewhere. The colour at the moment is plain
and a bit yucky. Possibly a VFS logo.


Regards,

AW

Re: [Vfs-devel] Correct filename without mod_rewrite

[Tony K. <tk...@ca...>]

----- Original Message -----
From: "Abdul-Wahid Paterson" <ee...@we...>
To: <vfs...@li...>
Sent: Tuesday, June 06, 2000 6:52 PM
Subject: [Vfs-devel] Correct filename without mod_rewrite


>
>
> When I first started developing VFS I had the problem that when the user
tries
> to download a file because it is a PHP script that returns the file the
> browser tries to save the file as get_file.php3
>
> To get around this problem I put in a mod_rewrite rule in the .htaccess
file
> as follows:
>
> RewriteRule ^(.*?)/file/.*$ get_file.php3?file=$1
[T=application/x-httpd-php3]
>
> This worked fine but it made VFS reliant on the user having mod_rewrite
>
> Someone today showed me how to do it without using mod_rewrite basically
all
> we have to do is add this header:
>
> header("Content-Disposition: inline\; filename=$file_name");
>
> The browzer then changes the filename to the given filename and saves it
as
> that rather than as get_file.php3
>
> I have tested it so far on Netscape 4.7, IE 5.5 and Lynx 2.8.3 and it
seems to
> work fine. Can anyone test it on any other browsers. Especially older
ones. I
> am not sure how long this feature has been implemented.
>

I'll test it under Netscape 4.0 (Linux), Netscape 4.0 (Win32), IE 4.0 / 5.0
(Win32), IE 3 (NT - this is a maybe/maybe not) and IE 5 (Mac).

Regards,
Tony Kirk

Re: [Vfs-devel] class.DBI

[Tony K. <tk...@ca...>]

> > Why not look at integrating all of the database code from db_wrapper.inc
> > into class.DBI structure? We can just add all needed code to the DBD
files.
> > All of the databases we want to support already have DBD files. We could
> > possibly drop some_database_wrapper.inc and db_wrapper.inc files all
> > together. Just move that code to the necessary class.DBD::some_database
> > files.
>
> Well, I know it would really leave db_wrapper.inc to do much execept
actually
> make the database connection. However, there may be some things like
dealing
> with sequences and dates. My main reason for leaving it separate though is
> that if there are any changes make to class.DBI we can just plug in the
new
> class.DBI without having to apply all our changes again. I would prefer to
> keep things as compartmentalised as possible.
>

DOH! Damn fine point there! Thank god I'm not the only one on this team :)

Regards,
Tony Kirk