Hi!
Lock'a Mail wrote:
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).
Yes, makes sense. I think the most important part is also to have good
test coverage of everything so we can refactor easily. I doubt that we
will do everything right in the first pass ;-)
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.
A package is basically a directory, a module is a file.
pyogp.lib.base is a package with a namespace (and this is why we need
this nested directory structure) and it can contain subpackages, like
msg_tmpl might be one. So these can be nested.
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.
Yes, I know, this was maybe the wrong place to mention it ;-) I indeed
was talking about handling the actual data coming in from some region
(and sending it to).
Maybe we should really write some example down on how the individual
parts can be used. Like (not following your code here as I would need to
look it up but just take it as some example):
"""
Create a message template representation:
>>> from msg_tmpl import generate_template
>>> msgtmpl = generate_template() # read and parse the message template
Now we can use it for creating a new packet:
>>> packet = msgtmpl.create_packet('SomePacketNameOrNumber')
And we can serialize it for putting it into a UDP packet
>>> serializer = ISerialization(packet)
>>> packet_data = serializer.serialize()
The above could be wrapped in a convenience function or method of the
packet.
We can also deserialize a packet:
>>> packet_data = get_from_udp_pipe() # this will look differently
>>> deserializer = getUtility(IDeserializer,'udp_packet')
>>> packet = deserializer.deserialize(packet_data)
Now we can have a look at the header:
>>> header = packet.header
>>> header.type_
13
And the body:
no idea how we model this yet, probably some access to blocks etc.
"""
So much for my example in form of a doctest. Not sure it makes sense ;-)
This is the type of conversation we've been needing in Pyogp! wOOt!
Yes! :-) So far communication is quite good I would say.. although I
hope to also get down to do some programming again ;-)
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.
yes.
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 :) )
Ok, great :-) I will try to code something later, should I find some
time. For now it's late lunch time.
-- 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
