How to know precisely when the revision of a content item is released?

Question

Hi,
I have written a filter to handle delete event of content item revisions. Whenever a revision of a data file (WCM data file) is deleted my filter gets triggered and and checks for some criteria on our meta data. When the criteria is met it has to compare the contents of the revision that is deleted with the new revision. Since the revision will be deleted when my filter is exited, I copied the contents of the revision that is deleted and invoked a java thread with required document information.
In that thread I am checking for when the revision is successfully deleted so that I can read the contents of new revision and compare them with old revision.
For that I calling DOC_INFO_BY_NAME service from my thread and am checking until the following values for below meta data are in effect
dStatus=RELEASED
dReleaseState=Y
Unfortunately this is not working properly. I am still seeing the data file content of deleted revision only. For testing purpose I put a sleep of 10 seconds in my code instead of reading the meta data values which is making the code work as expected. I am to get the contents on new revisions after the sleep time. But I don't want to work this way as this is not a guaranteed mechanism.
How to know for sure when the revision is released?
Regards,
Pratap

Answer 1

Hope as you mentioned I would be able to use link manager. That would make my work much simpler. But just want to ensure that we both are on the same page relating to my requirements. I still feel there is some gap in what I have tried to explain and what you understood. May be I couldn't put it in simple words.
I will try my best to explain the requirements again in a simpler manner. This is only to ensure that I wouldn't end up spending lot of time in understanding new stuff but only to relaize at later time it may not work for me. I haven't used Link Manager before. That is why I am speculating a bit. I will start looking into the documentation of the Link Manager and Related Content to checkout if they work for me.
First thing is that the links are not just present in static lists. They can also be in content generated using WYSIWYG editors and Image elements.
Second when I talked about HTMLs they are not true content items. We are generating these HTMLs based on the structure of the site studio data file that is checked-in. I think it would be more clear if I add more details here.
The data files that I have been referring so far are bit complex. Our site studio contibution site allows creation of parent content items like detailed page, news articles etc and child items like RelatedSections, FAQ Items etc. The child items are referenced in the parent content items for organizing the parent content item's structure. All these site studio content items are XML files and each of them can internally contain links to other items. In fact the child items can have references to parents items or other childd items as static list (with link selector elements) and WYSIWYG editors are used while creating these content types (parent and child items).
Finally we generate the HTML only for parent items and display them on our portal. Child references are used only for defining parent item structure and the generated HTML for the parent item contains the details of child items. Our differentiation of parent and child is in the context. HTMLs that I have been talking so far are these ones only. They are not real content items.
The HTML will be generated when ever the parent item is updated and approved in the last step in our workflow. Now since parent item's HTML is dependent on child items, whenever a child item is updated and approved in the last step of workflow we should look up for all the parent items that are referring to this child and regenerate the HTML for those parent items using updated contents of this child.
Similar logic of HTML regeneration should be applied in the delete events.
Finally the revision related issues that I listed for data files apply for images as well. Since the images are also managed content items with multiple revisions they are maintained in site studio content items with their dDocName instead of its file file path and extension. Lets say an image is being referred in one of the parent content items and the image extension at the time it was initially used in the parent item is gif. The HTML contents for this parent that get generated will have gif extension for this image item. Now after some time if the user checks-in a new revision for this image item and lets say the extension now is png. But the HTML generated for the parent item is still having .gif in the img src attribute. Which means we need to re-generate the HTML in this case by checking where all this image item is referred.
If link manager can be helpful in meeting the above requirements it would be great. It shouldn't matter if there is bit of customization work involved.
Regards,
Pratap