Hmmm, interesting ideas. I hate to always look at problems via my query-writer package, so please try to ignore that, I'm not wishing anyone to pick it up and use it.
Actually, query-writer has never been used to build views, do selects, etc. as I have always thought it nearly impossible to pass through the expressiveness of a nice SQL query to Tcl or any other language. One thing query-writer starts with which is helpful is a list of columns available for certain operations on objects: new, set, del, rst (reset). A view operation/permission is easy to add. This simply provides a method of tagging which columns of a defined object are available to a certain qw group (tied to a relational segment). qw groups span objects, and in general there is an admin group, usually getting all columns, and a site member group, getting a developer defined subset.
The concept is that the developer can establish in one place what a particular group of users can do with a set of objects without the need to write new pages for each group.
Ditching query-writer, you can get the same effect with tying a list of object/columns to a rel segment, and add users to the rel segment, or just re-use an existing rel segment that is already related to the package making use of list builder. Query-writer reuses main site members and site wide admins for the default access controls.
So the only thing I'm really suggesting here is to use a proxy object, same as for the features object, but assign permissions based upon the type of membership in a rel segment.
