This is a partial copy of an email I sent to Marc Powell about
the future of the project.

Date: 25/02/2002
---------------------------------------------------------------

Hi,

<snip>

I want to wait just a little longer for 1.0 - more to
keep my options open than anything else.  If a really cool
requested feature comes along which requires database changes
I have more flexibility to do them in releases prior to
1.0.

But in the next few months I would like to move to 1.0.

There are a few things I want to finish first:

1)  Move to full compliance with php 4.1.0, by removing
    all http global variable references.  I have added the
    begin.inc.php script to put all http variables into
    a $HTTP_VARS array to avoid having to worry about whether
    the request is GET/POST etc.
       => I have already removed SESSION global variables.
       => Many of the newer classes are complete.  Probably
       about 50% more of the total to complete.

2)  I would like to remove much of mysql specific logic and replace
    with a abstract database interface.  I do not plan to change
    the SQL or actually provide other database support, but I wanted
    to start with removing all mysql php stuff first, and then
    consider how to proceed.
     ==> Any suggestions on existing php database libraries welcome!

3)  Add the ability to prefix all OpenDb tables with a configurable
    string, to provide support for users with access to only one
    database.  This is problematic for the Patch system, where I
    would have to implement a SQL parser to replace the table
    references with the prefix.  (Not too bad - as I only need to
    worry about parsing the 'from' clause!)  This is something that
    I see as very important in the long run, as I have a feeling
    many users would find it useful.
 
4)  A restrictions system.  This would allow an administrator to
    restrict access to particular items, such as items with an 
    X AGE_RATING.  The system would also be flexible enough to
    allow individual users to restrict access to particular users.
      => docs/restrictions.txt
      The Requested Features: 'Maximum Rating allowed',
                  'Restricting concurrent borrowed items',
                  'Individuals approving users'

5)  I would like to complete a 'Borrower Ratings' system whereby
    users would be given a rating for their ontime return of items,
    as well as the general condition of the item upon return, etc.
    
    Each user would start with a platinum rating and gradually
    get reduced, until they have been 'black banned' for instance.
     => This feature would encourage borrowers to look after items,
     and allow potential lenders to decide whether to lend or not.
     The system would obviously allow users to come back from the
     'black' status by repeated good ratings.  The system would not
     enforce anything, but as a guide to lenders...

I am planning to go 0.50 instead of final 0.39, which may surprise a few 
people, but ....

Then I want to start looking at the restrictions functionality again and start 
implementing some of that.  All the restrictions functionality will be fully
configurable and users who are not interested can get back the speed lost by
disabling it.  There will some speed loss when the functionality is enabled,
but will offer a lot of power - so a trade off ...

Anyway thats the plan for the future.

I am currently developing a feature for listings.php where you
will be able to specify a title_display_mask for the 'Title' column.  
You will be able to specify extra s_attribute_type item_attribute
values to display along with the title.  This would be useful for
those people making use of the ALT_TITLE attribute for non-english
titles, etc.  Obviously it will be disabled by default, as extra
queries on item_attribute table are necessary.

<snip>

Cheers
Jason
--
Vegan Philosopher Programmer