[RFC] set based apis...

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Clatworthy wrote:
> Generally speaking, what you're proposing is great policy. If there is
> no need to force a constraint on an API, don't do it because it
> restricts implementation choices.

Sure it's great in theory, but there are always reasons for enforcing
these kind of constraints. If you need something in a particular order,
and you get it in the wrong order, then you have to compensate, by doing
your own sorting.

It would be silly, for example, if repositories provided knit deltas out
of build order.  There's no advantage to storing them out of build
order, and it's hard to imagine how they could get out of order in the
first place.  Yet without a guarantee that they will be returned in the
correct order, the upper layer must enforce that ordering.

I would suggest that there are at least two categories of data that
should have an enforced ordering, and this ordering should be reflected
in the repo storage itself:
1. Inventory data should be provided in parent-to-child order
2. File versions should be provided in a buildable order.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGnsVw0F+nu1YWqI0RAv2NAJ4hAQy9QllQeG0saazJrBYR/N4vOwCePbsE
drOxC5ttRIjJFCAoQCBn4EE=
=2cCA
-----END PGP SIGNATURE-----