vfs-devel

[Vfs-devel] Correct filename without mod_rewrite

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

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 have attached the get_file.php3 with the necessary modifications. You can
use it for testing by calling get_file.php3?file=$file_id where $file_id is
the file_id of the file you want to test.

If all works fine I think we should include this in any 0.1 updates ahead of
the 0.2 database integration release

Regards,

AW

Re: [Vfs-devel] class.DBI

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

> 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. 


> 
> To make the code and file structure cleaner I agree with the /lib directory
> idea. I'm a sucker for keeping like files grouped into directories.

Okay that is finalised at least.


Regards,

AW

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 12:49 PM
Subject: [Vfs-devel] class.DBI


>
> I have just been playing around with class.DBI and it seems to work fine
> with Postgres. I haven't tried any other database though but I am sure
> they work properly.
>
> There are a few issues around using class.DBI that we need to resolve.
> Manly due to the use of BLOBS for file storage. The way that PHP handles
> blobs for Postgres, Oracle and Informix is complete different. Mainly
> because there is no standard way that the databases handle blobs. I
> suggest that we have different functions for the individual databases that
> use blobs. Where should they go? May be we could still put them in
> some_database_wrapper.inc that gets included from by the db_wrapper.inc.

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.

I'll spend some time today playing with the class.DBI code and comment more
on it later today.

> The structure would then be something like this:
>
> header.inc calls vfs_auth.inc, db_wrapper.inc and config.inc
>
> db_wrapper.inc calls some_database_wrapper.inc and loads class.DBI
>
> class.DBI loads the relevant class.DBD::some_database
>
> NOTE: we might also need to use the some_database_wrapper.inc to do other
> database specific functions like: using sequences, formating dates, etc.
>
> I suggest also that we create a directory /lib where we put the .inc
> files and the class.DBI stuff. We might have to change the class.DBI
> slightly because it calls the DBD driver from the current directory which
> won't be /lib but / becuase that is where the .php script will be running
> from.

To make the code and file structure cleaner I agree with the /lib directory
idea. I'm a sucker for keeping like files grouped into directories.

>
> Anyone else got any ideas on all of this?
>
> Regards,
>
> AW
>
>
>
>
> _______________________________________________
> Vfs-devel mailing list
> Vfs...@li...
> http://lists.sourceforge.net/mailman/listinfo/vfs-devel
>

[Vfs-devel] class.DBI

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

I have just been playing around with class.DBI and it seems to work fine
with Postgres. I haven't tried any other database though but I am sure
they work properly.

There are a few issues around using class.DBI that we need to resolve.
Manly due to the use of BLOBS for file storage. The way that PHP handles
blobs for Postgres, Oracle and Informix is complete different. Mainly
because there is no standard way that the databases handle blobs. I
suggest that we have different functions for the individual databases that
use blobs. Where should they go? May be we could still put them in
some_database_wrapper.inc that gets included from by the db_wrapper.inc.
The structure would then be something like this:

header.inc calls vfs_auth.inc, db_wrapper.inc and config.inc

db_wrapper.inc calls some_database_wrapper.inc and loads class.DBI

class.DBI loads the relevant class.DBD::some_database

NOTE: we might also need to use the some_database_wrapper.inc to do other
database specific functions like: using sequences, formating dates, etc.

I suggest also that we create a directory /lib where we put the .inc
files and the class.DBI stuff. We might have to change the class.DBI
slightly because it calls the DBD driver from the current directory which
won't be /lib but / becuase that is where the .php script will be running
from.

Anyone else got any ideas on all of this?

Regards,

AW

[Vfs-devel] what's next?

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

I think we should work towards a 0.2 release being a rewrite to include
multiple database support. Initially we should concentrate on including
mySQL support which is going to have to be done without any blobs. Does
mySQL support blobs at all?

If there are any bugs in 0.1.1 then I will fix them and release a 0.1.2
otherwise 0.2 should be basically the same features but with multiple
database support and non-Blob support.

It may be the case that even Postgres users don't want to use blobs.
First, they requrire the Postgres user to be a superuser and secondly some
people aren't convinced on their speed. Although, my own testing proves to
be okay.

We need to work out how we are going to divide the tasks between us. I
suggest that we first port the db_wrapper.inc to use class.DBI and then we
divide the work between us for changing the existing files over to use
it. I will try to get something working using class.DBI later today.

I suggest that we use the task manager on the sourcforge page for keeping
track of who is doing what and how much progress has been done in each
task.


Regards,

AW

Re: [Vfs-devel] First on the topic list?

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

All sounds good to me. As far as the CVS account, not yet. I'll do that
tonight.

Tony Kirk

----- Original Message -----
From: "Abdul-Wahid Paterson" <ee...@we...>
To: <vfs...@li...>
Sent: Monday, June 05, 2000 7:36 PM
Subject: Re: [Vfs-devel] First on the topic list?


