Hi!
I have made some changes to the message template code I've been working on:
Very cool! :-)
1. Transformed the code into a message template parser
- changed the file name to message_template_parser
- put the code that previously made a dict into a class called
MessageTemplateParser
2. Transformed the previously called "Packet" code into MessageTemplate
code (considering each message in the message_template.msg to be a
Message Template)
- renamed Packet to MessageTemplate, PacketBlock to
MessageTemplateBlock, and PacketVariable to MessageTemplateVariable
- extracted all the header information for each particular message
template and its blocks and put it into the object's fields
3. Nicer formatted printing of the Parsed message template. If you run
bin\packets you will see the message_template.msg reprinting from the
parser all perty-like.
Some remarks: Should we maybe put all the message_template related stuff
into one directory? Maybe we can rename data to message_template and put
everything in there. Would IMHO make the package more understandable.
I also see some mix of naming conventions and I wonder if we should use
the standard python naming conventions as defined in PEP8:
http://www.python.org/dev/peps/pep-0008/
Basically that means for naming:
- module names should be lowercase without underscores (and not too long)
- package names should be lowercase, underscores it it helps readability
- class names are CamelCase, no underscores
- function and method names are lowercase and underscores for readability
There is much more in there according to indentation and we maybe all
should read it.
Using this would have the benefit of not needing to write down our own
coding style and other developers should be already familiar with it.
I also would check my code for things which need change then.
Next to do:
1. Store the size of the block variables, not just their type NAMES. We
need this to read and build messages. This should be done at template
parsing time and not when building our reading.
One idea might be to use the same serialization/deserialization pattern
as for everything else, just that those packets will serialize into
those UDP packets instead of LLSD.
The pattern basically is to use an adapter like this:
packet = SomePacket()
serializer = ISerialization(packet)
return serializer.serialize()
Then the actual parser code would be pluggable and we can write a method
which encapsulates these calls (probably in some main handler) to save
some lines of code.
2. Create MessageReader
- Move over the functionality in message_template.py into this class
(such as decodeNum, decodeFrequency)
- Use size stored in block variables to read from a buffer and store
it into the variable
3. Create MessageBuilder
- Move over functionality in message_template.py into this class
(such as encodeHeader)
- Use the size stored in the block variables to write data into the
variable buffer
These basically could be those adapters.
4. Write Message classes that mimic the Message Template classes, but
will be used to actually create a packet (probably later on, not soon)
- eg: MessageData, MessageBlockData, MessageVariableData
5. Write tests for all the newly created classes
Shouldn't this be step 0? ;-)
But looks great so far, looking forward to actually use it :-)
-- Christian
--
Christian Scholz video blog: http://comlounge.tv
COM.lounge blog: http://mrtopf.de/blog
Luetticher Strasse 10 Skype: HerrTopf
52064 Aachen Homepage: http://comlounge.net
Tel: +49 241 400 730 0 E-Mail [EMAIL PROTECTED]
Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T
neue Show: TOPFtäglich (http://mrtopf.de/blog/category/topf-taglich/)
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp
