SOURCE 

>  On Behalf Of Hajo Kirchhoff
>  
>  Brian Braatz wrote:
>  > you split the lib into a few pieces:
>  >
>  > 1- Get the data from the data base and stream it into X
>  > 2- a stock form of "X" (like the table you described)
>  > 3- Helpers for binding
>  >
>  > if you built the thing that way, then it will be usable by those of
us
>  > out there who have large bodies of code relying on things like ADO
>  > recordsets. I would love to replace the recordsets, but I need to be
>  > able to selectively use pieces of your library and I need to have a
>  > usage model that is similar.
>  >
>  
>  Thanks, interesting thoughts.
>  
>  Hajo
>  

[Brian Braatz Writes:] 
If you are interested in collaborating, I have wanted to (for some time
now) 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 container
and make it work dynamically.

(and there is more)

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.

:)

Brian




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost