I’m trying to understand how the annotations are generated, saved and loaded within GroupDocs.
Let me explain how this suppose to work and how it works in all other annotation tools.
Other I mean Brava, Daeaja ViewOne Pro, Acrobat, Acrobat plugins, PDF Annotation Services. Basically all that tools are used with the ECM systems like Documentum, Alfresco, Oracle Web Center, Sharepoint. All those tools use I’d say a standard way to store the annotations. That means that every annotation/stamp/watermark is a single object that can be saved or exported in different format (XML, FDF, XFDF) depending on the tool. Plus can be easily converted from one to another. Anyway, such an object contains all the annotation definition plus owner name and creation date. That’s it. It’s either linked with the document via a relation (ECM system) or embedded like in PDF where it an be exported/imported as FDF or XFDF.
Perfect and simple solution.
Document <–> Relation (who, when) <–> Annotation
Withing GroupDocs I can see a completely diffent approach/model that I’m not able to understand.
There is an annotation that has to reference a session?? and userId??. Session is volatile by definition so I can’t understand how a session ID can be saved with the annotation. User ID is also GD specific whether it all other system UserId is actually a String that can be used and understood by other systems.Then there is ID and GUID. Not sure why there are two identifiers for a single object.
Then there is a Reply, another objects that references the annotation and has also two identifiers and userId reference.
To sum up, two or more objects per annotations containing references to internal GD objects.
In other words - no way to save the annotation within the ECM system, is that correct?
I’d need a way to combine the annotation with all the replies into some single XML file. That’s doable I guess, although with two different DAOs that handle those objects separately it might be quite complicated.
Anyway, let’s assume that I’m able to store the annotation with the replies as a single file that can be stored within the ECM system. I loose ID, annotationSessionID, userId, GUID as those parameters are irrelevant. Within the ECM system I have a document with that related annotation and some metadata that identifies who and when created it.
That’s the expected output that allows the data to be migrated to another ECM system or another repository within the same system (very common situation).
Now I need a way to read it back to the GD format. And… I don’t see a way to do it. How to populate annotationSessionID that requires a session which requires a document with INT identifier. How to populate ID, GUID and userId. How to populate all those relations on the fly when there are seven different DAOs depending one on another. It looks like I should copy over the ECM database, which includes millions of documents and tens of millions of annotations into the GD internal database and keep that synchronized. Otherwise, literally, there is no way to make that work together.
I encourage you to take a look at the existing ECM systems, because that’s your target. There are millions of people working with it using the annotation tools every day. GroupDocs seem a great alternative to them. But unfortunately I don’t see a way to make that work together.
We’ve been trying to do the integration for half a year now. Each version fixed a dozen of bugs and introduced a bunch of new bugs. Nevertheless, I hope that at some point it will be amazing tool.
Unfortunately I reached the point when I don’t see a light in a tunnel. The connector design and approach seems so unreasonable that I don’t think there is any way to make that work in real world.
Keep in mind that I represent 500k+ of potential users.
Please let me know if there is anything that you plan to change or anything that we can do to do the ECM integration.