Vincent and John,
> Your ideas are very much welcome. However, I would bet that
> .Net-specific functionality such as Reflection.Emit is just one of
> many new technologies that everyone has not had the time to fully
> investigate and embrace. Your proposals would probably be better
> accepted if you could write up a brief indicating the benefits and
> pitfalls of such an approach and what would be required to maintain
> the code. If the developers were to implement code they did not fully
> understand and you were to disappear, it would just be wasted time as
> they would end up ripping all of it out later. In short, make a sales
> pitch. J
> .Net-specific functionality such as Reflection.Emit is just one of
> many new technologies that everyone has not had the time to fully
> investigate and embrace. Your proposals would probably be better
> accepted if you could write up a brief indicating the benefits and
> pitfalls of such an approach and what would be required to maintain
> the code. If the developers were to implement code they did not fully
> understand and you were to disappear, it would just be wasted time as
> they would end up ripping all of it out later. In short, make a sales
> pitch. J
Well, that was my sales pitch :-)))) I do understand what you are saying which is why I'm not just requesting write access to SVN and patching things directly; I want to give the opportunity for some discussion beforehand. However, I'm a technical person so my communications is primarily limited to code samples ;-)
I guess I can try to explain using more English and less code, but it's not really my strong-point ;-)
Communications between the SecondLife client and server are essentially a type of rpc, albeit one-way and asynchronous. I admit to not knowing whether an async one-way rpc is still classified semantically as rpc, but the key point is that they can be modelled as a standard C# function call:
void InstantMessage( LLUUID TargetAgentID, string message, ... );
These function calls will always return void, since all data is outgoing, and return immediately, since they are asynchronous, but they're nevertheless function calls.
This function call declaration, together with the information in protocol.txt, gives enough information to create a network packet, a technique called Marshalling, and send it to the server.
We can write the code manually to marshall the packet and send it to the server. Initially, with just a few packet types, this is absolutely viable and the best approach. However as the number of packet types increases it encounters scalability issues:
- it takes a lot of time
- it's difficult to maintain
- there's a lot of scope for errors and long hours spent debugging
Writing the marshalling code automatically is a standard approach to this problem and significantly (orders of magnitude...) reduces time spent coding and debugging the rpc layer.
Marshalling code can be written using a code generator - the Corba and Ice approach - or can be generated on the fly using Reflection - the .Net Remoting approach. Both approaches are valid.
Code generator approaches require the creation of interface files, which is a lot better than manually generating code, and allows cross-language portability, but breaks the illusion of transparence.
Reflection-based approaches tend to be easy to use and achieve excellent transparence, since everything appears as a simple native-language function call.
To summarize the advantages of automatically generating marshalling code:
- easy to write each function call
- highly transparent and easy to read
- "just works"
_______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev
