Forum OpenACS Development: Content Repository API

I've noticed that Jun has this API in the bcms package, both a bcms::item::create_item and bcms::revision::add_revision.

It seems reasonable that we roll this functionality into the content repository itself.

Background: I'm writing the batch user synchronization code, and we typically get a big XML document with either all users, or changes since last update.

Now, in order for us to be able to track when there are problems, we've decided to store the entire document. And in order to not have to bother with CLOBs and such, we thought it might be simplest to just create a CR item for it, and simply deal with it through the CR API.

Except, of course, there is no such API that we can rely on in core.

What should we do?

1) Give up, and just put a CLOB column in our table (they're not *that* hard)

2) Roll Jun's BCMS API into acs-cotent-repository.
  - Not sure what the status of the API is
  - There's going to be some amount of work involved in renaming (I'm assuming we'd use cr:: namespace instead of bcms:: namespace, but keep everything else the same) and we won't have time to do this
  - Is this consistent with what others are thinking?

3) Have other people been working on similar API? I seem to recall that Jeff wrote something like this for photo book.

4) Something else?

What are your thoughts?

/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.