Hello,
I have started work on building an API for CMS that would allow different
modules to be programmed for it. For example, one module could use a SQL
database for storage as another could use the local filesystem. The
administrator could then decide how to store the content depending on the
software available and storage needed.
I am thinking about building a basic interface class from which all the
modules would be extended. This would use the object-oriented features of
Perl and could in the end simplify very much the future development of CMS.
Should we make the authentification and storage modules as separate ? I have
received emails suggesting the use of the HTTP authentification mechanisms
to control access, and I was thinking about building an authentification
method based on text and configuration files.
What I have to do is to decide how the base classes of the API will be
built. Here's what I have in mind:
--storageAPI
|--setDirectory (sets the current directory)
|--getSubdirectories (returns a list of subdirectories in the current
directory)
|--getFiles (returns a list of files in the current directory)
|--getFileProperties (returns the properties of the filename passed in
parameter
| ie. Reserved or not, comments, date of last
modification, etc.)
|--checkOut (returns the content of the file passed in parameter. Sets ir
reserved
| depending on a second parameter)
|--checkIn (takes the filename and its content by parameter)
|--discardReservation (discards the reservation on a filename passed in
parameter)
|--setComment (sets a comment on a filename, both passed in parameter)
|--createDirectory (creates a new subdirectory in the current directory)
|--deleteFile (deletes a file)
--authentificationAPI
|--login (takes a username and password in parameter and returns wether it
was
| successfull or not)
|--logout (logs out a given user)
Now, this API would allow us to have one main file where calls are made to
the right API depending on the configuration selected.
Any comments, suggestions ?
Alexandre Gravel
Infivia Solutions
gr...@in...
http://www.infivia.com
|