>
>
> > Save the uploaded file as 'VFS$file_id'
> > When the user goes to download the file copy the stored file over to the
> > original file name or create a sym link to the stored file. What's your
> > ideas? Copy or symbolic link? or does it really matter?
>
> I think that we should have an option in the config.inc file to allow them
to
> use mod_rewrite where it is available. mod-rewrite does an excellent job
and
> is so easy to set-up. Look at the .htaccess file in the distro. Otherwise,
> probably a symlink would be quicker to set-up especially for large files
that
> are over say 20 Mbytes.
>
> >
> > I've checked out the class. Looks to be very clean. Also looks like it
will
> > get the job done.
>
> If we are going to move to class.DBI, which I think we probably should.
Then
> we need to finalise which files are going to do what and then port the SQL
to
> use class.DBI This is what I am thinking of as a structure:
>
>
> 1. Every page - has a call to header.inc at the top
>
> 2. header.inc - has a few functions that are used througout the site and a
> call to vfs_auth.inc and db_wrapper.inc. It also loads the config.inc file
and
> sets up the configuration variables.
>
> 3. db_wrapper.inc - provides and sets up the generic database
functionality
> and loads either some_database.DBD or some_database_wrapper.inc
>
>
> BTW Tony, have you setup your CVS access to the code? You should be able
to
> make changes using your s/f login id directly to the CVS
>
>
> Regrads,
>
> AW
>
>
>
> _______________________________________________
> Vfs-devel mailing list
> Vfs...@li...
> http://lists.sourceforge.net/mailman/listinfo/vfs-devel
>

Re: [Vfs-devel] First on the topic list?

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

 

> Save the uploaded file as 'VFS$file_id'
> When the user goes to download the file copy the stored file over to the
> original file name or create a sym link to the stored file. What's your
> ideas? Copy or symbolic link? or does it really matter?

I think that we should have an option in the config.inc file to allow them to
use mod_rewrite where it is available. mod-rewrite does an excellent job and
is so easy to set-up. Look at the .htaccess file in the distro. Otherwise,
probably a symlink would be quicker to set-up especially for large files that
are over say 20 Mbytes. 
 
> 
> I've checked out the class. Looks to be very clean. Also looks like it will
> get the job done.

If we are going to move to class.DBI, which I think we probably should. Then
we need to finalise which files are going to do what and then port the SQL to
use class.DBI This is what I am thinking of as a structure:


1. Every page - has a call to header.inc at the top

2. header.inc - has a few functions that are used througout the site and a
call to vfs_auth.inc and db_wrapper.inc. It also loads the config.inc file and
sets up the configuration variables.

3. db_wrapper.inc - provides and sets up the generic database functionality
and loads either some_database.DBD or some_database_wrapper.inc


BTW Tony, have you setup your CVS access to the code? You should be able to
make changes using your s/f login id directly to the CVS


Regrads,

AW

Re: [Vfs-devel] First on the topic list?

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

----- Original Message -----
From: "Abdul-Wahid Paterson" <ee...@we...>
To: <vfs...@li...>
Sent: Monday, June 05, 2000 9:15 AM
Subject: Re: [Vfs-devel] First on the topic list?


> Yes, I am aware of this problem and I think I included it on the original
> TODO list in the 0.1 distrbution. I agree with your solution as it is
> pretty much with what I already had in mind. The disadvantange of the
> filesystem way is that you need to have a webserver writeable directory.

Well we just need to have the user create a directory (or chmod the VFS app
directory) to allow read/write for user nobody (or whatever account they
have apache or whatever web server, running as). And how about doing
something like this...

Save the uploaded file as 'VFS$file_id'
When the user goes to download the file copy the stored file over to the
original file name or create a sym link to the stored file. What's your
ideas? Copy or symbolic link? or does it really matter?

> But apart from that it isn't really a problem. Everyfile has a unique file
> number "file_id". Maybe we could use that for the filesystem filename so
> that it becomes something like VFS$file_id. Is there any advantage of
> making the filename random?

There was no REAL point to the random file name deal. Just a way to make
sure there were no duplicate file names being stored. I like your idea
better :)

>
> I agree with this layout. However, I think we should take a look at the
> class.DBI. Although it would involve a lot being rewritten, they may have
> done a lot of work for us already. I am waiting for Roland to get back to
> us about it. He doesn't seem to have joined the mailing list yet.
>
> You can find out about class.DBI at
>
> http://evil.inetarena.com/php/DBI.php3
>

I've checked out the class. Looks to be very clean. Also looks like it will
get the job done.


Regards,
Tony Kirk

Re: [Vfs-devel] vfs-0.11

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

Ok I have released a new version labled 0.1.1

We can now start discussing the mySQL integration and other database
support.


On Mon, 5 Jun 2000, Abdul-Wahid Paterson wrote:

