samba - Jun 2006 - Samba as a frontend to virtual files

My company built a little business application in FoxPro many years ago, and 
it's gradually grown into a giant ball of mission-critical haywire. 
We've
starting porting small parts of it to PostgreSQL, but it will probably take 
years to complete the project.  In the mean time, I've been considering the 
option of hacking Samba to present a set of virtual files that are actually 
frontends to PostgreSQL tables.

For those of you who are blissfully unaware of FoxPro's workings, it 
basically operates on a bunch of binary files that each client reads from a 
fileserver when it wants to search and writes when it wants to update.  
These files have a very simple format: a fixed-length header followed by a 
number of fixed-length records.

My idea was something like this:

1) Add a "foxproid" column to each PostgreSQL table.

2) When a client seek()s to an offset, convert that to a row number.

3) If the client read()s, do:

  a) select * from pgtable where foxproid = $seek_row;

  b) Convert the results into a string of bytes (this process is well 
defined) and return them to the client.

4) If the client write()s, do:

  a) Convert the string of bytes into an array of values (this process is 
also well defined).

  b) update pgtable set column1=array[0], etc...

5) If the client asks for a list of files, return the list of eligible 
PostgreSQL tables.

...and so on.  The payoff would be that legacy code could still access the 
data without realizing that it was running against an RDBMS, but we could 
gradually transition to a pure client/server system at our leisure.  We're 
currently running some home-rolled scripts to convert the table files to 
PostgreSQL tables on an hourly basis, but the possibility of doing away 
with that architecture and keeping live data in a real database is awfully 
attractive.  If this worked, I could almost guarantee that every FoxPro 
user the the world would immediately migrate to such a setup.

What do you think?  Does this seem feasible, or hopelessly out of scope for 
Samba's design.  Would a good programmer who hasn't had a reason to look
at
Samba's codebase before be able to manage such a thing?
-- 
Kirk Strauser
The Day Companies

On Thu, Jun 15, 2006 at 04:30:18PM -0500, Kirk Strauser
wrote:
> My company built a little business application in FoxPro many years ago,
and
> it's gradually grown into a giant ball of mission-critical haywire. 
We've
> starting porting small parts of it to PostgreSQL, but it will probably take
> years to complete the project.  In the mean time, I've been considering
the
> option of hacking Samba to present a set of virtual files that are actually
> frontends to PostgreSQL tables.
> 
> For those of you who are blissfully unaware of FoxPro's workings, it 
> basically operates on a bunch of binary files that each client reads from a
> fileserver when it wants to search and writes when it wants to update.  
> These files have a very simple format: a fixed-length header followed by a 
> number of fixed-length records.
> 
> My idea was something like this:
> 
> 1) Add a "foxproid" column to each PostgreSQL table.
> 
> 2) When a client seek()s to an offset, convert that to a row number.
> 
> 3) If the client read()s, do:
> 
>   a) select * from pgtable where foxproid = $seek_row;
> 
>   b) Convert the results into a string of bytes (this process is well 
> defined) and return them to the client.
> 
> 4) If the client write()s, do:
> 
>   a) Convert the string of bytes into an array of values (this process is 
> also well defined).
> 
>   b) update pgtable set column1=array[0], etc...
> 
> 5) If the client asks for a list of files, return the list of eligible 
> PostgreSQL tables.
> 
> ...and so on.  The payoff would be that legacy code could still access the 
> data without realizing that it was running against an RDBMS, but we could 
> gradually transition to a pure client/server system at our leisure. 
We're
> currently running some home-rolled scripts to convert the table files to 
> PostgreSQL tables on an hourly basis, but the possibility of doing away 
> with that architecture and keeping live data in a real database is awfully 
> attractive.  If this worked, I could almost guarantee that every FoxPro 
> user the the world would immediately migrate to such a setup.
> 
> What do you think?  Does this seem feasible, or hopelessly out of scope for
> Samba's design.  Would a good programmer who hasn't had a reason to
look at
> Samba's codebase before be able to manage such a thing?
Perfectly doable using Samba's VFS layer. If you're starting now I'd
work out of Samba HEAD svn right now as we're planning to change the
VFS interface to include James Peach's work once 3.0.23 ships.

Jeremy.