Blue Sky: Scripting Language / SQL database ?
From: Zitan Broth <zitan_at_mediasculpt.net>
Date: 2003-04-28 08:36:13 CEST
Been having a look at Subversion and it is an excellent open source project alright, far more flexible than CVS, and particularly awesome to support DAV and DeltaV. And my interest in Subversion comes *especially* from the DeltaV support. To be able integrate Subversion with into a web service-based architecture it would require some extra functionality mentioned in the "Future" section of the Subversion Design doc. My serving side scripting language of choice is PHP but I'm sure you could achieve a bridge to PHP from Perl also.
With a scripting language glue layer in between the Subversion "business logic" (eg how to implement DeltaV, DAV) and the current "persistance" layer (currently Berkely DB) it would be possible to take advantage of the logic that handles DAV and DeltaV but extend the logic and change how things are persisted in powerful ways (ie write another backend), say for example persisting part of the data in an SQL database (metadata, text docs, collections even and the other part (larger media files) in a file repository, and so on. It would also mean that organisations would likely extend the mod_dav backend via svn also, so that their custom backends could support DeltaV where required. A language like PHP supports almost every SQL database under the sun as well as being able to call Perl, Pthyon, Java and even .NET allowing integration into any platform or backend desired.
I'm installing a windows version locally of Subversion now and will look over the API documentation (svn_fs.h), however I'm (not yet) a C developer. So I'm interested to know what the interest in this project extension? How hard would it be to implement? Is work currently underway? I guess if the architecture is well abstracted (and Subversion looks to be an excellently managed project ;)) it would be a matter of editing the current API between the logic and the persistance to call a series of classes which are currently blank but would be filled in by the developers as required. Have I got the "right end of the stick" here or is the work far more complicated (eg is part of the logic embedded with the persistance layer interface)?
Any comments a greatly appreciated.
This is an archived mail posted to the Subversion Dev mailing list.