Forum OpenACS Development: General Comments package update plans

Collapse
Posted by Dave Bauer on
I have started working on an updated general comments that is not dependent on acs-messaging. I put the code in openacs-4/contrib/packages/general-comments

Here is the preliminary plan:
http://cvs.openacs.org/cvs/openacs-4/contrib/packages/general-comments/TODO

The initial data model is here:
http://cvs.openacs.org/cvs/openacs-4/contrib/packages/general-comments/sql/postgresql/general-comments-create.sql

I started this work a week or so ago, but lost all my changes, so there has been a slight delay.

Any comments or suggestions are greatly appreciated, especially advice on using the attachments package.

Collapse
Posted by Peter Marklund on
Dave,
those changes sound fantastic! Great that you have taken this initiative!

/Peter

Collapse
Posted by tammy m on
Dave,

Sounds good.

Just for your consideration...

When I wanted to get General Comments into Search results... I started wondering if we need to use CR for General Comments at all? It doesn't seem like versioning (or specifying relationships to subdocuments; or defining content types; or adding custom attributes) is important for General Comments so the overhead of CR might not be beneficial.

And it might be more practical to implement search on General Comments by just using existing search on Static Pages. The Static Pages package would have to be changed slightly to simply "display" comments along with the page as it's stuffed into the database. This would have the side benefit of not having duplicate links show up in Search results for the General Comment and the associated Static Page (as happens in Forums now).

Collapse
Posted by Bart Teeuwisse on
Dave,

Tammy raises a good point with respect the versioning of comments. However, one could still use the CR even without versioning. Instead of creating a new cr_revision with each modification, one would reuse the same revision.

This way the CR continues to be the standard method of storing information and no modifications to the OpenFTS search are required.

/Bart

Collapse
Posted by Malte Sussdorff on
What is so bad about storing versions of general comments. If you are concerned about performance due to large tables due to revisions, wouldn't it make more sense to think about a "current" cr_items table and an "archived" cr_items table.
Collapse
Posted by Andrew Piskorski on
Tammy, although I'm quite familiar with most of Static Pages, I'm not especially familiar with either General Comments or the Content Repository. So I can't say definitively, but my understanding (emphasized by Don B. many times in the Forums) is that CR is and/or should be the single central point of contact for all "content" in the OpenACS system, and user comments certainly are content. So any solution which removes comments from the CR entirely is probably the wrong way to go. Sounds like using the CR without versioning like Bart says would be the right idea.
Collapse
Posted by tammy m on
Hi,

Yeah I guess archiving cr_items +/or cr_revisions is another option. This just all seems like more maintence and overhead than something as simple as GeneralComments needs... I can understand the philosophy that all content be in one place but I'm not sure that it makes it easy +/or fast to do what I'm trying to do.

Another concern for me specifically, is the way Search works with the CR. Using the Forums as an example again: the Search results contain multiple links to what is basically the same content (single messages and then the thread itself, with each single message of course being displayed out of the context of the thread) which makes it hard for the user to know what content he has seen already and that some content in the Search results will actually be duplicates (displayed on different pages).

So besides overhead + maintenance of using the CR, my question would be will the GeneralComments Search results, since they would use the CR  FTS Search procs, be able to return just the associated StaticPage the GeneralComments show up on OR will we be getting Search results linking to single pages showing any single GeneralComment out of context? This will be confusing for users.

I guess I'm confused also in that I was looking at the CR, with it's versioning and extended custom attributes, as more of a CMS solution... which would imply to me  that _all_ content wouldn't necessarily belong there.

Where can I read more on DonB's advice on CR usage?

thanks for the feedback all:)

Collapse
Posted by Don Baccus on
One reason to use the content repository is that it already has the logic necessary to differentiate between Oracle CLOB and Postgres TEXT storage.  It seems silly for individual packages to duplicate such functionality.

Another reason to use it is that we plan to extensively improve the Tcl API to the CR in the upcoming months, making it easier to use.

Of course others have mentioned other valid reasons for using the CR.

Versioning is useful in many, many more contexts than in a CMS, BTW.  Surely the capability is not always needed and I've looked into the possibility in the future of allowing non-versionable content types that use a single object for both the cr_item and cr_revision as a way of lowering overhead in such cases.  But the CR brings more to the table than just versioning.

You're free to ignore it in your own work, of course.

Collapse
Posted by Don Baccus on
Wasn't there recent work done on search and forums so the problem Tammy mentions is no longer a problem?  Or did I misunderstand one of the other threads.

Regardless, since forums doesn't use the content repository (yet) the content repository can't be blamed for this behavior :)

Collapse
Posted by Tilmann Singer on
Yes, we changed the forums search so that it indexes full threads only and not single messages, but as far as I know it's not part of the toolkit yet, only of the openacs.org site. And old messages are still indexed the old way - it needs a full reindexing which Dave plans to do later together with other things.
The general-comments package has and interesting situation. It looks like originally it used the general_comments:: namespace to define its tcl procs. At some point it was changed to general_comments_* with no namespace. The namespaced proc are marked deprecated.

It was generally agreed that using namespaces is a good idea. Looking at general-comments, it definitely can be refactored to be more flexible and remove HTML from the tcl procs.

Any advice on removing the deprecated procs, and replacing them with new namespaced procs?