|
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 Thanks, Sam From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hugh Perkins New idea!!! Ok, just taken a look at the snapshot version of libsecondlife and it's
got a directory called Packets, which is an abstraction layer to create each
outgoing packet. It's essentially the Rpc layer, since what's coming into this layer is
a plain old C# function call (eg Communication.ImprovedInstantMessage( ...,
targetagentid, ..., message, ... ) ), and what's coming out is a network
packet, albeit not actually serialized onto the wire, at least not just yet :-)
What could be ideal is a way of taking these function calls and
*automatically* serializing them to Packet, and (possibly) writing them
directly to the wire. Reflection makes the parameters of the method available
to us! so we know the details about what we want to send. We could do something like: public static Packet ImprovedInstantMessage(ProtocolManager
protocol, LLUUID targetAgentID, return new
BinaryMarshaller().MarshallThisCallToBinary( protocol, new object[]{
targetAgentID, myAgentID, parentEstateID, regionID, position, offline, ... ); } Somewhat simpler, but kindof a chore to have to populate the object[]
array. We can do better than that using Reflection.Emit. Reflection.Emit
lets us create classes on the fly, with the code to populate object[] array
populated for us automatically! We can cache the generated classes so we only need to generate each
class once. Using Reflection.Emit lets us do the following: In Communication: class Communication { public Packet ImprovedInstantMessage(ProtocolManager
protocol, LLUUID targetAgentID, return null; } } Yes that really does just return null! Its just a
placeholder. The Reflection.Emit will handle this by creating a derived
class that does the real work. We can store the derived class in a
standard Communication variable, and call the methods directly and easily! Communication communication = outgoingbinaryrpc.CreateProxy(
Communication ) as Communication; Packet packet = communication.ImprovedInstantMessage( protocol,
targetAgentID, myAgentID, parentEstateID, ... ); Quite easy to use right? What we've done is essentially to create a transparent proxy
that transparently and automatically generates our network packet for
us! It would be trivial to in fact add the logic to additionally
automatically fire this packet across the network! On 7/16/06, Hugh
Perkins <[EMAIL PROTECTED]>
wrote: Christopher, > One thing though: if we do go with the former, what happens when
there are two fields with the same name in different blocks? Christopher, that's a good point. There's no obvious clean way to
do that though there's various less clean ways. To what extent does this
situation arise? If this is something that arises significantly maybe the second option
is better? On 7/16/06, Christopher Omega < [EMAIL PROTECTED]> wrote: I personally would
graitate to the former. Not needing to know what block a particular field
belongs to seems to me more like a good thing. One thing though: if we do
go with the former, what happens when there are two fields with the same name
in different blocks? On 7/15/06, Hugh
Perkins <
[EMAIL PROTECTED]> wrote:
_______________________________________________
|
_______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev
