You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Bhavani Iyer <bh...@gmail.com> on 2008/08/26 03:00:27 UTC
Proposed API for CAS Journaling
Please review the intiial proposal for extending the CAS interface to
support journaling posted on the wiki:
http://cwiki.apache.org/confluence/display/UIMA/APIs+for+CAS+Journaling
- Bhavani
Re: Proposed API for CAS Journaling
Posted by Tong Fin <to...@gmail.com>.
As I said, the Joern's use-case is at the application level. There is more
room to add supports. But, we need to put more code in the application side
(not in the UIMA framework). When I said keeping info in CAS, I mean that I
rely on the UIMA framework to provide API to do de/serialization and access
the CAS content. So, what I can do with the CAS is limited. And, it will not
be true when we do something at the tool/application level.
Since we are talking about doing something at the tool/application level,
there is another approach that I can think about (not sure how hard it is).
The beauty of UIMA is that its xmiCAS can be read by Ecore (EMF) and there
are some codes in the UIMA framework to support that. We may use UIMA+EMF to
support "modification history" for "editing" since Ecore has a good support
for "changes". (Just my thinking)
On Tue, Aug 26, 2008 at 4:18 PM, Thilo Goetz <tw...@gmx.de> wrote:
> It's not directly supported, but don't you think it could help
> in such an application? You would still need to keep the full
> intermediate CASes around, but the journal would be very helpful
> in determining where changes happened. The actual difference
> for display could be computed on the fly. So full CAS + journal
> and you've got most of the way to a CAS diff between versions, no?
>
> --Thilo
>
> Tong Fin wrote:
> > In short answer, it is not possible since the context of creating CAS
> > Journal that we are proposing is different from your use-case.
> >
> > In the current design, we try to minimize the overhead in the UIMA
> framework
> > and less modification to the code. We keep track the changes "by each
> > analysis engine" and we don't (at least now) preserve the intermediate
> > values of changes to the same feature structure. For example, if the
> feature
> > structure "abc" is changed by AE1 and then by AE2, we only keep the
> value
> > after AE2 modification. Other point that I should mention is that, since
> the
> > CAS content is kept and is managed by UIMA framework, there are some
> > limitations about the information that we would like to "add" and "keep"
> > during running UIMA "pipeline" (without major modification to the UIMA
> > framework). We are doing journaling at "runtime".
> >
> > Your use-case is more at the application level and it is more flexible on
> > how we remember the "history". Maybe, there is other way on how to save
> the
> > history (not just in the CAS).
> >
> > On Tue, Aug 26, 2008 at 3:35 PM, Jörn Kottmann <ko...@gmail.com>
> wrote:
> >
> >> Does "revision" mean change between runs or between operations ?
> >>> If it is, the current "proposed" format does not cover this use-case
> >>> because
> >>> there are issues on how to represent "intermediate" values of feature
> >>> structures for example.
> >>>
> >> A user opens a CAS in the editor and do changes to the CAS then he
> >> saves the editor and the changes are written to file. Each time he does
> >> this I would like to keep a revision like the history in eclipse.
> >>
> >> Would this be possible ?
> >>
> >> Jörn
> >
> >
> >
> >
>
>
--
Tong
Re: Proposed API for CAS Journaling
Posted by Thilo Goetz <tw...@gmx.de>.
It's not directly supported, but don't you think it could help
in such an application? You would still need to keep the full
intermediate CASes around, but the journal would be very helpful
in determining where changes happened. The actual difference
for display could be computed on the fly. So full CAS + journal
and you've got most of the way to a CAS diff between versions, no?
--Thilo
Tong Fin wrote:
> In short answer, it is not possible since the context of creating CAS
> Journal that we are proposing is different from your use-case.
>
> In the current design, we try to minimize the overhead in the UIMA framework
> and less modification to the code. We keep track the changes "by each
> analysis engine" and we don't (at least now) preserve the intermediate
> values of changes to the same feature structure. For example, if the feature
> structure "abc" is changed by AE1 and then by AE2, we only keep the value
> after AE2 modification. Other point that I should mention is that, since the
> CAS content is kept and is managed by UIMA framework, there are some
> limitations about the information that we would like to "add" and "keep"
> during running UIMA "pipeline" (without major modification to the UIMA
> framework). We are doing journaling at "runtime".
>
> Your use-case is more at the application level and it is more flexible on
> how we remember the "history". Maybe, there is other way on how to save the
> history (not just in the CAS).
>
> On Tue, Aug 26, 2008 at 3:35 PM, Jörn Kottmann <ko...@gmail.com> wrote:
>
>> Does "revision" mean change between runs or between operations ?
>>> If it is, the current "proposed" format does not cover this use-case
>>> because
>>> there are issues on how to represent "intermediate" values of feature
>>> structures for example.
>>>
>> A user opens a CAS in the editor and do changes to the CAS then he
>> saves the editor and the changes are written to file. Each time he does
>> this I would like to keep a revision like the history in eclipse.
>>
>> Would this be possible ?
>>
>> Jörn
>
>
>
>
Re: Proposed API for CAS Journaling
Posted by Tong Fin <to...@gmail.com>.
In short answer, it is not possible since the context of creating CAS
Journal that we are proposing is different from your use-case.
In the current design, we try to minimize the overhead in the UIMA framework
and less modification to the code. We keep track the changes "by each
analysis engine" and we don't (at least now) preserve the intermediate
values of changes to the same feature structure. For example, if the feature
structure "abc" is changed by AE1 and then by AE2, we only keep the value
after AE2 modification. Other point that I should mention is that, since the
CAS content is kept and is managed by UIMA framework, there are some
limitations about the information that we would like to "add" and "keep"
during running UIMA "pipeline" (without major modification to the UIMA
framework). We are doing journaling at "runtime".
Your use-case is more at the application level and it is more flexible on
how we remember the "history". Maybe, there is other way on how to save the
history (not just in the CAS).
On Tue, Aug 26, 2008 at 3:35 PM, Jörn Kottmann <ko...@gmail.com> wrote:
> Does "revision" mean change between runs or between operations ?
>> If it is, the current "proposed" format does not cover this use-case
>> because
>> there are issues on how to represent "intermediate" values of feature
>> structures for example.
>>
>
> A user opens a CAS in the editor and do changes to the CAS then he
> saves the editor and the changes are written to file. Each time he does
> this I would like to keep a revision like the history in eclipse.
>
> Would this be possible ?
>
> Jörn
--
-- Tong
Re: Proposed API for CAS Journaling
Posted by Jörn Kottmann <ko...@gmail.com>.
> Does "revision" mean change between runs or between operations ?
> If it is, the current "proposed" format does not cover this use-case
> because
> there are issues on how to represent "intermediate" values of feature
> structures for example.
A user opens a CAS in the editor and do changes to the CAS then he
saves the editor and the changes are written to file. Each time he does
this I would like to keep a revision like the history in eclipse.
Would this be possible ?
Jörn
Re: Proposed API for CAS Journaling
Posted by Tong Fin <to...@gmail.com>.
On Tue, Aug 26, 2008 at 3:15 PM, Jörn Kottmann <ko...@gmail.com> wrote:
> Please review the intiial proposal for extending the CAS interface to
>> support journaling posted on the wiki:
>> http://cwiki.apache.org/confluence/display/UIMA/APIs+for+CAS+Journaling
>>
>
> For debugging a time stamp of the jornal could be useful.
>
> Could the journal also be used by the Cas Editor to store older
> revisions in one cas file ?
>
> Jörn
Does "revision" mean change between runs or between operations ?
If it is, the current "proposed" format does not cover this use-case because
there are issues on how to represent "intermediate" values of feature
structures for example.
If we can come out with a useful use-case, we may extend the current CAS
Journaling to support that (if the current implementation of UIMA permits).
-- Tong
Re: Proposed API for CAS Journaling
Posted by Jörn Kottmann <ko...@gmail.com>.
> Please review the intiial proposal for extending the CAS interface to
> support journaling posted on the wiki:
> http://cwiki.apache.org/confluence/display/UIMA/APIs+for+CAS
> +Journaling
For debugging a time stamp of the jornal could be useful.
Could the journal also be used by the Cas Editor to store older
revisions in one cas file ?
Jörn
Re: Proposed API for CAS Journaling
Posted by Bhavani Iyer <bh...@gmail.com>.
On Tue, Aug 26, 2008 at 4:19 PM, Marshall Schor <ms...@schor.com> wrote:
>
>
> Bhavani Iyer wrote:
> > On Tue, Aug 26, 2008 at 1:42 PM, Thilo Goetz <tw...@gmx.de> wrote:
> >
> >
> >> Bhavani Iyer wrote:
> >>
> >>> On Tue, Aug 26, 2008 at 4:28 AM, Thilo Goetz <tw...@gmx.de> wrote:
> >>>
> >>>
> >>>> -1 to returning internal CAS handles as FS IDs. That's asking for
> >>>> trouble. Why would you want to do that? You're forcing the user
> >>>> to deal with low-level CAS APIs.
> >>>>
> >>>>
> >>> How about if an iterator is returned from which FeatureStructure
> >>>
> >> objects
> >>
> >>> can be
> >>> retrieved ?
> >>>
> >> Or an array, I don't care. Just not meaningless ints.
> >>
> >
> >
> > OK.Will update the interface spec in the wiki.
> >
> I don't quite follow how changing this to an iterator will "work". Is
> there some assumption about the order the iterator will return feature
> structures - so that if a feature structure is returned as the "nth"
> item for one Journal, it is guaranteed that the same feature structure
> is returned as the "nth" item from all Journals (if they have at least
> "n" items)? If this is an intended property, we should state this, I
> think.
>
Basically, the Journal object contains the log of CAS operations done by
a particular component
which is independent of the Journal of another component that updated the
same CAS.
The iterator interface was proposed as an alternative to creating and
returning an array of FeatureStructure
objects. Since the operations are logged in the order they occurred, the
order in which the FSs, are returned
by the iterator will perserve the order for a specific type of operation
(e.g. new, modify, indexadd ...) done by
a particular component.
> -Marshall
> >
> >>
> >>>
> >>>> I have a strong preference for making journaling a global option
> >>>> that's set on the framework, not on the CAS. We should have all
> >>>> these options in one place so they're easy to find and document.
> >>>>
> >>> The intention was to make journaling dynamic and when journaling is
> >>>
> >> off
> >>
> >>> there is no
> >>> overhead. A service needs to be able to turn journaling on/off per
> >>> client request. A
> >>> global setting would mean that the service has to be stopped and
> >>>
> >> restarted
> >>
> >>> to change the setting
> >>> which would be painful.
> >>>
> >> If you say so. Just as long as an annotator can't turn it on.
> >>
> >>
> >
> > Absolutely. An annotator will not be able to turn it on.
> >
> >
> >
> >>> - Bhavani
> >>>
> >>>
> >>
> >
> >
>
Re: Proposed API for CAS Journaling
Posted by Marshall Schor <ms...@schor.com>.
Bhavani Iyer wrote:
> On Tue, Aug 26, 2008 at 1:42 PM, Thilo Goetz <tw...@gmx.de> wrote:
>
>
>> Bhavani Iyer wrote:
>>
>>> On Tue, Aug 26, 2008 at 4:28 AM, Thilo Goetz <tw...@gmx.de> wrote:
>>>
>>>
>>>> -1 to returning internal CAS handles as FS IDs. That's asking for
>>>> trouble. Why would you want to do that? You're forcing the user
>>>> to deal with low-level CAS APIs.
>>>>
>>>>
>>> How about if an iterator is returned from which FeatureStructure
>>>
>> objects
>>
>>> can be
>>> retrieved ?
>>>
>> Or an array, I don't care. Just not meaningless ints.
>>
>
>
> OK.Will update the interface spec in the wiki.
>
I don't quite follow how changing this to an iterator will "work". Is
there some assumption about the order the iterator will return feature
structures - so that if a feature structure is returned as the "nth"
item for one Journal, it is guaranteed that the same feature structure
is returned as the "nth" item from all Journals (if they have at least
"n" items)? If this is an intended property, we should state this, I think.
-Marshall
>
>>
>>>
>>>> I have a strong preference for making journaling a global option
>>>> that's set on the framework, not on the CAS. We should have all
>>>> these options in one place so they're easy to find and document.
>>>>
>>> The intention was to make journaling dynamic and when journaling is
>>>
>> off
>>
>>> there is no
>>> overhead. A service needs to be able to turn journaling on/off per
>>> client request. A
>>> global setting would mean that the service has to be stopped and
>>>
>> restarted
>>
>>> to change the setting
>>> which would be painful.
>>>
>> If you say so. Just as long as an annotator can't turn it on.
>>
>>
>
> Absolutely. An annotator will not be able to turn it on.
>
>
>
>>> - Bhavani
>>>
>>>
>>
>
>
Re: Proposed API for CAS Journaling
Posted by Bhavani Iyer <bh...@gmail.com>.
On Tue, Aug 26, 2008 at 1:42 PM, Thilo Goetz <tw...@gmx.de> wrote:
> Bhavani Iyer wrote:
> > On Tue, Aug 26, 2008 at 4:28 AM, Thilo Goetz <tw...@gmx.de> wrote:
> >
> >> -1 to returning internal CAS handles as FS IDs. That's asking for
> >> trouble. Why would you want to do that? You're forcing the user
> >> to deal with low-level CAS APIs.
> >>
> >
> > How about if an iterator is returned from which FeatureStructure
> objects
> > can be
> > retrieved ?
>
> Or an array, I don't care. Just not meaningless ints.
OK.Will update the interface spec in the wiki.
>
>
> >
> >
> >> I have a strong preference for making journaling a global option
> >> that's set on the framework, not on the CAS. We should have all
> >> these options in one place so they're easy to find and document.
> >
> >
> > The intention was to make journaling dynamic and when journaling is
> off
> > there is no
> > overhead. A service needs to be able to turn journaling on/off per
> > client request. A
> > global setting would mean that the service has to be stopped and
> restarted
> > to change the setting
> > which would be painful.
>
> If you say so. Just as long as an annotator can't turn it on.
>
Absolutely. An annotator will not be able to turn it on.
>
> >
> > - Bhavani
> >
>
>
Re: Proposed API for CAS Journaling
Posted by Thilo Goetz <tw...@gmx.de>.
Bhavani Iyer wrote:
> On Tue, Aug 26, 2008 at 4:28 AM, Thilo Goetz <tw...@gmx.de> wrote:
>
>> -1 to returning internal CAS handles as FS IDs. That's asking for
>> trouble. Why would you want to do that? You're forcing the user
>> to deal with low-level CAS APIs.
>>
>
> How about if an iterator is returned from which FeatureStructure objects
> can be
> retrieved ?
Or an array, I don't care. Just not meaningless ints.
>
>
>> I have a strong preference for making journaling a global option
>> that's set on the framework, not on the CAS. We should have all
>> these options in one place so they're easy to find and document.
>
>
> The intention was to make journaling dynamic and when journaling is off
> there is no
> overhead. A service needs to be able to turn journaling on/off per
> client request. A
> global setting would mean that the service has to be stopped and restarted
> to change the setting
> which would be painful.
If you say so. Just as long as an annotator can't turn it on.
>
> - Bhavani
>
Re: Proposed API for CAS Journaling
Posted by Bhavani Iyer <bh...@gmail.com>.
On Tue, Aug 26, 2008 at 4:28 AM, Thilo Goetz <tw...@gmx.de> wrote:
> -1 to returning internal CAS handles as FS IDs. That's asking for
> trouble. Why would you want to do that? You're forcing the user
> to deal with low-level CAS APIs.
>
How about if an iterator is returned from which FeatureStructure objects
can be
retrieved ?
>
> I have a strong preference for making journaling a global option
> that's set on the framework, not on the CAS. We should have all
> these options in one place so they're easy to find and document.
The intention was to make journaling dynamic and when journaling is off
there is no
overhead. A service needs to be able to turn journaling on/off per
client request. A
global setting would mean that the service has to be stopped and restarted
to change the setting
which would be painful.
- Bhavani
Re: Proposed API for CAS Journaling
Posted by Tong Fin <to...@gmail.com>.
That is a good information !
I think we will let the tool (outside UIMA framework) to create a
user-friendly ID by itself. The UIMA framework will not create/provide any
unique ID for each FS.
On Tue, Aug 26, 2008 at 4:13 PM, Marshall Schor <ms...@schor.com> wrote:
>
>
> Adam Lally wrote:
> >> With the proposed change to return an Iterator instead of an array
> of
> >> ints, you
> >> can get a reference to a FeatureStructure object and then call the
> >> method hashCode()
> >> to get the id.
> >>
> >>
> >
> > I would not recommend relying on a hash code being a unique
> > identifier. There's no guarantee that that will always be the case.
> > If the UI needs a unique integer for its own purpose it could generate
> > its own and use a Map from FeatureStructure to integer to keep track.
> >
> More background on using the current internal feature structure id:
>
> Eddie reminded me that remote delegates connected via Vinci do *not*
> preserve ids. So if a CAS went to a remote service using Vinci, when it
> came back, these ids would not be the same.
>
> So, in general, using the internal feature structure ID is not going to
> work with our current implementation, at least, in cases where Vinci is
> used.
>
> -Marshall
> > -Adam
> >
> >
> >
>
--
Tong
Re: Proposed API for CAS Journaling
Posted by Marshall Schor <ms...@schor.com>.
Adam Lally wrote:
>> With the proposed change to return an Iterator instead of an array of
>> ints, you
>> can get a reference to a FeatureStructure object and then call the
>> method hashCode()
>> to get the id.
>>
>>
>
> I would not recommend relying on a hash code being a unique
> identifier. There's no guarantee that that will always be the case.
> If the UI needs a unique integer for its own purpose it could generate
> its own and use a Map from FeatureStructure to integer to keep track.
>
More background on using the current internal feature structure id:
Eddie reminded me that remote delegates connected via Vinci do *not*
preserve ids. So if a CAS went to a remote service using Vinci, when it
came back, these ids would not be the same.
So, in general, using the internal feature structure ID is not going to
work with our current implementation, at least, in cases where Vinci is
used.
-Marshall
> -Adam
>
>
>
Re: Proposed API for CAS Journaling
Posted by Tong Fin <to...@gmail.com>.
On Tue, Aug 26, 2008 at 2:53 PM, Adam Lally <al...@alum.rpi.edu> wrote:
> > With the proposed change to return an Iterator instead of an array of
> > ints, you
> > can get a reference to a FeatureStructure object and then call the
> > method hashCode()
> > to get the id.
> >
>
> I would not recommend relying on a hash code being a unique
> identifier. There's no guarantee that that will always be the case.
> If the UI needs a unique integer for its own purpose it could generate
> its own and use a Map from FeatureStructure to integer to keep track.
>
I agree with Adam. The UI will not use a 20-digit, for example, to show to
the user !
The tool will use it own scheme that is best for end-user.
BTW, the proposed change to return an Iterator of FS is OK with me.
-- Tong
Re: Proposed API for CAS Journaling
Posted by Adam Lally <al...@alum.rpi.edu>.
> With the proposed change to return an Iterator instead of an array of
> ints, you
> can get a reference to a FeatureStructure object and then call the
> method hashCode()
> to get the id.
>
I would not recommend relying on a hash code being a unique
identifier. There's no guarantee that that will always be the case.
If the UI needs a unique integer for its own purpose it could generate
its own and use a Map from FeatureStructure to integer to keep track.
-Adam
Re: Proposed API for CAS Journaling
Posted by Bhavani Iyer <bh...@gmail.com>.
On Tue, Aug 26, 2008 at 1:49 PM, Tong Fin <to...@gmail.com> wrote:
> The goal is to allow user to see the "changed history of each feature
> structure".
> For example, the Fig 3.5 in the proposed GUI posted in Wiki
>
> http://cwiki.apache.org/UIMA/cas-viewer-extension-for-provenance-tracking-of-uima-cas-content.html
> show that the FS (of RoomNumber type) with id=61 is created by RoomNumber
> AE
> and is modified by Meeting AE.
> (hope that the link works !).
>
> To implement the about UI, one way is to use the ID to identify the FS.
> This
> ID can be created by the tool (outside of UIMA) or by the UIMA. I don't
> mind
> where we implement that ID as long as the tool has a consistent way to
> create the ID.
>
> If we have other option to do that other than using ID to identify each FS,
> it is fine with me too.
With the proposed change to return an Iterator instead of an array of
ints, you
can get a reference to a FeatureStructure object and then call the
method hashCode()
to get the id.
>
> On Tue, Aug 26, 2008 at 1:28 PM, Thilo Goetz <tw...@gmx.de> wrote:
>
> > Tong Fin wrote:
> > > Just to clarify...
> >
> > Sorry, but this didn't really clarify anything for me. What's wrong
> > with just returning an array of FS objects?
> >
> > >
> > > My comment means that I suggest to have a new API to get FS from ID and
> > not
> > > to use the existing Low-level API. This ID is not related to any
> > > implementation that we have or know about.
> > >
> > > On Tue, Aug 26, 2008 at 12:22 PM, Tong Fin <to...@gmail.com> wrote:
> > >
> > >> -1 to returning internal CAS handles as FS IDs. That's asking for
> > >>> trouble. Why would you want to do that? You're forcing the user
> > >>> to deal with low-level CAS APIs.
> > >>>
> > >> I think this FS ID is required by the tool to show the modification
> > history
> > >> of a FS. For example, FS with id=10 is created by AE1 and is modified
> by
> > >> AE2, etc.. How we implement this FS ID is hidden from the tool and it
> > can be
> > >> generated or get from some where.
> > >>
> > >> -- Tong
> > >>
> > >
> > >
> > >
> >
> >
>
>
> --
> -- Tong
>
Re: Proposed API for CAS Journaling
Posted by Tong Fin <to...@gmail.com>.
The goal is to allow user to see the "changed history of each feature
structure".
For example, the Fig 3.5 in the proposed GUI posted in Wiki
http://cwiki.apache.org/UIMA/cas-viewer-extension-for-provenance-tracking-of-uima-cas-content.html
show that the FS (of RoomNumber type) with id=61 is created by RoomNumber AE
and is modified by Meeting AE.
(hope that the link works !).
To implement the about UI, one way is to use the ID to identify the FS. This
ID can be created by the tool (outside of UIMA) or by the UIMA. I don't mind
where we implement that ID as long as the tool has a consistent way to
create the ID.
If we have other option to do that other than using ID to identify each FS,
it is fine with me too.
On Tue, Aug 26, 2008 at 1:28 PM, Thilo Goetz <tw...@gmx.de> wrote:
> Tong Fin wrote:
> > Just to clarify...
>
> Sorry, but this didn't really clarify anything for me. What's wrong
> with just returning an array of FS objects?
>
> >
> > My comment means that I suggest to have a new API to get FS from ID and
> not
> > to use the existing Low-level API. This ID is not related to any
> > implementation that we have or know about.
> >
> > On Tue, Aug 26, 2008 at 12:22 PM, Tong Fin <to...@gmail.com> wrote:
> >
> >> -1 to returning internal CAS handles as FS IDs. That's asking for
> >>> trouble. Why would you want to do that? You're forcing the user
> >>> to deal with low-level CAS APIs.
> >>>
> >> I think this FS ID is required by the tool to show the modification
> history
> >> of a FS. For example, FS with id=10 is created by AE1 and is modified by
> >> AE2, etc.. How we implement this FS ID is hidden from the tool and it
> can be
> >> generated or get from some where.
> >>
> >> -- Tong
> >>
> >
> >
> >
>
>
--
-- Tong
Re: Proposed API for CAS Journaling
Posted by Thilo Goetz <tw...@gmx.de>.
Tong Fin wrote:
> Just to clarify...
Sorry, but this didn't really clarify anything for me. What's wrong
with just returning an array of FS objects?
>
> My comment means that I suggest to have a new API to get FS from ID and not
> to use the existing Low-level API. This ID is not related to any
> implementation that we have or know about.
>
> On Tue, Aug 26, 2008 at 12:22 PM, Tong Fin <to...@gmail.com> wrote:
>
>> -1 to returning internal CAS handles as FS IDs. That's asking for
>>> trouble. Why would you want to do that? You're forcing the user
>>> to deal with low-level CAS APIs.
>>>
>> I think this FS ID is required by the tool to show the modification history
>> of a FS. For example, FS with id=10 is created by AE1 and is modified by
>> AE2, etc.. How we implement this FS ID is hidden from the tool and it can be
>> generated or get from some where.
>>
>> -- Tong
>>
>
>
>
Re: Proposed API for CAS Journaling
Posted by Tong Fin <to...@gmail.com>.
Just to clarify...
My comment means that I suggest to have a new API to get FS from ID and not
to use the existing Low-level API. This ID is not related to any
implementation that we have or know about.
On Tue, Aug 26, 2008 at 12:22 PM, Tong Fin <to...@gmail.com> wrote:
>
> -1 to returning internal CAS handles as FS IDs. That's asking for
>> trouble. Why would you want to do that? You're forcing the user
>> to deal with low-level CAS APIs.
>>
> I think this FS ID is required by the tool to show the modification history
> of a FS. For example, FS with id=10 is created by AE1 and is modified by
> AE2, etc.. How we implement this FS ID is hidden from the tool and it can be
> generated or get from some where.
>
> -- Tong
>
--
-- Tong
Re: Proposed API for CAS Journaling
Posted by Tong Fin <to...@gmail.com>.
> -1 to returning internal CAS handles as FS IDs. That's asking for
> trouble. Why would you want to do that? You're forcing the user
> to deal with low-level CAS APIs.
>
I think this FS ID is required by the tool to show the modification history
of a FS. For example, FS with id=10 is created by AE1 and is modified by
AE2, etc.. How we implement this FS ID is hidden from the tool and it can be
generated or get from some where.
-- Tong
Re: Proposed API for CAS Journaling
Posted by Thilo Goetz <tw...@gmx.de>.
Bhavani Iyer wrote:
> Please review the intiial proposal for extending the CAS interface to
> support journaling posted on the wiki:
> http://cwiki.apache.org/confluence/display/UIMA/APIs+for+CAS+Journaling
>
> - Bhavani
>
-1 to returning internal CAS handles as FS IDs. That's asking for
trouble. Why would you want to do that? You're forcing the user
to deal with low-level CAS APIs.
I have a strong preference for making journaling a global option
that's set on the framework, not on the CAS. We should have all
these options in one place so they're easy to find and document.
--Thilo