[Pyogp] Updates: Small changes and an Agent Domain

[Christian Scholz]

Hi!

As you might have seen I checked in some code. Here it was it is:

- I added the high level API I did to my grokified branch. This also
involved adding a new class called Avatar. An avatar holds the region it
is in and the region again holds the details it gets from the
place_avatar cap. When you move to another region the region in the
avatar is supposed to change. It also holds a reference to it's Agent (I
think at least, need to check again but it should)

- I renamed IPlaceAvatarAdapter to just IPlaceAvatar. I thought that
makes more sense.

- I made the IPlaceAvatar adapter now adapt to IAgentDomain and not to
IAgent which IMHO makes more sense aswell as it's the agent domain on
which we make the call, not the agent.


Then I checked in the work on my agent domain implementation, at least
the part I did on the library side. What's missing is the actual
application using this stuff. It's work in progress right now so it does
not work, mainly caused by not being able to call Linden Lab's regions.

I will now continue (someday) with it and will use OpenSim.

I will also checkin the example application but will do that to the
Plone collective repository. I will send a note to this list once this
is done with some explanation on how it is done. The main point here was
though to keep application and library as separate as possible and the
library part not depend on the application part. What I did in Plone was
mainly adding views for login, seedcap and place_avatar which then call
the library part and return whatever needs to be returned.
Of course user handling is completely up to the application and it needs
to implement an adapter which will log the user in (or maybe not). This
adapter is then called from the login() method of the library.

You can find the whole package at

http://svn.secondlife.com/svn/linden/projects/2008/pyogp/pyogp.lib.agentdomain

and the login method in particular in the __init__.py:

http://svn.secondlife.com/svn/linden/projects/2008/pyogp/pyogp.lib.agentdomain/trunk/pyogp/lib/agentdomain/__init__.py

I might provide another buildout which installs Plone, the OGP product I
am creating for it and the agentdomain library part. I need this for
further development anyway.

-- Christian

[Locklainn]

Hey Tao,
I don't see your checked in code. Are you committing to the sl repo?

Tasks I think we have outlined:
oDetermine if grok should be used
o Decide which test framework to use for the test harness -
PyUnit/unittest, doctest, pytest (we have currently decided to let the
writer of the tests to decide which framework to use...)
o Are we doing a class-based model or a method-based model? In other
words, is the client lib functionality encapsulated into classes or kept
as independent (no side-effect) methods?
o Clean up the wiki - what exactly needs to be done?

Post by Christian Scholz
Hi!
- I added the high level API I did to my grokified branch. This also
involved adding a new class called Avatar. An avatar holds the region
it is in and the region again holds the details it gets from the
place_avatar cap. When you move to another region the region in the
avatar is supposed to change. It also holds a reference to it's Agent
(I think at least, need to check again but it should)
- I renamed IPlaceAvatarAdapter to just IPlaceAvatar. I thought that
makes more sense.
- I made the IPlaceAvatar adapter now adapt to IAgentDomain and not to
IAgent which IMHO makes more sense aswell as it's the agent domain on
which we make the call, not the agent.
Then I checked in the work on my agent domain implementation, at least
the part I did on the library side. What's missing is the actual
application using this stuff. It's work in progress right now so it
does not work, mainly caused by not being able to call Linden Lab's
regions.
I will now continue (someday) with it and will use OpenSim.
I will also checkin the example application but will do that to the
Plone collective repository. I will send a note to this list once this
is done with some explanation on how it is done. The main point here
was though to keep application and library as separate as possible and
the library part not depend on the application part. What I did in
Plone was mainly adding views for login, seedcap and place_avatar
which then call the library part and return whatever needs to be
returned.
Of course user handling is completely up to the application and it
needs to implement an adapter which will log the user in (or maybe
not). This adapter is then called from the login() method of the library.
You can find the whole package at
http://svn.secondlife.com/svn/linden/projects/2008/pyogp/pyogp.lib.agentdomain
http://svn.secondlife.com/svn/linden/projects/2008/pyogp/pyogp.lib.agentdomain/trunk/pyogp/lib/agentdomain/__init__.py
I might provide another buildout which installs Plone, the OGP product
I am creating for it and the agentdomain library part. I need this for
further development anyway.
-- Christian

[Timothy Loughlin (Locklainn Linden)]

Hello,
I have made some changes to the message template code I've been working on:

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.

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.

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

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

[Christian Scholz]

Hi!
Very cool! :-)

Post by Timothy Loughlin (Locklainn Linden)
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.

Post by Timothy Loughlin (Locklainn Linden)
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.

Post by Timothy Loughlin (Locklainn Linden)
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.

Post by Timothy Loughlin (Locklainn Linden)
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

[Lock'a Mail]

Post by Christian Scholz
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).

Post by Christian Scholz
I also see some mix of naming conventions and I wonder if we should
http://www.python.org/dev/peps/pep-0008/
- 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.

Post by Christian Scholz
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.
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 :) )

[Christian Scholz]

Hi!

Post by Lock'a Mail

Post by Christian Scholz
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 ;-)

Post by Lock'a Mail

Post by Christian Scholz
I also see some mix of naming conventions and I wonder if we should
http://www.python.org/dev/peps/pep-0008/
- 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.

Post by Lock'a Mail

Post by Christian Scholz
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.
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):

"""

Post by Lock'a Mail

Post by Christian Scholz

from msg_tmpl import generate_template
msgtmpl = generate_template() # read and parse the message template
packet = msgtmpl.create_packet('SomePacketNameOrNumber')

And we can serialize it for putting it into a UDP packet

Post by Lock'a Mail

Post by Christian Scholz

serializer = ISerialization(packet)
packet_data = serializer.serialize()

The above could be wrapped in a convenience function or method of the
packet.

Post by Lock'a Mail

Post by Christian Scholz

packet_data = get_from_udp_pipe() # this will look differently
deserializer = getUtility(IDeserializer,'udp_packet')
packet = deserializer.deserialize(packet_data)
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 ;-)

Post by Lock'a Mail
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 ;-)

Post by Lock'a Mail
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.

Post by Lock'a Mail
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