Opentalk communication

> remoteData sceneAdd: (CSVisualizationAddresses new
> visualizeAddressAtX: numX y: numY z: 0).
>
> remoteVisual reDraw: remoteData
> ******************
> During client operations data is aquired and then passed as shown
> before.
> The problem:
> first time I use remoteData and remoteVisual all is fine, a viewfinder
> windows appears and the first chunk of data is drawn on the server side,
> but after that I receive a series of OtETimeout exception and even if I
> catch them nothing more happens in the server side (there is a test in
> method reDraw: and it do not receives messages after exceptions).

> Christian Ponti wrote:
> > remoteData sceneAdd: (CSVisualizationAddresses new
> > visualizeAddressAtX: numX y: numY z: 0).
> >
> > remoteVisual reDraw: remoteData
> > ******************
> > During client operations data is aquired and then passed as shown
> > before.
> > The problem:
> > first time I use remoteData and remoteVisual all is fine, a viewfinder
> > windows appears and the first chunk of data is drawn on the server side,
> > but after that I receive a series of OtETimeout exception and even if I
> > catch them nothing more happens in the server side (there is a test in
> > method reDraw: and it do not receives messages after exceptions).
>
> I don't know what's wrong, but a few tips on how to find out.
>
> 1) The 'server' broker runs your requests in background 'worker' processes (by default a new one for each request). In general any error raised in your code that is not handled by your code will be caught and suppressed (generating a remote error response if possible). If you want to see these errors try playing with #passErrors/#suppressErrors (used on broker instances) which control the error suppression.
>
> 2) Often to be able to find the problematic area to focus on, the only way to get a good picture of what's going on is a complete log of the remote interactions. Brokers signal lots of events for various stages of remote message processing that you can subscribe to using the usual triggerEvent APIs. For starters try 'broker sendAllEventsTo: EventPrinter new'. You should get a pretty detailed log of what's going on printed in the Transcript. You can subcribe to specific events only as well, if you want to trim down the amount of output. Look at the implementation of #sendAllEventsTo: to get an idea how.
>
> 3) With remote objects the tricky part is managing their location. In you example, unless you took some precautions, your addresses objects is most likely on the client side and the server has to access it remotely. Due to the high level of messaging transparency, that may still work (resulting in lots of remote messages flying back and forth), but some operations may not work remotely. Maybe at some point you end up trying to invoke a primitive on a remote graphics context or something such, which is very unlikely to work. So the point is, you need to manage the location of your objecs, make sure they are on the right side of the network divide. For this you need use the object passing mechanisms properly, making sure which objects are passed by reference and which by value and when. There's a chapter on this in the documentation as well.
>
> This sounds like an interesting Opentalk application, btw. Can you provide more details ?
>
> Good luck!
>
> Martin