Re: Attempt for an UNO Undo API

Hi Andrew,

>   Although I am ignorant in much of this, I do have some random thoughts.

appreciated, as always :)

> Mathias Bauer mentioned allowing the container to control changes for 
> some items (such as he did with notes2), but that this may be a problem 
> with larger objects such as graphics objects and even OLE objects. On 
> the other hand, I do not expect that an OLE object will have any ability 
> to actively participate in the undo process, which forces implementation 
> back to the container (or you simply state that changes made to an OLE 
> object internally are not undoable). For some reason, I keep thinking 
> about the implications of a linked sheet in a Calc document.

I have no final opinion on this at the moment. I think we'll come back
to the topic in "version 2.0" of the API, when we exemplarily (will have
to) solve this for charts embedded in Calc.

> There was also talk of throwing multiple types of exceptions when an 
> error occurs. Does this prevent some languages (such as Basic, Perl, and 
> similar) from participating in this scheme?

No. Throwing (read: allowing to throw) multiple exceptions is nothing
unusual in the UNO API, so those language bindings will have as little
(or as much - not sure, for instance, how/if throwing UNO exceptions
works there) problems as with any other UNO API.

> Can/will the undo API affect extensions?

I hope so :)
Extensions doing multiple changes in a row are one major scenario to be
addressed by the API (see my original mail in the thread).

> Any thoughts on database actions? It does not seem reasonable that a SQL 
> statement will participate, even for an internal Base document, this 
> could be a very long running transaction.

I don't think that it makes sense to implement this for databases. In
Base, "Undo" is not even present at the UI (if we talk about data
changes - it well exists in UI components such as the
query/table/forms/reports designers), so there's nothing the API
implementation could be based on, at the moment.

Ciao
Frank

-- 
ORACLE
Frank Schönheit | Software Engineer | [email protected]
Oracle Office Productivity: http://www.oracle.com/office