Thanks Christian. These were the questions I had. About putting
serialize directly into MsgData, I'm actually going to put it in the
packet builder. It makes more sense. You would only want to serialize
something when you are building it to be sent. Likewise, the deserialize
will go into the reader. I guess the builder and readers are adapters
then (and maybe should implement the ISerialization interface at some
point).
I have some related questions too. For the most part of the client lib,
it seems we should have standard objects, meaning we won't need them to
be swappable. It seems like it would be a good idea to identify the
aspects of the client lib that we would like to be swappable (and so
make them use zca) and the ones that we don't need to be swappable (and
so don't use zca for these). I feel that we have and are going to have a
lot of 1 to 1 interface to implementation, which is just more
abstraction for no reason (arguably, of course). Is this something
people would like to discuss? That is, which parts of the lib should be
swappable?
Lock
Christian Scholz wrote:
Hi!
So Locklainn wanted to create a serialization component for his
message builder. What the message builder spits out is a MsgData
instance which needs to be serialized. A MsgData instance is a generic
class which handles all types of packets (you can add blocks and data
etc.).
In order to create an adapter it would need some interface. It makes
sense to call it IMessageData (or IMsgData) and put the methods into
it which the class actually defines.
Then you would write an adapter which implements ISerialization. As
you should see from interfaces.py you need to implement 2 things. A
serialize() method and a content_type attribute (this is more used for
HTTP traffic though, not sure if that really is needed in the UDP case
but I guess we can let it return application/llpacket or something
dummy like this).
This should be straightforward like it has been done in credentials.py.
Now what this gives us is that we can exchange the serializer in our
application if we want to. What we cannot exchange though is the
implementation for IMsgData unless we also exchange the class which
spits these out. And this was Locklainn's question if I get this right.
So the question indeed is what the advantage is or if you can make it
work so that you can also just exchange the MsgData implementation.
In fact you can if you use some factory pattern here and register
IMsgData as a utility (each class is actually a factory because if you
call it it returns an instance):
class MsgData(object):
implement(IMsgData)
provideUtility(MsgData)
You can then use it like this:
msgdata = getUtility(IMsgData)()
(at least this should work, haven't tested it yet).
Then you can replace this as well in your code.
The main question is though if we need all this in here and I think we
don't. Probably nobody wants to change the implementation and if so we
maybe can refactor it like this at that point in time.
Regarding serialization we also probably don't need it. For HTTP
request it makes sense because there is still the option to use JSON.
For UDP packets though there is not really an alternative format we
can use.
That being said I would propose that you implement serialize()
directly in the MsgData (when you do that you can actually still add
the implements(ISerialization) to MsgData because then this directly
is the adapter for itself).
good night,
Christian
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp
