[tigerstripe-dev] Storing annotations...

[Andrey Platov <andrey@xxxxxxxxx>]

Hi folks,

While post http://dev.eclipse.org/mhonarc/lists/tigerstripe-dev/msg00124.html describes current approach to avoid adapters conflict and selecting right object to annotate, I'd like to address usage issues raised by Steve http://dev.eclipse.org/mhonarc/lists/tigerstripe-dev/msg00116.html and discuss how we would store annotations and navigate through annotations and annotable objects.

Current approach to store annotations is simple as following:

1) Current

Any existing EMF object can be used as an annotaion, "glue" is EAnnotation object, which is used to associate annotation with annotable object via URI, and the picture is: 

//associate annotable and annotation
class EAnnotation { 
  uri: String; //reference to annotable object
  annotation: EObject; //pointer to annotation
}

2) Alternatively we may consider to extend from EAnnotation, like

class StereotypeAnnotation extends EAnnotation {
  String stereotype;
}

Comparing this approaches it looks like (1) is somewhat flexible and allow us to (re)use virtually any EMF class as an annotation, since there are no requirements on annotation class from TAF standpoint, at same time approach (2) is effective in terms of memory usage for small annotation objects (e.g. consist of fileds of trivial types).

For end-user (developer) point of view, as Steve mentioned, approach (2) is more convenient, but it is not so flexible as (1).

*** EObjects instead of URIs

Replacing URIs with EObjects looks attractive, so we may have:

3) 

class EAnotation {
  annotable: EObject;
  annotation: EObject;
}

or even

4) 

class Stereotype {
  entity: ETigerstripeEntity;
}

This approach looks very good and easy from implementation standpoint if annotable objects are initially EMF-based. But if we'd like to annotate any POJO and use default EMF naviagation/persistency to walk from EAnnotation to "virtual" EObject representing POJO, things become very tricky [I'd be happy to ellaborate if someone interested]. 

So the question is how much we're interested in having (3) and (4) at TAF level? Probably it would be easy to request additional data about annotable POJO (returned by TAF) inlcuding type, attributes, etc on higher levels?

Please share your thoughts.

Kind Regards,
Andrey