> 
> I am going to release another version today that fixes a couple of bugs in
> 0.1 and also introduces some new features like encrypted passwords,
> logging, delete user and more detailed file information.
> 
> After 0.11 we need to discuss how we are going to integrate other database
> support into VFS and what are roadmap will be for introducing new
> features. I will write some more on this later today.
> 
> See ya
> 
> AW
> 
> 
> 
> 
> _______________________________________________
> Vfs-devel mailing list
> Vfs...@li...
> http://lists.sourceforge.net/mailman/listinfo/vfs-devel
> 

[Vfs-devel] New project help for look-n-feel

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

Adis, (Sourforge login abb), has joined the vfs devel team to work on the
look and feel aspects. He will be working with us to make VFS look smart
and to introduce some grahics etc.

Cya,


AW

Re: [Vfs-devel] First on the topic list?

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

On Mon, 5 Jun 2000, Tony Kirk wrote:

>     We may have to work out another storage method for the files since not
> all DBSs have comparable functions to the Postgres function; pg_lo_import.
> On large files for servers without a function like that the only option
> would really be to encode the file and store it or read the file in and
> store it as a normal blob type. Both of which would be time consuming for
> very large files (8 megs or more). How about storing the file as a file?
> Creating a file named VFSXXXXX where X would be randomly generated
> characters to insure unique file names. Just keep looping until you get a
> random file name. Then store the original filename in the database so it can
> be sent to the user with the correct file name. That would insure that
> separate methods wouldn't be needed for storing the files with different
> DBSs. Just an idea.

Yes, I am aware of this problem and I think I included it on the original
TODO list in the 0.1 distrbution. I agree with your solution as it is
pretty much with what I already had in mind. The disadvantange of the
filesystem way is that you need to have a webserver writeable directory.
But apart from that it isn't really a problem. Everyfile has a unique file
number "file_id". Maybe we could use that for the filesystem filename so
that it becomes something like VFS$file_id. Is there any advantage of
making the filename random?

 
>     Also we need to work out the layout of the scripts. If you want the
> scripts as one set of files and the db_wrapper files to be separate - it
> would require a small rewrite of some of the current code since there is SQL
> statements being generated through the scripts. My idea for the layout would
> be the following.
> 
> config.inc
> postgres_db_wrapper.inc
> mysql_db_wrapper.inc
> [then whatever other databases will be supported]_db_wrapper.inc
> Then the rest of the scripts.

I agree with this layout. However, I think we should take a look at the
class.DBI. Although it would involve a lot being rewritten, they may have
done a lot of work for us already. I am waiting for Roland to get back to
us about it. He doesn't seem to have joined the mailing list yet.

You can find out about class.DBI at

http://evil.inetarena.com/php/DBI.php3



> In the config.inc file would be a setting like: 
> $dbtype = "postgres";
> 
> and in the scripts needing the db functions all you would need is:
> 
> require("config.inc");
> require("$dbtype_db_wrapper.inc");
> 
> Does all of this make sense? It's a pretty typical setup for PHP apps that
> support multiple DBSs.

Yes it makes sense. I also wanted to move all the .inc files to be
included from the header.inc file so that every page only needs to include
one .inc file to get everything set-up as required.


Regards,

AW

[Vfs-devel] First on the topic list?

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

    We may have to work out another storage method for the files since not
all DBSs have comparable functions to the Postgres function; pg_lo_import.
On large files for servers without a function like that the only option
would really be to encode the file and store it or read the file in and
store it as a normal blob type. Both of which would be time consuming for
very large files (8 megs or more). How about storing the file as a file?
Creating a file named VFSXXXXX where X would be randomly generated
characters to insure unique file names. Just keep looping until you get a
random file name. Then store the original filename in the database so it can
be sent to the user with the correct file name. That would insure that
separate methods wouldn't be needed for storing the files with different
DBSs. Just an idea.

    Also we need to work out the layout of the scripts. If you want the
scripts as one set of files and the db_wrapper files to be separate - it
would require a small rewrite of some of the current code since there is SQL
statements being generated through the scripts. My idea for the layout would
be the following.

config.inc
postgres_db_wrapper.inc
mysql_db_wrapper.inc
[then whatever other databases will be supported]_db_wrapper.inc
Then the rest of the scripts.

In the config.inc file would be a setting like:
$dbtype = "postgres";

and in the scripts needing the db functions all you would need is:

require("config.inc");
require("$dbtype_db_wrapper.inc");

Does all of this make sense? It's a pretty typical setup for PHP apps that
support multiple DBSs.

Regards,
Tony Kirk

[Vfs-devel] vfs-0.11

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

I am going to release another version today that fixes a couple of bugs in
0.1 and also introduces some new features like encrypted passwords,
logging, delete user and more detailed file information.

After 0.11 we need to discuss how we are going to integrate other database
support into VFS and what are roadmap will be for introducing new
features. I will write some more on this later today.

See ya

AW

[Vfs-devel] Test Message.

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

Testing