Method events as currently defined in 126.96.36.199 (RC17) are IMO under-specified.
there are several open issues with the current specification:
- sequence of state change and method events is unclear (issue# 462)
- getMethodInfo issues (issue# 461)
binary/stream method arguments are problematic (at best) and put
a heavy burden on an implementation; e.g. on import an implementation
would need to spool the contents of a (potentially very large) xml
stream beforehand in order to make it available to the *IMPORT method
event. similar issues exist with the SET_PROPERTY method event.
- there's no method event for Session/Workspace#getImportContentHandler;
it's unclear how SAX events could be represented in the current method
- CHANGE_MIXINS method event: unclear how this maps to the Node.addMixin and
.removeMixin methods; what are the parameters? should probably be replaced
with separate method events, e.g. ADD_MIXIN & REMOVE_MIXIN
- granularity of (transient) method events is unclear: is an application allowed
to consolidate method events? e.g. consider the following method calls:
how many method events would be generated by each of the above examples?
this is just a random list of issues i found, there are probably more than those
in the light of the issues with the current method event design i'd like to raise
the question whether we really need method events. what are the use cases requiring
method events? IIRC the most important use case is detecting move operations.
are there more? detecting move operations could IMO be handled by the observation/event
userdata feature. it would shift the responsibility to the application, but is this