Christian Scholz wrote:
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.
Well, the message template stuff is really a small part of the bigger
messaging system. I agree we should organize it in some better way, but
I'm not sure if that means a message_template folder or something else.
I think we don't have enough understanding of what we are really going
to need. Maybe renaming data would be a good temporary fix, but
something to keep in mind is what else might come along that is related
(maybe we should be looking into this as well).
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.
I don't mind using a pre-defined coding standard. As long as we all
agree. BTW - what is a package in Python? Sorry, I'm trying to get the
Python lingo down. I'll start to follow those standards, and if we
decide to go with something else I'll change stuff over.
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.
I'm not sure what you mean by this. The code I'm writing, the parsing
code, isn't serialization. It is just building the packet (so, the
SomePacket() aspect of it). So yes, I think we do need some way to
serialize packets, but it seems we are confusing something (the building
of the packet vs the serialization of it). This makes me think we should
really outline the packet procedures, that is, the parsing,
building/creating, reading, sending and serializing, what types of
messages we are going to need and why we may need different types of
serialization.
This is the type of conversation we've been needing in Pyogp! wOOt!
Hopefully we can start to get an idea of the overall goals of the
project and break it down so we know exactly what components we need.
I'm going to send out a task list as I currently see it soon.
Thanks!
Lock (fyi, due to the complexity of my name, feel free to call me Lock.
It's my gamer name anyway :) )
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp
