Thanks Dave and Joel:)
Right I don't need to implement triggers for general-comments because I do see the general-comments object I add go into the search_observer_queue. Actually it turns out to be a acs_message_revision object.
Because the object_type of the acs_object that general-comments inserts in cr_revisions is acs_message_revision (not general-comments specific type), I guess I should implement the FTSContentProvider service contract on acs-messaging (not general-comments)? Since acs_message_revision is the object_type that the search_indexer proc will be looking for when it needs the procs that FTSContentProvider provides.
But this brings up another issue because I suppose I can use the content/datasource from the acs_message_revision object BUT I want to have the URL for the StaticPage associated with the GeneralComment returned. I can think of a few really hacky/kludgy ways to do this (have the acs_message_revision url sc proc run some query to see if there is a StaticPage/GeneralComment related to the acs_message_revision) -- but none of them are very object-oriented. I mean an acs_message_revision should really NOT be expected to know about all possible object types that might refer to it in the future and account for them.
So that brings me to the bigger question of what is the "right" way to use the acs_objects and acs_object_types to do this? I'm afraid to create a general-comments object type for fear it might break something in the acs-messaging or content-repository (some code that looks at object types to provide some service that already works with these types).
