vfs-devel

[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] 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

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

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
>