"Robert Ramey" <ramey@rrsd.com> wrote
I just looked over the documentation and I like what I see. Its no clear what's missing - of course I didn't try to use it. I think you might get more response to your request for help if.
a) the directory structure and documentation looked more like a boost library so that one could just paste it into his boost tree.
Agreed -- will do it.
b) it was clear what's working and what's not. Maybe this should be reflected in the directory structure.
c) If it was divided into working / not working.
d) if the working subset was immediately useful. E.g. transactions could be postponed. It looks like you've focused on adding all the features before finishing off the basics ( documentation, examples, tests, etc.) This makes it hard for users to become addicted to your library which is what you need to get more help. The best way to get help is to get people using (part of) your library. When they need some feature, you can pressure them to create it and add a test.
I do not believe there really is anything that can be qualified as "not working". It's rather "not production quality". We actually implemented all we wanted, and it does pass all our unit tests. You can view it as a system that is pretty much "QA-ready". My real problem with this is that I believe systems should be given to "QA" by much smaller portions. We actually tried to present the system to Boost three times: 1) After we implemented relational tables and relational operations on them; 2) After we added indexing and range queries (for any relation); 3) After we added transactions and incremental index update. One problem is that it's pretty difficult to present this system on the piece-by-piece basis. For example: Our approach to transactions was to store changes (deltas) separately from tables untill the transaction is committed. At the moment of commit we wanted to be able to calculate delta for any particular node of any expression built on modified tables. This would allow us to incrementally update indexes, if needed, rather than fully rebuild them. Once you commit to such a goal, you have to implement deltas for ALL the operators you support, because you have no idea what operators will be used in the expression... OTOH, we could probably first implement this without incremental index update and always fully rebuild the indexes. That would have been 10 % of the effort. That was what we would definitely have done if we had had a real User. Since we didn't really have users, we just kept on implementing what we thought needed to be done. I think some things need to be re-designed and re-implemented not because they don't work, but rather because after someone has been working on a system for two years, there always is something that shout have been done differently...
Machines and applications are now being made that can really benefit from the RTL library.
I definitely hope so :) Regards, Arkadiy