Boost logo

Boost :

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2004-10-17 20:16:37


"Robert Ramey" <ramey_at_[hidden]> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk