In order to add web-access with any browser-capable device to an existing Xbase-application basically two things are required. A webserver with an applicationserver which has access to the Xbase-database and a webapplication which utilizes webpages driven by this data.
Development of webapplications has started with simple PHP-pages directly accessing mysql-databases. This has lead to sourcefiles, which were a mess of mixed html/css/javascript/php/sql and were a nightmare to maintain. Therefore web development frameworks introduced design patterns like MVC (model-view-controller).
Ruby-on-Rails is one of these frameworks and a popular one for very good reasons. To use Rails as applicationserver for data in a Xbase database it must have access to this database. Rails is implemented in Ruby - a dynamic, reflective, object-oriented, general-purpose programming language, developed in the mid-1990s by Yukihiro "Matz" Matsumoto in Japan. For dataaccess Rails uses an object relational mapper (ORM). That means database records are ruby-objects with member variables for each field. No SQL is needed - basically this is the same design pattern as a workarea in Xbase (Dbase,Clipper,...) is.
The ORM for Rails is ActiveRecord, written in Ruby. To access a database, ActiveRecord needs a database driver for the specific database, called database-adapter. These exist for all important systems like sqlite, MySQL, PostgreSQL, Oracle, ... Classic Xbase-applications use DBF-Files to store data, there is no database-adapter for this "database". Ironically despite the fact, that ActiveRecord dont use SQL, you need a SQL-database to write a database-adapter. What you also need is a C-API for the database and a ruby-mapping for this API. None of all these needs exist as a standard for DBF. There are some primitive libraries for DBF-access but they all fail when it comes to concurrent access and handling of indexfiles (NTX) especially in a heterogeneous environment (Windows/UNIX, CIFS/NFS).
There are three ways out of this dilemma:
SAP which owns Sybase which bought Extended System now is the owner of the Advantage Database System. The ADS database is interesting because it has some standalone features:
On the ADS site is a ruby-mapper for this C-API. This mapper was patched to support the ActiveRecord-adapter, which is also found on the ADS site. This adapter supports only Rails-3 - all of my efforts to convince the SAP-people behind ADS, to maintain the adapter, failed. They did also not fix several bugs in it, so i decided to fix them and package the whole thing. These packages contain working ruby and rails with ads:
Xbase and Rails must have concurrent direct access to the DBF/NTX-files, since both systems are serverless. I have running this setup in production on a medium-scale installation (80 users 130 tables 2G data). A NetApp storage system gives access via CIFS to the windows-clients and via NFS to Unix. The NetApp-systems respect locking in heterogeneous environments, ADSlocal's and Xbase's locking seem to be compatible. This deployment is nothing for the halfhearted, no company will give you support for it. My installation is working troublefree since several months.
This sounds like the silver-bullet way of doing it. PostgreSQL is a professional grade database and Rails works out of the box with it. Xbase applications upsized to PostgreSQL datastore should benefit in security and stability. But it is relatively new solution and i have still some tickets open at Alaska. The PACK-command does not work and there are still problems with encoding. When this solution has matured this is the way to go when DBF-files are not needed anywhere else in the stack.
I have written a pure C FastCGI server with the C-API of ADSlocal which implements full CRUD database access (see Wikipedia REST for details). Rails ActiveResource can consume this, despite being much less powerful than ActiveRecord, nevertheless this is a valid way of doing it. The server can be found in my xbase-rpm mentioned above. Concurrent access has the same support issue as the first solution.