[ 
https://issues.apache.org/jira/browse/UIMA-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15605866#comment-15605866
 ] 

Marshall Schor commented on UIMA-5106:
--------------------------------------

# re: getting a blessed id feature that all FSs would inherit: I wasn't 
thinking of users adding a new feature on TOP or Annotation - you are correct 
in observing that this would be restricted to some user-defined type which 
wasn't one of the built-in "feature-final" types.  A key idea is that only 
selected types would have this - the ones you wanted it for.

# re: users wanting their own stable IDs - they can manage this themselves.  
True, but the dev list has had requests for UIMA to help here.  There were 2 
kinds of help wanted:  
#* a) assigning unique ids, and 
#* b) having a way to go from those IDs to the associated Feature Structures (a 
map).  

As we move into more distributed environments, having some principled way to 
have a hierarchical naming that results in guaranteed unique names seems 
useful; this context is where the OID idea came up.  But you may be right - 
this may not be of very much interest (yet) to the wider community.  (Community 
- if this is wrong, please speak up :-) ).

> uv3 constant "id" for FSs (Proposed new Feature for uv3)
> --------------------------------------------------------
>
>                 Key: UIMA-5106
>                 URL: https://issues.apache.org/jira/browse/UIMA-5106
>             Project: UIMA
>          Issue Type: New Feature
>          Components: Core Java Framework
>            Reporter: Marshall Schor
>            Priority: Minor
>             Fix For: 3.0.0SDKexp
>
>
> Add constant ID for FSs. This would be an incrementing, long value. It would 
> be constant through serialization/ deserialization cycles. There would be a 
> lazily created map from longs to FSs (via weak links) to allow direct access 
> from the ID to the FS.  Lazy intent is to not have a cost for this 
> (space/time) other than the cost for 1 long / FS, if it is not used.
> We could make this feature optional, as well, to avoid the 8 bytes per FS 
> overhead, but in V3, I think that's not a good tradeoff (space savings vs 
> complexity).  
> Issues: 
> * Current design allows parallelism of services, with returned results 
> "stacked" into receiving CAS; would need to change (some of) the IDs coming 
> back.
> CAS would need to have the high-water-mark value as part of serializations.
> Backwards compatibility:
> * loading V2 CASs: generate new IDs upon loading.
> * serializing to V2: (for connecting to V2 services): drop the IDs.
> This is a proposed new V3 feature; comments appreciated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to