From: Chris Frey
Date: June 14 2005 3:51am
Subject: Re: v2.0 release plan
List-Archive: http://lists.mysql.com/plusplus/4527
Message-Id: <20050614035116.GB12942@netdirect.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On Mon, Jun 13, 2005 at 02:01:43PM -0600, Warren Young wrote:
> Please let me know which ones you plan on tackling, and I'll stay away 
> from those areas.  Personally, I'm considering starting with the 
> exception handling stuff first.

Go right ahead, I have other projects that are pressing right now.

I'll make good use of the mailing list to coordinate effort.


> >	- performance... recent posts to the list have exposed some possible
> >		areas where the library could be tuned.  I'm big on making
> >		use of small hardware, so performance is another key interest
> 
> Can I mark you as the responsible party for the Row optimization stuff, 
> then?

Sounds good.  I'll take that as project #1 when I get time.


> >	- database independence... yes, this dream is still alive. :-)
> 
> If so, then we'd better do it a different way than it's currently being 
> handled.

I have no problem with that.  I haven't even looked at it closely enough
to design anything yet, and fully expect that things will be cleaned up
when I get to it.  I hope to help clean things up first, so that when
database-independence is added, hopefully there won't be a lot of
maintenance to keep up with the main tree.

One idea that pops into my mind would be a higher level API class, like
your driver idea, and then when the user wishes to select the database
to use, it would be something like:

	Connection<MysqlDriver> con;
	Connection<PostgreSQLDriver> con2;
	// etc


> Above all, I see no point in having even the hint of database 
> independence in MySQL++ until at least two database server types are 
> supported.  One should never have unused extensibility mechanisms; they 
> just become baggage.  One should refactor existing nonextensible 
> mechanisms into extensibility, so that you always get exactly the 
> interface you need right now, not the one you think you will need someday.

I agree.  My database-independence-hinted code will be separate until it
works.  Whether that's on a separate branch or just a tarball on my
website doesn't matter to me.


> Naming issues are going to be a problem if you pursue this.  namespace 
> mysqlpp, libmysqlpp, Gna project mysqlpp...

We can worry about that once something is working.  :-)


> >		I don't think this is of much general interest, 
> 
> Oh, I don't know.  It'd be nice to have the option to swap out backends, 
> just so you'd _know_ how such changes affect one's program.  Even if you 
> come back to MySQL, it's nice to have the option.  But can we agree that 
> a driver paradigm makes more sense than the current class hierarchy?

I agree a driver mechanism seems pretty clean as well.  With templates,
perhaps it is possible to get away with only specifying the driver in
one spot.  Don't know until I try it.

If I find I need a hierarchy later, I'll have technical arguments to
back it up, and you can talk me out of it then. :-)  I'm always open to
better design ideas.  Right now I have no working code.

- Chris