[Opensim-dev] [Proposal] New software architecture

[Melanie]

Hi,

Justin Clark-Casey wrote:
> 3.  Are the details of the protocol between client and server side really invisible to the service clients?  The awkward 
> case here is between local 'in process' and remote servers, I think.  For instance, on IAssetService there is a method

It is not impossible for a client that knows how to infer internal 
workings from observable behavior to determine which connector it's 
talking to. However, doing this would be bad practice.

> 
> Get(string id, Object sender, AssetRetrieved handler)
> 
> Afaik, if the asset service is local then the asset is returned via the same thread to the AssetRetrieved handler (i.e. 
> synchronously).  If the asset service is remote, then the asset is returned asynchronously to the nominated handler 
> method on a different thread.  This is not fully invisible.

A synchronous method is needed. It may block, even for extended 
periods and the caller needs to make sure there is no contention. 
The amount of time spent in the method is undefined.

> 
> This could be a problem if the caller does a lot of work using the handler thread.  If the service is synchronous, then 
> the caller thread may be used for this where the caller did not expect it.
> 

As in .NET async, the request will run on the caller's thread if it 
completes synchronously, or on a threadpool thread if not.
Where it actually runs is not defined and the caller must be 
prepared for both scenarios.

> 4.  In particular on IAssetService, there appears to be a purely synchronous get methods, e.g.
> 
> AssetBase Get(string id);
> 
> I know these also existed in the past, but are they a good idea in a world where the callers are not meant to know 
> whether the underlying service is local or remote?  I know practically they may be needed (at least in the old code, the 
> underlying call simply timed out and returned null if the asset wasn't retrieved in a hard coded amount of time). 
> Again, this is a difference between in-process servers (which will return immediately) and remote ones (which could 
> delay up to 10 secs).
> 

They are needed and the caller must be prepared to block.

> 5.  At the very least, interfaces need proper documentation if the caller is not meant to have to know what is happening 
> inside.  This documentation needs to be in the proper XML style so that it shows up in generated documentation.
> 

That style can't be easily generated with my tools (vi). I don't use 
an IDE. Anyone is free to add it, even though it looks ugly in pure 
code view, but I can't.

Melanie