Arguments not wrapped in local proxies in EventDispatchers::invoke and Operation return results
michaelelfial opened this issue · comments
Now that complex isolation is achieved with local proxies for LocalAPI and services provided by apps, the client (an app asking for API or service provided by another through AppGate and LocalAPI) does not get a direct reference, but a proxy that transfer the calls to the server. If the server fires some events they are also wrapped, but their arguments (specified by the server) are not wrapped. This means that through events the subscribed clients can obtain direct access to some server objects if the server sends them as arguments when firing the event (e.g. someevent.invoke(this, someobject) - both this and someobject will travel naked to the handler of the client.).
Up until now we never sent objects through service fired events and I suppose we can avoid that for the near future. So, the release will not be delayed because of this, but any code that relies on this "nakedness" will stop working in the next versions - have this in mind.
It is an interesting question how to wrap the arguments in this case - to use the client app's container this wrapping has to occur in components that really should know about it. This means that if we want the EventDispatcher to do this, we will have to create a ProxyDispatcher class especially for the purpose and advise it for the app's local proxy container from the proxy in which it is a proxy member for the original event. This is doable, but there are some points to consider - for instance as the events may fire many times, one and the same object will come to the handler many times as argument. The proxy containers have the ability to deal with that and aggregate multiple equivalent proxies into one, but I wonder if this is Ok in the case of events. The more worrying question is another - fine we deal with that, but having references to objects held in the container, possibly until the client app's shutdown may be a bad thing - what if these objects are short lived and should be released after quick use? Container does not prevent this, but may tempt people to "forget" to release the arguments even when they know that this is important - having all the auto-release provided by the container may prevent obvious bad results for a long time and stimulate the developers to neglect this for too long....
See #13 for details on how this was resolved.