Pyogp Client Lib

This page is dedicated to the client library aspect of the Pyogp project. The more general page is AWG_Test_Harness This page is in progress and so may be incomplete and some information may be incorrect at this point.

Overview

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...

Documentation

• Current Protocols
  • Current_login_protocols - what login is like now
• OGP Protocols
  • SLGOGP_Draft_1 - the outline of the OGP protocols
  • SLGOGP_Teleport_Strawman - what login may be like
  • Second_Life_Login_API_Strawman - what login may be like
• General Messaging
  • Second_Life_Grid_Protocols/Foundation - general protocol information
  • Protocol - this is general information about messaging and the various protocol systems
  • Eventlet - a networking library written in Python, probably going to be used for this project
  • Circuit - the way to pass two-way information along a UDP connection
  • Message - more detail of messages
  • Reverse_HTTP - I believe this is used (or will be) in the OGP protocols
• Coding notes
  • ZCA Guide - ZCA that the lib project will be using

Status

• Current Interop project status - Interop_Live_Protocol

• Projects
  • Interop Ruths - something news that may be of interest to us
• Pyogp SVN - svn repo of first stab at framework
  • pyogp.lib-login.py - sample script which logs into aditi's agent domain and establishes a presence on a simulator on vaak:

Plan

Task list for the client library. These may get PJIRA tasks someday, or some other format we decide upon.

1. ZCA or no 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.
2. Incorporate buildout?
3. Test framework: To doctest or not to doctest? We are certainly planning to use unittest
4. Determine how to handle test data. I imagine we'll build a template and interface to an implementation of the template, and leave contents up to the developer.