> That's fine, I couldn't accept it before v3.0 anyway.
Possibly, we can try to make an unstable branch. And for example 2.2, 2.4, etc
will be stable, and 2.3, 2.5, etc will be unstable. In that case, it would be
possible to include new features not in 3.0, but earlier.
> Start with the file format. Something like this:
>
> <?xml blah blah blah>
> <ssqls class="MyStructureName" table="MyTableName">
> <field type="mediumint" name="myFieldName" null="1" />
> <field type="datetime" name="myOtherFieldName" />
> </ssqls>
> ...takes mytables.ssqls and creates mytables.h. (Maybe creates
> mytables.cpp, too, but I'm not certain about that. It might be better
> if everything remained inline.)
I guess it can be defined by xml tag/command line parameter. But variant with
*.cpp looks better for me :)
> 3. Cope with different type systems. Notice above that I'm using SQL
> type names. It should be smart enough to translate those into the
> proper MySQL++ type names. Likewise, if I put in, say, time_t, it
> should be able to figure out the right thing to do there, too.
Give a more detailed description, please.
> 5. SSQLS structures should derive from a common base class. This let
> you put some useful common code in the MySQL++ library itself, but more
> importantly, it would let you make methods like Query::insert() into
> regular methods instead of templates.
Give a more detailed description (example), please.
