Difference between revisions of "PyOGP Client Library"

From Second Life Wiki
Jump to navigation Jump to search
(Formatting repair)
 
(116 intermediate revisions by 10 users not shown)
Line 1: Line 1:
This page is dedicated to the client library aspect of the Pyogp project. The more general page is [[Pyogp]].
{{PyOGP/navigation}}
== Overview ==
== Intro ==
The longer term vision of the Pyogp project is essentially to create a client library, capable of navigating the grid and interacting with the various hosts, sitting next to a testing framework, happily running along telling us what works where, and where something needs a little attention to work according to specification...
In the long, long run, the Client lib could be used as the basis for a [[Use_Cases#Limited_Capability_Clients|lightweight client]] written in Python.
==Objectives==
On the wiki page [[Protocol]], there is a list of all the protocols that SL currently uses. We plan on implementing any and every protocol we can. We want the client library to have as much functionality as possible, keeping in mind that it is lightweight. However, we would like to prioritize the features we implement. Pyogp should be a client for both the Legacy protocols and OGP protocols, as they become implemented. Currently, the priority list is:
#Login
#Establish/maintain presence
#Parse the data sent via the communication channels (event queue/UDP)
#Start building out functionality in the client
<br>
It seems there is some desire to have the client be usable from a command line for such things as IM, checking friends online, viewing inventory, etc.


== Tasks==
PyOGP is a young, open source, python client library which provides an interface to an agent (client) of a Second Life grid. The code aims to enable automated testing of Second Life grids, to encourage and enable exploration into the client/server relationship and related protocols of Second Life, and to make possible simple prototyping of various client applications.
Task list for the client library. These may get PJIRA tasks someday, or some other format we decide upon.
#Start looking over and learning [[Eventlet]] most of the other documentation listed on this page
#Decide whether to [http://docs.python.org/lib/module-doctest.html doctest] or not to doctest. We are certainly planning to use [http://docs.python.org/lib/module-unittest.html unittest]
#Develop requirements specification - let's first get an idea of what it is, exactly, that we want to build
#*Requirements
#*[[Use_Cases#Limited_Capability_Clients|Use Cases]] - these might help to identify how the lib might be used by someone. We should look at these and determine which of the use cases we want to implement.
#*Identify target audience and the corresponding limitations - this project is not meant solely for Linden Lab, so we should identify who could use it and how they may use it
#Design the structure of the code according to the spec
#*Taking into consideration some of the following:
#**Must work for both Legacy and OGP (any Login or other protocols must be interfaced so to be implemented by Legacy or OGP)
#**Flexibility to allow different ways to communicate between the client and server (e.g. either eventlet, urllib2, etc.)
#Implement the design
#*Determine how to distribute the code so nobody's toes hurt and no elbows bumped


Tasks that have been recently completed:
Hosted on svn.secondlife.com, it does require a contributor's agreement for commit access, and currently has a few contributors from the Second Life open source community.
#*Determine whether to [http://www.muthukadan.net/docs/zca.html ZCA] or not to ZCA - ZCA enables flexibility via modularity with a component based framework. The intent would be to incorporate this into the library, while the test harness bits would remain 'stock' python. Tao Takashi will extend his initial attempt at this one for AWG and LL to review early next week.
#*Decide whether or not to incorporate [http://pypi.python.org/pypi/zc.buildout/1.0.0b30 buildout]


== Components (and supporting environmental details)==
P.S. We'll likely be moving to hg relatively soon...
These are the currently envisioned components.
#Login
#*The beta grid has an agent domain login accessible at https://login1.aditi.lindenlab.com/cgi-bin/auth.cgi
#*Parameters = firstname, lastname, password (or md5-password as '$1$' + md5-hash)
#*Regionuri list (log into the agent domain running on aditi, show up on vaak!). Use the regionuri parameter in viewers built from http://svn.secondlife.com/trac/linden/browser/branches/agent-domain-2
#*Note: people working with the agentd suggest trying one of 12035, 13000, 13001, and 13002. They say at LEAST 2 will work.
#*#http://sim1.vaak.lindenlab.com:13000    Dore
#*#http://sim1.vaak.lindenlab.com:13001    Card
#*#http://sim1.vaak.lindenlab.com:13002    Grigiano
#*#http://sim1.vaak.lindenlab.com:12035    Island for Misfit Toys
#*#http://sim2.vaak.lindenlab.com:12035    Ahern
#*#http://sim2.vaak.lindenlab.com:13000    Miramare
#*#http://sim2.vaak.lindenlab.com:13001    Morris
#Capabilities (and while it's around, the UDP pipe)
#Message Handlers for the event queue(see chttp, [[SLGOGP_Draft_1#Event_Queues]])
#*Current way this is handled is by having the client have a non-ported web server running in the viewer which handles the messages by parsing URLs in a local manner
#Basic web server parts for the Agent, Region and grid bits (ideally a snap in framework)


* mailing list: pyogp@lists.secondlife.com
* irc: irc://irc.freenode.com/#pyogp
* wiki: http://wiki.secondlife.com/wiki/Pyogp
* licensing: Apache 2.0 license, copyright Linden Lab


== Status ==
=== Goals ===
*[https://svn.secondlife.com/svn/linden/projects/2008/pyogp/ Current Pyogp Repo] - svn repo of the most up-to-date code we are using for the project
*[[Current_Sim_Capabilities]] - capabilities that are currently used
*[http://pysecondlife.googlecode.com/svn/pyogp/pyogp.lib.base/trunk: Tao Takashi's Pyogp] - svn repo - Tao Takashi has hit the ground running with an experimental framework which has been made available [http://code.google.com/p/pysecondlife/ here].
**Read more at his blogpost describing the start of his work at his very long [http://mrtopf.de/blog/secondlife/worldofsl/setting-up-a-framework-for-a-python-implementation-of-the-open-grid-protocol-technical url].
*[[Presence_Code_Python| Sai's Presence]] and [[Presence_Code_Python_cmd_line| Sai's Presence_cmd_line]] - Saijanai Kuhn's first attempts at some Python presence
*[https://svn.secondlife.com/svn/linden/projects/2008/pyogp_old/ Linden Pyogp] - svn repo of Linden's first stab at framework, using Sai's code as a base
**[https://svn.secondlife.com/svn/linden/projects/2008/pyogp_old/examples/pyogp.lib-login.py pyogp.lib-login.py] - sample script which logs into aditi's agent domain and establishes a presence on a simulator on vaak:
**Disclaimer*: Everything in the repo now will change dramatically in the next few weeks as things firm up structure wise. My desires for the work include: a simple, well defined library, a separate test framework (unittest, the initial high level code to be added this week), an samples/examples sandbox, and clean well commented code. That said, none of the above are in place now. They will be. More sophisticated implementations can evolve over time, or can be included on the side of the library...
*[[Example_protocol_code]] - code written about login and presence
* [http://zhaewry.wordpress.com/2008/06/05/happy-jumpy-ruths-interop-takes-a-step/ Interop Ruths] - some news that may be of interest to us
<br>
* [[Pyogp/Protocols]] - here's a listing of the protocols that we may implement, and the implementation details about them as well.


== Documentation ==
In the very near future, we can have tests available to be run as soon as a deploy is completed that exercise a simulator/grid in the same way we do a smoke test. We will use these as automated tests run at build time, post deploy validation, and regression testing of simulators and backend systems.
*[[AWG_Test_Harness_Intro]]
* [[Pyogp/Client_Lib/Notes]] - notes that may help understand the rest
<br>
* Current Protocols
** [[Current_login_protocols]] - what login is like now
* OGP Protocols
** [[SLGOGP_Draft_1]] - the outline of the OGP protocols
** [[OGP_Draft_Login|OGP Draft Login flowchart]] - flowchart for current OGP login protocols
** [[SLGOGP_Teleport_Strawman]] - what login may be like
** [[Second_Life_Login_API_Strawman]] - what login may be like
** [[OGP_Draft_Login]] - diagrams of the OGP login
* General Notes
** [[Second_Life_Grid_Protocols/Foundation]] - general protocol information
** [[Protocol]] - this is general information about messaging and the various protocol systems
** [http://en.wikipedia.org/wiki/Comet_(programming) COMET programming]
** [[Eventlet]] - a networking library written in Python, probably going to be used for this project
***NOTE: We have been testing eventlet and it seems there's a problem posting to the seed capability.
****[[Pyogp_Client_Lib/Login_Test_Script]] - a very simple test script using eventlet that fails at the post to the seed cap
***Windows Instructions - Eventlet for Windows is a bit tricky to install
****[[User:Baba_Yamamoto/Eventlet]] - there are some problems with eventlet that Baba has looked into
****greenlet - you MUST have Visual Studio 2003 installed to install greenlet on windows (are there binary versions?). Use easy_install greenlet to install it.
****pyOpenSSl - windows versions
*****[http://webcleaner.sourceforge.net/pyOpenSSL-0.6.win32-py2.4.exe pyOpenSSL py2.4] - windows pyOpenSSL for Python 2.4
*****[http://webcleaner.sourceforge.net/pyOpenSSL-0.6.win32-py2.5.exe pyOpenSSL py2.5] - windows pyOpenSSL for Python 2.5
****util.py - has a dependency on fcntl. Go into eventlet's util.py, and either comment out all the fcntl calls, or for a slightly (not a good fix) better solution, [https://lists.secondlife.com/pipermail/sldev/2007-September/004790.html Donovan's Fix]


** [[Circuit]] - the way to pass two-way information along a UDP connection
This provides early feedback on code quality. QA is then able to dive deeper in testing the changes specific to a branch.  
** [[Message]] - more detail of messages
** [[Reverse_HTTP]] - I believe this is used (or will be) in the OGP protocols
** [http://www.libsecondlife.org/wiki/Protocol_%28network%29 General Packet Format] - libsecondlife - describes what the general format is for a packet
** [http://www.libsecondlife.org/wiki/ACK ACKs] - libsecondlife - describes what an ACK is
* Coding notes
** [http://www.muthukadan.net/docs/zca.html ZCA Guide] - ZCA that the lib project will be using
* Python Docs
** [http://www.python.org/doc/current/lib/module-distutils.html DistUtils] -
*** [http://www.python.org/community/sigs/current/distutils-sig/ Sig for utils]
** [http://peak.telecommunity.com/DevCenter/PythonEggs Python Eggs] -
*** [http://peak.telecommunity.com/DevCenter/setuptools setuptools] - lib to handle eggs


== Licensing ==
Having this library available also allows us to test potential changes before we have finalized design and are ready to submit to QA. Not sure how something will play out? Try it, and test it with PyOGP....
# The code written as part of this effort is subject to the Apache v2 license. Read more at http://opensource.org/licenses/apache2.0.php.


  <excerpt>
=== A Brief History ===
  Copyright 2008, Linden Research, Inc.
  <br>
  Licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at
  <br>
  http://www.apache.org/licenses/LICENSE-2.0
  <br>
  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
  </excerpt>


PyOGP was originally created as a tool for testing [[OGP]] related changes to the Second Life grid. By the end of the summer in 2008, the '''pyogp.lib.base''' package provided a skeleton messaging system and was able to test Linden Lab's first implementation of an agent domain and the related changes in an agent's region handoff and teleport. As the development effort around OGP waned, we started to extend pyogp by adding higher level client related functionality. Recently, this functionality was split out into a separate python package ('''pyogp.lib.client'''), and sample scripts (and future apps) were moved into '''pyogp.apps'''.


== Architecture Overview==
=== Structure ===
PyOGP is comprised of three python packages. The library consists of pyogp.lib.base and pyogp.lib.client, while sample scripts, and in time applications, live in pyogp.apps.
:'''pyogp.lib.base''' - consists of basic networking, messaging systems (UDP and event queue) and capabilities, custom datatypes, and a low level message related event system
:'''pyogp.lib.client''' - consists of 'convenience' classes mapping methods and handlers to specific messages (e.g. Agent().say(msg) tells the client to send the ChatFromViewer message to the host region). Raises application oriented events based on processing of messages (these are currently sparsely implemented)
:'''pyogp.apps''' - sample scripts and works in progress, the scripts here generally illustrate simple usage of classes as related to in world interactions by an agent of a Second Life grid
=== Dependencies ===
==== Platform / Python version compatibility ====
PyOGP aims to be compatible across platforms, though there are known problems with various environments. We'll be focusing on ensuring better compatibility soon.
'''Known good configurations'''
:Windows XP + Python 2.5
:Mac + Python 2.5, 2.6
:Linux + Python 2.4, 2.5, 2.6 (Linden hosts fall into this group)
'''Known bad configurations'''
:Windows Vista + Python 2.6
:Windows 7 + Python 2.6
There have been challenges in ensuring compatibility between the various dependencies, largely due to greenlet, eventlet, and pyopenssl. Please report bugs on [http://jira.secondlife.com/browse/PYO pJira]
==== Python module dependencies ====
The packages that make up PyOGP have some dependencies on python modules not included in a standard install, or sometimes not available on an older Python distribution.
'''pyogp.lib.base dependencies:'''
<syntaxhighlight lang="python">  #from setup.py
 
    install_requires=[
        'setuptools',
        # -*- Extra requirements: -*-
        'uuid',
        'elementtree',
        'llbase',
        'WebOb',
        'wsgiref',
        'eventlet==0.8.14',
        'pyOpenssl'
        ]</syntaxhighlight>
'''pyogp.lib.client dependencies:'''
<syntaxhighlight lang="python">    install_requires=[
        'setuptools',
        # -*- Extra requirements: -*-
        'pyogp.lib.base'
        ] </syntaxhighlight>
'''pyogp.apps dependencies:'''
<syntaxhighlight lang="python">    install_requires=[
        'setuptools',
        'pyogp.lib.client'
        ]</syntaxhighlight>
=== How to install ===
''Lindens can see internal documentation for more specific guidance. https://wiki.lindenlab.com/wiki/Pyogp#How_to_Install''
==== Standalone dev environment using buildout ====
Buildout is a type of Python development environment, organizing and configuring various components and their dependencies. On a desktop, one may checkout such an environment for working with PyOGP. One may optionally use a virtualenv Python environment to isolate the development code and it's runtime environment on one's host.
Dependencies: buildout takes care of everything, grabbing needed modules etc.
Wiki instructions: https://wiki.secondlife.com/wiki/Pyogp/Client_Lib/The_Development_Sandbox
==== Installing the PyOGP packages ====
Each of the PyOGP package may be installed to one's Python install or to a [http://pypi.python.org/pypi/virtualenv virtualenv]. '''Buyer beware''' if installing into your system's install: you'll want to be able to uninstall manually, as we haven't hooked up the uninstall. PyOGP is still coming up to speed with respect to distutils and pypi and the like, but it's relatively close now.
To install a package, simply run 'python setup.py install' in a package's root.
==== Referencing PyOGP packages via the PATH ====
Source code can be referenced directly if one simply ensures that a package, and it's dependencies, are available in the PYTHONPATH environmental variable.
== Current functional coverage ==
Anything not listed as covered is probably not yet covered.
pyogp.lib.base:
:* base udp messaging system (message.*)
:** UDP serialization/deserialization
:** message_template.msg parsing
:* base event queue messaging system (event_queue.EventQueueClient())
:* capabilities and their methods. Seed capabilities are a special case. (caps.Capability())
:* Message-based events (message.message_handler)
pyogp.lib.client:
:* agents (agent.Agent())
:** L$ balance request, friending, and walk/fly/sit/stand actions...
:* OGP agentdomain (agentdomain.AgentDomain())
:* application level events (event_system.AppEventsHandler())
:* some object handling (objects.*)
:** edit name, description, next-owner permissions and more
:** object creation is possible
:* some inventory handling (inventory.*)
:** login inv skeletons
:** fetching inventory, including AIS (caps based Agent Inventory Services))
:** some creating of new inventory items (LSL scripts, notecards)
:* regions (region.Region())
:** host and neighboring regions are handled slightly differently
:** udp and event queue connections are optionally enabled for each case
:** currently only pulling caps available to the agent via the seed cap (plus using the inventory related caps in the AIS context)
:* some appearance handling (appearance.AppearanceManager),
:* parcels
:* chat
:* some ImprovedInstantMessage handling
:** raises events on received instant messages
:** can deal with inventory offers/accepts/declines
:** other cases in this message are currently only logged
:* groups
:* group chat
:* LSL script uploading
=== Sample Scripts ===
There are a variety of scripted examples that have been used to exercise and test functionality as it is added to the library. These persist as coded documentation.
The source code is available in https://svn.secondlife.com/svn/linden/projects/2008/pyogp/pyogp.apps/trunk/pyogp/apps/examples/.
The following refers to a buildout context. If one installs pyogp.apps vi setup.py, these scripts will exist in the python environment's bin/ directory. In the buildout context, these scripts are available in {buildout root}/bin.
The scripts are derived from a package's 'setup.py' via the entry_points parameter, and essentially build executable Python scripts configured to run in the correct environment with the proper dependencies added the the path used by the script. These scripts are currently just simple illustrations of some uses of the PyOGP codebase.
<syntaxhighlight lang="python">  #the current entry_points in setup.py og pyogp.apps:
 
    entry_points={
        'console_scripts': [
            'AIS_inventory_handling = pyogp.apps.examples.AIS_inventory_handling:main',
            'agent_login = pyogp.apps.examples.agent_login:main',
            'agent_manager = pyogp.apps.examples.agent_manager:main',
            'appearance_management = pyogp.apps.examples.appearance_management:main',
            'chat_and_instant_messaging = pyogp.apps.examples.chat_and_instant_messaging:main',
            'group_chat = pyogp.apps.examples.group_chat:main',
            'group_creation = pyogp.apps.examples.group_creation:main',
            'inventory_handling = pyogp.apps.examples.inventory_handling:main',
            'inventory_transfer = pyogp.apps.examples.inventory_transfer:main',
            'inventory_transfer_specify_agent = pyogp.apps.examples.inventory_transfer_specify_agent:main',
            'login = pyogp.apps.examples.login:main',
            'multi_region_connect = pyogp.apps.examples.multi_region_connect:main',
            'object_create_edit = pyogp.apps.examples.object_create_edit:main',
            'object_create_permissions = pyogp.apps.examples.object_create_permissions:main',
            'object_create_rez_script = pyogp.apps.examples.object_create_rez_script:main',
            'object_creation = pyogp.apps.examples.object_creation:main',
            'object_properties = pyogp.apps.examples.object_properties:main',
            'object_tracking = pyogp.apps.examples.object_tracking:main',
            'parcel_management = pyogp.apps.examples.parcel_management:main',
            'parse_packets = pyogp.apps.examples.parse_packets:main',
            'region_connect = pyogp.apps.examples.region_connect:main',
            'smoke_test = pyogp.apps.examples.smoke_test:main',
            'chat = pyogp.apps.examples.chat_interface:main',
            ]
        }</syntaxhighlight>
== How it Works (High Level) ==
=== Eventlet ===
PyOGP use [[Eventlet]] to run coroutines to handle multiple 'concurrent' processes, rather than threads or multiple processes. Each client agent instance will spawn a handful of coroutines to handles e.g. the UDP pipe, the Event Queue, various monitors, while yielding time to the parent process which should ensure it yields to the other routines as well.
PyOGP uses eventlet in very elementary ways at this point, but will perhaps start to use blocking queues in some cases, so that the coroutine only is allocated processing time if there is work for it to do.
=== pyogp.lib.base ===
This package handles the protocols used when communicating with a Second Life grid. A high level perspective on the package reveals a MessageManager() (still in development) which provides an interface to the UDP and Event Queue connections, as well as basic networking with enables login and capabilities interactions. The base package also has a low level even system through which all messages are passed and sent to subscribers.
Any subcomponent is available for direct interaction at any time, the MessageManager() and the MessageHandler() are the simple access points.
==== Events & Callbacks ====
The event implementation in pyogp follows the observer pattern, where observers subscribe to and are notified when an event occurs. Data is passed throughout the client instance via events.
* MessageManager - is an attribute of a Region and every packet received/sent is filtered through here. subscriptions are by message name
** MessageHandler - is an attribute of MessageManager, and every categorized message received from the event queue or udp dispatcher is filtered through here. (message as defined in message_template.msg, or one of ['ChatterBoxInvitation', 'ChatterBoxSessionEventReply', 'ChatterBoxSessionAgentListUpdates', 'ChatterBoxSessionStartReply', 'EstablishAgentCommunication']. There may be unhandled messages, I just haven't seen em yet :))
===== Message Events =====
In the most fundamental implementation of event usage, all packets are passed through a MessageManager() instance for evaluation. Observers may register to receive udp packets serialized into the form of Message() instances. The MessageHandler() is a consolidation point for subscribing to messages keyed by message name, and created on demand via subscription.
See pyogp.lib.base.message.message_handler.MessageHandler() for more details.
The pyogp agent's Region() instances each monitor their stream of packets (e.g. the host region: agent.region.message_manager.message_handler). (Perhaps this should be changed to a generalized Network() class where all packets (coupled to their originating regions) are evaluated.
Event firing passes data on to a callback handler defined in the subscription, in the form of (handler, *args, **kwargs).
The Agent class monitors the ImprovedInstantMessage packet:
<syntaxhighlight lang="python">        onImprovedInstantMessage_received = self.region.message_handler.register('ImprovedInstantMessage')
        onImprovedInstantMessage_received.subscribe(self.onImprovedInstantMessage)
    def onImprovedInstantMessage(self, packet):
        """ handles the many cases of data being passed in this message """
        {code} # parse and handle the data...</syntaxhighlight>
The messaging system then fires the event when an ImprovedInstantMessage message is received, which calls onImprovedInstantMessage method above to handle the message contents. Multiple subscribers may be listening for any message related event, and each would be notified of the same Message() instance.
Unsubscribing from an event:
<syntaxhighlight lang="python">        onImprovedInstantMessage_received.unsubscribe(self.onImprovedInstantMessage)</syntaxhighlight>
There are various event and callback implementations viewable in pyogp, poke around and help consolidate things if you like.
=== pyogp.lib.client ===
The client package generally provides a convenient interface to initiate or interpret interactions with host region (or neighboring regions). By listening to the messaging related event system in pyogp.lib.base, the client package interprets the messages that come in off the wire, and executes business logic in building responses. pyogp.lib.client also provides simple methods to enable the ending of messages to a grid.
==== Events ====
* EventsHandler - an attribute of an Agent, also able to be passed in, that is intended as the primary interface of a pyogp application into the internal state and data events within the lib. This system uses the same base classes as used by the MessageHandler() in the base package, and the descriptions about events and callbacks above apply here as well. The api for subscribing to these events is similar to the MessageHandler(), with an additional timeout parameter passed in the _register() method. When the specified timeout expires, the subscription returns None and expires the subscription.
==== Agent Login (examples) ====
===== Single Agent Login & Chat=====
Spawn a client in a co-routine, allowing persistent presence until forcefully terminated.
<syntaxhighlight lang="python">from eventlet import api
from pyogp.lib.client.agent import Agent
from pyogp.lib.client.settings import Settings
settings = Settings()
settings.ENABLE_INVENTORY_MANAGEMENT = True
settings.MULTIPLE_SIM_CONNECTIONS = False
client = Agent(settings = settings)
api.spawn(client.login, options.loginuri, 'first', 'last', 'password', start_location = options.region)
# wait for the agent to connect to it's region
while client.connected == False:
    api.sleep(0)
while client.region.connected == False:
    api.sleep(0)
client.say("Hello World!")
# once connected, live until someone kills me
while client.running:
    api.sleep(0)</syntaxhighlight>
===== Multiple Agent Login =====
Each agent instance in logged in in a separate coroutine.
<syntaxhighlight lang="python">from pyogp.lib.client.agent import Agent
from pyogp.lib.client.agentmanager import AgentManager
credentials= [('agent1', 'lastname', 'password'), ('agent2', 'lastname', 'password')]
# prime the Agent instances
agents = [Agent(settings, firstname, lastname, password)
          for firstname, lastname, password in credentials]
agentmanager = AgentManager()
agentmanager.initialize(agents)
# log them in
for key in agentmanager.agents:
    agentmanager.login(key, options.loginuri, options.region)
# while they are connected, stay alive
while agentmanager.has_agents_running():
    api.sleep(0)</syntaxhighlight>
== Extending Functionality ==
While the implementations and structures in pyogp.lib.base can (and are in the process of) being refactored to improve performance or usability, it is a fairly complete package.
The functional coverage PyOGP provides on the other hand is not complete, and there are a variety of needs to complete the implementation in pyogp.lib.base. We need to improve coverage of message handling (dealing with messages sent to the client), add more wrappers for sending various messages and performing multistep tasks (to simplify the initiation of interactions with the region), and we need to raise more application level events in the client package so that applications have easy access to incoming data.
=== Sending Messages ===
PyOGP, like the Viewer, communicates with the Second Life simulator by sending messages over UDP.
In order to extend PyOGP, you'll build a representation of a new UDP message, and send it through the pyogp.lib.base modules for serialization and wire handling.
=== Example: Sending an IM ===
To send an IM to the simulator, send an ImprovedInstantMessage packet.  The base class for message packets is defined in <code>base/message/message.py</code>
Packets are assembled using a Message() instance which has the message name and Block() instances passed in through its constructor.  Similarly, Blocks are assembled by passing in the Block name and the value name and values for each of the Block values. (The ability to build Message() instances via an llsd payload is expected to be introduced soon.)
Note: It is important that the message name, block name, and value names and types should match what is specified in the message template. (It is also possible to manipulate the representation of the stored template, or to use a custom message template.)
Example:
<syntaxhighlight lang="python">    def send_ImprovedInstantMessage(self, AgentID = None, SessionID = None,
                                FromGroup = None, ToAgentID = None,
                                ParentEstateID = None, RegionID = None,
                                Position = None, Offline = None,
                                Dialog = None, _ID = None, Timestamp = None,
                                FromAgentName = None, _Message = None,
                                BinaryBucket = None):
        """
        sends an instant message packet to ToAgentID. this is a
        multi-purpose message for inventory offer handling, im, group chat,
        and more
        """
        packet = Message('ImprovedInstantMessage',
                        Block('AgentData',
                              AgentID = AgentID,
                              SessionID = SessionID),
                        Block('MessageBlock',
                              FromGroup = FromGroup,
                              ToAgentID = ToAgentID,
                              ParentEstateID = ParentEstateID,
                              RegionID = RegionID,
                              Position = Position,
                              Offline = Offline,
                              Dialog = Dialog,
                              ID = UUID(str(_ID)),
                              Timestamp = Timestamp,
                              FromAgentName = FromAgentName,
                              Message = _Message,
                              BinaryBucket = BinaryBucket))
        # Send the message:
        self.region.enqueue_message(packet, True)</syntaxhighlight>
=== Handling Incoming Messages and Raising an Event ===
To listen for when messages of a particular type are sent to the client instance, subscribe to the MessageHandler() on the host region's MessageManager(), like the example that follows:
<syntaxhighlight lang="python">        onImprovedInstantMessage_received = self.region.message_handler.register('ImprovedInstantMessage')
        onImprovedInstantMessage_received.subscribe(self.onImprovedInstantMessage)</syntaxhighlight>
When the event is fired upon receipt of the message matching the name, the specified callback handles the data passed along, and in this case raises an event notifying observers of the 'InstantMessageReceived' event in pyogp.lib.client of the important data.
<syntaxhighlight lang="python">    def onImprovedInstantMessage(self, packet):
        """ callback handler for received ImprovedInstantMessage messages. much is passed in this message, and handling the data is only partially implemented """
        Dialog = packet.blocks['MessageBlock'][0].get_variable('Dialog').data
        FromAgentID = packet.blocks['AgentData'][0].get_variable('AgentID').data
        if Dialog == ImprovedIMDialogue.InventoryOffered:
            self.inventory.handle_inventory_offer(packet)
        # ...
        # some of the Dialogue types this message can contain are handled, we are showing 2
        # ...
        elif Dialog == ImprovedIMDialogue.FromAgent:
            # ... code parses the data from the Message() instance ...
            message = AppEvent('InstantMessageReceived', FromAgentID = FromAgentID, RegionID = RegionID, Position = Position, ID = ID, FromAgentName = FromAgentName, Message = _Message)
            logger.info("Received instant message from %s: %s" % (FromAgentName, _Message))
            self.events_handler.handle(message)</syntaxhighlight>
== Logging ==
Uses python's standard logging module (http://docs.python.org/library/logging.html). The library defines logging events throughout, it is up to the application/script to determine the output.
Hooking logging into a new module:
<syntaxhighlight lang="python">from logging import getLogger
# initialize logging
logger = getLogger('pyogp.lib.client.agent')
class Agent(object):
    """ our agent class """
    def __init__(self, params):
        self.params = params
        logger.debug("Initializing agent with params: %s" % (params))</syntaxhighlight>
An application can then set up the logging output as follows (or any other way it pleases):
<syntaxhighlight lang="python">console = logging.StreamHandler()
formatter = logging.Formatter('%(asctime)-30s%(name)-30s: %(levelname)-8s %(message)s')
console.setFormatter(formatter)
logging.getLogger('').addHandler(console)
logging.getLogger('').setLevel(logging.DEBUG)</syntaxhighlight>
The output to console is then:
<code>2009-04-21 22:08:58,681      pyogp.lib.base.agent          : DEBUG    agent with params: params</code>
== Pyogp Unit Tests ==
See [[PyOGP_Package_Unittests]].
== Sphinx (api docs) ==
'''Api documentation is now available for PyOGP packages''' (well, not for apps yet, but someday....)!
In pyogp/docs in each of the pyogp.lib.base and pyogp.lib.client packages, one will find source, last revision, and build files for sphinx based documents. Output is available at {package root}/docs/html/index.html.
We plan on sharing the api documentation on the web soon, and will work to make simple build wrappers work on various platforms, though this is a low priority.
Ask Enus for updated documentation to be checked in, or, build a better refresh.py.
== Roadmap ==
See [[Pyogp/Roadmap]] for details, or ask in irc or on the mailing list. Here's what's up in the near term for pyogp:
* better '''packaging''' and '''platform compatibility'''
* more '''functional coverage''' of message. We are covering 32% of the messages the viewers sends or handles when received (though it's estimated at more like 50% of normal use cases.
* '''permissions system testing''' to save QA from 3-5 day regression passes on perms
* '''appearance''' - this will require enabling upload and download, plus baking. Anyone have some spare time? :)
[[Category: Pyogp_Client_Lib]]
[[Category: Pyogp]]
[[Category: Pyogp]]
[[Category:Architecture Working Group]]
[[Category:Grid_Interoperability]]
[[Category:AW Groupies]]
[[Category:MMOX]]

Latest revision as of 07:31, 27 June 2017

Intro

PyOGP is a young, open source, python client library which provides an interface to an agent (client) of a Second Life grid. The code aims to enable automated testing of Second Life grids, to encourage and enable exploration into the client/server relationship and related protocols of Second Life, and to make possible simple prototyping of various client applications.

Hosted on svn.secondlife.com, it does require a contributor's agreement for commit access, and currently has a few contributors from the Second Life open source community.

P.S. We'll likely be moving to hg relatively soon...

Goals

In the very near future, we can have tests available to be run as soon as a deploy is completed that exercise a simulator/grid in the same way we do a smoke test. We will use these as automated tests run at build time, post deploy validation, and regression testing of simulators and backend systems.

This provides early feedback on code quality. QA is then able to dive deeper in testing the changes specific to a branch.

Having this library available also allows us to test potential changes before we have finalized design and are ready to submit to QA. Not sure how something will play out? Try it, and test it with PyOGP....

A Brief History

PyOGP was originally created as a tool for testing OGP related changes to the Second Life grid. By the end of the summer in 2008, the pyogp.lib.base package provided a skeleton messaging system and was able to test Linden Lab's first implementation of an agent domain and the related changes in an agent's region handoff and teleport. As the development effort around OGP waned, we started to extend pyogp by adding higher level client related functionality. Recently, this functionality was split out into a separate python package (pyogp.lib.client), and sample scripts (and future apps) were moved into pyogp.apps.

Architecture Overview

Structure

PyOGP is comprised of three python packages. The library consists of pyogp.lib.base and pyogp.lib.client, while sample scripts, and in time applications, live in pyogp.apps.

pyogp.lib.base - consists of basic networking, messaging systems (UDP and event queue) and capabilities, custom datatypes, and a low level message related event system
pyogp.lib.client - consists of 'convenience' classes mapping methods and handlers to specific messages (e.g. Agent().say(msg) tells the client to send the ChatFromViewer message to the host region). Raises application oriented events based on processing of messages (these are currently sparsely implemented)
pyogp.apps - sample scripts and works in progress, the scripts here generally illustrate simple usage of classes as related to in world interactions by an agent of a Second Life grid

Dependencies

Platform / Python version compatibility

PyOGP aims to be compatible across platforms, though there are known problems with various environments. We'll be focusing on ensuring better compatibility soon.

Known good configurations

Windows XP + Python 2.5
Mac + Python 2.5, 2.6
Linux + Python 2.4, 2.5, 2.6 (Linden hosts fall into this group)

Known bad configurations

Windows Vista + Python 2.6
Windows 7 + Python 2.6

There have been challenges in ensuring compatibility between the various dependencies, largely due to greenlet, eventlet, and pyopenssl. Please report bugs on pJira

Python module dependencies

The packages that make up PyOGP have some dependencies on python modules not included in a standard install, or sometimes not available on an older Python distribution.

pyogp.lib.base dependencies:

  #from setup.py
  
     install_requires=[
         'setuptools',
         # -*- Extra requirements: -*-
         'uuid',
         'elementtree',
         'llbase',
         'WebOb',
         'wsgiref',
         'eventlet==0.8.14',
         'pyOpenssl'
         ]

pyogp.lib.client dependencies:

     install_requires=[
         'setuptools',
         # -*- Extra requirements: -*-
         'pyogp.lib.base'
         ]

pyogp.apps dependencies:

     install_requires=[
         'setuptools',
         'pyogp.lib.client'
         ]

How to install

Lindens can see internal documentation for more specific guidance. https://wiki.lindenlab.com/wiki/Pyogp#How_to_Install

Standalone dev environment using buildout

Buildout is a type of Python development environment, organizing and configuring various components and their dependencies. On a desktop, one may checkout such an environment for working with PyOGP. One may optionally use a virtualenv Python environment to isolate the development code and it's runtime environment on one's host.

Dependencies: buildout takes care of everything, grabbing needed modules etc.

Wiki instructions: https://wiki.secondlife.com/wiki/Pyogp/Client_Lib/The_Development_Sandbox

Installing the PyOGP packages

Each of the PyOGP package may be installed to one's Python install or to a virtualenv. Buyer beware if installing into your system's install: you'll want to be able to uninstall manually, as we haven't hooked up the uninstall. PyOGP is still coming up to speed with respect to distutils and pypi and the like, but it's relatively close now.

To install a package, simply run 'python setup.py install' in a package's root.

Referencing PyOGP packages via the PATH

Source code can be referenced directly if one simply ensures that a package, and it's dependencies, are available in the PYTHONPATH environmental variable.

Current functional coverage

Anything not listed as covered is probably not yet covered.

pyogp.lib.base:

  • base udp messaging system (message.*)
    • UDP serialization/deserialization
    • message_template.msg parsing
  • base event queue messaging system (event_queue.EventQueueClient())
  • capabilities and their methods. Seed capabilities are a special case. (caps.Capability())
  • Message-based events (message.message_handler)

pyogp.lib.client:

  • agents (agent.Agent())
    • L$ balance request, friending, and walk/fly/sit/stand actions...
  • OGP agentdomain (agentdomain.AgentDomain())
  • application level events (event_system.AppEventsHandler())
  • some object handling (objects.*)
    • edit name, description, next-owner permissions and more
    • object creation is possible
  • some inventory handling (inventory.*)
    • login inv skeletons
    • fetching inventory, including AIS (caps based Agent Inventory Services))
    • some creating of new inventory items (LSL scripts, notecards)
  • regions (region.Region())
    • host and neighboring regions are handled slightly differently
    • udp and event queue connections are optionally enabled for each case
    • currently only pulling caps available to the agent via the seed cap (plus using the inventory related caps in the AIS context)
  • some appearance handling (appearance.AppearanceManager),
  • parcels
  • chat
  • some ImprovedInstantMessage handling
    • raises events on received instant messages
    • can deal with inventory offers/accepts/declines
    • other cases in this message are currently only logged
  • groups
  • group chat
  • LSL script uploading

Sample Scripts

There are a variety of scripted examples that have been used to exercise and test functionality as it is added to the library. These persist as coded documentation.

The source code is available in https://svn.secondlife.com/svn/linden/projects/2008/pyogp/pyogp.apps/trunk/pyogp/apps/examples/.

The following refers to a buildout context. If one installs pyogp.apps vi setup.py, these scripts will exist in the python environment's bin/ directory. In the buildout context, these scripts are available in {buildout root}/bin.

The scripts are derived from a package's 'setup.py' via the entry_points parameter, and essentially build executable Python scripts configured to run in the correct environment with the proper dependencies added the the path used by the script. These scripts are currently just simple illustrations of some uses of the PyOGP codebase.

  #the current entry_points in setup.py og pyogp.apps:
  
     entry_points={
         'console_scripts': [
             'AIS_inventory_handling = pyogp.apps.examples.AIS_inventory_handling:main',
             'agent_login = pyogp.apps.examples.agent_login:main',
             'agent_manager = pyogp.apps.examples.agent_manager:main',
             'appearance_management = pyogp.apps.examples.appearance_management:main',
             'chat_and_instant_messaging = pyogp.apps.examples.chat_and_instant_messaging:main',
             'group_chat = pyogp.apps.examples.group_chat:main',
             'group_creation = pyogp.apps.examples.group_creation:main',
             'inventory_handling = pyogp.apps.examples.inventory_handling:main',
             'inventory_transfer = pyogp.apps.examples.inventory_transfer:main',
             'inventory_transfer_specify_agent = pyogp.apps.examples.inventory_transfer_specify_agent:main',
             'login = pyogp.apps.examples.login:main',
             'multi_region_connect = pyogp.apps.examples.multi_region_connect:main',
             'object_create_edit = pyogp.apps.examples.object_create_edit:main',
             'object_create_permissions = pyogp.apps.examples.object_create_permissions:main',
             'object_create_rez_script = pyogp.apps.examples.object_create_rez_script:main',
             'object_creation = pyogp.apps.examples.object_creation:main',
             'object_properties = pyogp.apps.examples.object_properties:main',
             'object_tracking = pyogp.apps.examples.object_tracking:main',
             'parcel_management = pyogp.apps.examples.parcel_management:main',
             'parse_packets = pyogp.apps.examples.parse_packets:main',
             'region_connect = pyogp.apps.examples.region_connect:main',
             'smoke_test = pyogp.apps.examples.smoke_test:main',
             'chat = pyogp.apps.examples.chat_interface:main',
             ]
        }

How it Works (High Level)

Eventlet

PyOGP use Eventlet to run coroutines to handle multiple 'concurrent' processes, rather than threads or multiple processes. Each client agent instance will spawn a handful of coroutines to handles e.g. the UDP pipe, the Event Queue, various monitors, while yielding time to the parent process which should ensure it yields to the other routines as well.

PyOGP uses eventlet in very elementary ways at this point, but will perhaps start to use blocking queues in some cases, so that the coroutine only is allocated processing time if there is work for it to do.

pyogp.lib.base

This package handles the protocols used when communicating with a Second Life grid. A high level perspective on the package reveals a MessageManager() (still in development) which provides an interface to the UDP and Event Queue connections, as well as basic networking with enables login and capabilities interactions. The base package also has a low level even system through which all messages are passed and sent to subscribers.

Any subcomponent is available for direct interaction at any time, the MessageManager() and the MessageHandler() are the simple access points.

Events & Callbacks

The event implementation in pyogp follows the observer pattern, where observers subscribe to and are notified when an event occurs. Data is passed throughout the client instance via events.

  • MessageManager - is an attribute of a Region and every packet received/sent is filtered through here. subscriptions are by message name
    • MessageHandler - is an attribute of MessageManager, and every categorized message received from the event queue or udp dispatcher is filtered through here. (message as defined in message_template.msg, or one of ['ChatterBoxInvitation', 'ChatterBoxSessionEventReply', 'ChatterBoxSessionAgentListUpdates', 'ChatterBoxSessionStartReply', 'EstablishAgentCommunication']. There may be unhandled messages, I just haven't seen em yet :))
Message Events

In the most fundamental implementation of event usage, all packets are passed through a MessageManager() instance for evaluation. Observers may register to receive udp packets serialized into the form of Message() instances. The MessageHandler() is a consolidation point for subscribing to messages keyed by message name, and created on demand via subscription.

See pyogp.lib.base.message.message_handler.MessageHandler() for more details.

The pyogp agent's Region() instances each monitor their stream of packets (e.g. the host region: agent.region.message_manager.message_handler). (Perhaps this should be changed to a generalized Network() class where all packets (coupled to their originating regions) are evaluated.

Event firing passes data on to a callback handler defined in the subscription, in the form of (handler, *args, **kwargs).

The Agent class monitors the ImprovedInstantMessage packet:

        onImprovedInstantMessage_received = self.region.message_handler.register('ImprovedInstantMessage')
        onImprovedInstantMessage_received.subscribe(self.onImprovedInstantMessage)

    def onImprovedInstantMessage(self, packet):
        """ handles the many cases of data being passed in this message """

        {code} # parse and handle the data...

The messaging system then fires the event when an ImprovedInstantMessage message is received, which calls onImprovedInstantMessage method above to handle the message contents. Multiple subscribers may be listening for any message related event, and each would be notified of the same Message() instance.

Unsubscribing from an event:

        onImprovedInstantMessage_received.unsubscribe(self.onImprovedInstantMessage)

There are various event and callback implementations viewable in pyogp, poke around and help consolidate things if you like.

pyogp.lib.client

The client package generally provides a convenient interface to initiate or interpret interactions with host region (or neighboring regions). By listening to the messaging related event system in pyogp.lib.base, the client package interprets the messages that come in off the wire, and executes business logic in building responses. pyogp.lib.client also provides simple methods to enable the ending of messages to a grid.

Events

  • EventsHandler - an attribute of an Agent, also able to be passed in, that is intended as the primary interface of a pyogp application into the internal state and data events within the lib. This system uses the same base classes as used by the MessageHandler() in the base package, and the descriptions about events and callbacks above apply here as well. The api for subscribing to these events is similar to the MessageHandler(), with an additional timeout parameter passed in the _register() method. When the specified timeout expires, the subscription returns None and expires the subscription.

Agent Login (examples)

Single Agent Login & Chat

Spawn a client in a co-routine, allowing persistent presence until forcefully terminated.

from eventlet import api

from pyogp.lib.client.agent import Agent
from pyogp.lib.client.settings import Settings

settings = Settings()

settings.ENABLE_INVENTORY_MANAGEMENT = True
settings.MULTIPLE_SIM_CONNECTIONS = False

client = Agent(settings = settings)

api.spawn(client.login, options.loginuri, 'first', 'last', 'password', start_location = options.region)

# wait for the agent to connect to it's region
while client.connected == False:
    api.sleep(0)

while client.region.connected == False:
    api.sleep(0)

client.say("Hello World!")

# once connected, live until someone kills me
while client.running:
    api.sleep(0)
Multiple Agent Login

Each agent instance in logged in in a separate coroutine.

from pyogp.lib.client.agent import Agent
from pyogp.lib.client.agentmanager import AgentManager

credentials= [('agent1', 'lastname', 'password'), ('agent2', 'lastname', 'password')]

# prime the Agent instances
agents = [Agent(settings, firstname, lastname, password)
          for firstname, lastname, password in credentials]

agentmanager = AgentManager()
agentmanager.initialize(agents)

# log them in
for key in agentmanager.agents:
    agentmanager.login(key, options.loginuri, options.region)

# while they are connected, stay alive
while agentmanager.has_agents_running():
    api.sleep(0)

Extending Functionality

While the implementations and structures in pyogp.lib.base can (and are in the process of) being refactored to improve performance or usability, it is a fairly complete package.

The functional coverage PyOGP provides on the other hand is not complete, and there are a variety of needs to complete the implementation in pyogp.lib.base. We need to improve coverage of message handling (dealing with messages sent to the client), add more wrappers for sending various messages and performing multistep tasks (to simplify the initiation of interactions with the region), and we need to raise more application level events in the client package so that applications have easy access to incoming data.

Sending Messages

PyOGP, like the Viewer, communicates with the Second Life simulator by sending messages over UDP.

In order to extend PyOGP, you'll build a representation of a new UDP message, and send it through the pyogp.lib.base modules for serialization and wire handling.

Example: Sending an IM

To send an IM to the simulator, send an ImprovedInstantMessage packet. The base class for message packets is defined in base/message/message.py

Packets are assembled using a Message() instance which has the message name and Block() instances passed in through its constructor. Similarly, Blocks are assembled by passing in the Block name and the value name and values for each of the Block values. (The ability to build Message() instances via an llsd payload is expected to be introduced soon.)

Note: It is important that the message name, block name, and value names and types should match what is specified in the message template. (It is also possible to manipulate the representation of the stored template, or to use a custom message template.)

Example:

    def send_ImprovedInstantMessage(self, AgentID = None, SessionID = None, 
                                FromGroup = None, ToAgentID = None, 
                                ParentEstateID = None, RegionID = None, 
                                Position = None, Offline = None, 
                                Dialog = None, _ID = None, Timestamp = None, 
                                FromAgentName = None, _Message = None, 
                                BinaryBucket = None):
        """ 
        sends an instant message packet to ToAgentID. this is a 
        multi-purpose message for inventory offer handling, im, group chat, 
        and more 
        """

        packet = Message('ImprovedInstantMessage', 
                         Block('AgentData', 
                               AgentID = AgentID, 
                               SessionID = SessionID), 
                         Block('MessageBlock', 
                               FromGroup = FromGroup, 
                               ToAgentID = ToAgentID, 
                               ParentEstateID = ParentEstateID, 
                               RegionID = RegionID, 
                               Position = Position, 
                               Offline = Offline, 
                               Dialog = Dialog, 
                               ID = UUID(str(_ID)), 
                               Timestamp = Timestamp, 
                               FromAgentName = FromAgentName, 
                               Message = _Message, 
                               BinaryBucket = BinaryBucket))

        # Send the message:
        self.region.enqueue_message(packet, True)

Handling Incoming Messages and Raising an Event

To listen for when messages of a particular type are sent to the client instance, subscribe to the MessageHandler() on the host region's MessageManager(), like the example that follows:

        onImprovedInstantMessage_received = self.region.message_handler.register('ImprovedInstantMessage')
        onImprovedInstantMessage_received.subscribe(self.onImprovedInstantMessage)

When the event is fired upon receipt of the message matching the name, the specified callback handles the data passed along, and in this case raises an event notifying observers of the 'InstantMessageReceived' event in pyogp.lib.client of the important data.

    def onImprovedInstantMessage(self, packet):
        """ callback handler for received ImprovedInstantMessage messages. much is passed in this message, and handling the data is only partially implemented """

        Dialog = packet.blocks['MessageBlock'][0].get_variable('Dialog').data
        FromAgentID = packet.blocks['AgentData'][0].get_variable('AgentID').data

        if Dialog == ImprovedIMDialogue.InventoryOffered:

            self.inventory.handle_inventory_offer(packet)

        # ...
        # some of the Dialogue types this message can contain are handled, we are showing 2
        # ...

        elif Dialog == ImprovedIMDialogue.FromAgent:

            # ... code parses the data from the Message() instance ...

            message = AppEvent('InstantMessageReceived', FromAgentID = FromAgentID, RegionID = RegionID, Position = Position, ID = ID, FromAgentName = FromAgentName, Message = _Message)

            logger.info("Received instant message from %s: %s" % (FromAgentName, _Message))

            self.events_handler.handle(message)

Logging

Uses python's standard logging module (http://docs.python.org/library/logging.html). The library defines logging events throughout, it is up to the application/script to determine the output.

Hooking logging into a new module:

from logging import getLogger

# initialize logging
logger = getLogger('pyogp.lib.client.agent')

class Agent(object):
    """ our agent class """

    def __init__(self, params):

        self.params = params

        logger.debug("Initializing agent with params: %s" % (params))

An application can then set up the logging output as follows (or any other way it pleases):

console = logging.StreamHandler()
formatter = logging.Formatter('%(asctime)-30s%(name)-30s: %(levelname)-8s %(message)s')
console.setFormatter(formatter)
logging.getLogger('').addHandler(console)
logging.getLogger('').setLevel(logging.DEBUG)

The output to console is then:

2009-04-21 22:08:58,681 pyogp.lib.base.agent  : DEBUG agent with params: params

Pyogp Unit Tests

See PyOGP_Package_Unittests.

Sphinx (api docs)

Api documentation is now available for PyOGP packages (well, not for apps yet, but someday....)!

In pyogp/docs in each of the pyogp.lib.base and pyogp.lib.client packages, one will find source, last revision, and build files for sphinx based documents. Output is available at {package root}/docs/html/index.html.

We plan on sharing the api documentation on the web soon, and will work to make simple build wrappers work on various platforms, though this is a low priority.

Ask Enus for updated documentation to be checked in, or, build a better refresh.py.

Roadmap

See Pyogp/Roadmap for details, or ask in irc or on the mailing list. Here's what's up in the near term for pyogp:

  • better packaging and platform compatibility
  • more functional coverage of message. We are covering 32% of the messages the viewers sends or handles when received (though it's estimated at more like 50% of normal use cases.
  • permissions system testing to save QA from 3-5 day regression passes on perms
  • appearance - this will require enabling upload and download, plus baking. Anyone have some spare time? :)