Hello Brian, ----- Mensaje original ----- De: Brian Braatz <brianb@rmtg.com> Fecha: Jueves, Julio 28, 2005 10:34 pm Asunto: Re: [boost] Interest in an ODBC library?

If you are interested in collaborating, I have wanted to (for some timenow) build the table<> aspect of what you are working on.

My goals: 1- functional drop in replacement for ADO recordset 2- Dynamic and static "views" and indexes 3- binding model that does NOT force you to use the bindings supplied with the library this is something ADO lacks, and something I have had to work around to great frustration 4- the ability to COPY from one table<> to another table<> * ADO does NOT ALLOW you to copy recordsets. (brilliant no?)

Additionally -

I am not sure if he is still interested, but Joaquin Munez and I exchanged emails awhile back about collaborating on such a beast.

The general idea was to take the functionality in multi-index containerand make it work dynamically.

I am still interested, and it is my plan to implement a dynamic_multi_index_container in the future, if there's interest in such a thing --serving as the foundation for a DB table structure would be a very exciting application, undoubtedly. Let me sketch what I have in mind: The part of adding/removing indices at run time is not too hard: I haven't written any actual code, but the design of that feature seems reasonably straightforward to me. Some speed/space performance will be lost, but I guess this is expected. The hard part, IMHO, is how to gain access to such indices. Clearly some kind of runtime polymorhpisn is involved for a dynamic_multi_index_container to have any use: otherwise, the user code would have to know the exact type of the index it is retrieving. So we need something more powerful than the current static get<> interface. A possibility is to retrieve indices by mean of *interfaces* as defined in Jonathan Turkanis' BIL library: http://www.kangaroologic.com/interfaces/libs/interfaces/doc/ This interface concept provides the needed run-time polymorphism without having to cast the index classes into a rigid abstract hierarchy. This would allow the user to tune the polymorphic functionality exposed by indices from the most general (iteration) to the most concrete (for instance, set-like functionality, so restricting the type of acceptable indices that can go into the container) only by defining the interface to which the indices must conform. Of course, this is just a bunch of random thoughts and the BIL library is not part as of yet of Boost, so I don't think I'll be ready to provide something until mid 2006 or so. Moreover, it's still to be seen whether a dynamic_multi_index_container is of interest to the Boost community.

I am working on something unrelated to this discussion that could form a good foundation for table<>. I should have something to share middle of next week.

Just let me know if you are interested in putting our heads together.

Sure! I'll be reading your table<> material as soon as you make it available. Soon I'll be on a three-week vacation, so I might have some time to write my ideas about a dynamic_multi_index_container in a more structured way. Best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo