Hi Lars,
I guess that would be great. Here is the current status of the API. The single item manipulators: create_X, set_X, delete_X, VERB_X are the ones that are more useful and more stable. I am adding more comments and properly using @param, @returns, etc. rather than my own comments on ad_proc.
The list_Xs and tree_Xs api are the ones that are moving/unstable. And frankly the lesson that I got it. There is really no substitute for SQL. So list_Xs and tree_Xs will move to a more fixed query and provide as a basis for programmers. So list_Xs and tree_Xs seem to relegate to quick slap together with list builder to make a draft UI. The final UI will need the developer to take the sample query and tweak it to his own needs. Unless some guru programmer can make a persistence layer in tcl. My initial goes with list_Xs and tree_Xs is to centralize the queries, so if I tweak it affects all code that uses it. Right now I have accepted that the goal is just too much as of this time.
I will happy to help to move it to CR, the ones that I know are stable. In particular the folder procs are stable, and I just finished a run through on the docs of it. I have also added categories support using cr_keywords as of this time. But goal for this it to look at Timo's code. And have a switchroo when Timo's code is a go. But I haven't taken a proper look at Timo's code. What I have done so far is not to use keyword term but category term.
Another option is not to roll it into core yet. Since this is pretty much new I would not like to roll it into core and then later on think that its not good. We can create a package and take a namespace of cr:: Then when we think things are good enough, we then roll it into core.
Hope this inputs give you more info, I am available for chat if needed.
