[Opensim-dev] [Proposal] New software architecture

[Justin Clark-Casey]

Melanie wrote:
> 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.

The issue isn't about the client actively trying to infer things, it's about unexpected effects in calling code because 
different things are happening internally in different situations.

> 
>> 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.

Fair enough.

> 
>> 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.

Okay.

> 
>> 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.
> 

As far as I'm concerned, this point and the previous two are perfectly reasonable, as long as this behavior is 
documented on the interfaces so that the caller doesn't need to dig around in specific implementations to work out what 
the contract is.

>> 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.

I'm happy to add the right syntax after the fact, as long as documentation for non-obvious methods is there in the first 
place.  It's when this doesn't exist that the situation becomes difficult.

-- 
justincc
Justin Clark-Casey
http://justincc.wordpress.com