Difference between revisions of "PyOGP Client Library"

From Second Life Wiki
Jump to navigation Jump to search
Line 6: Line 6:
== Tasks==
== Tasks==
Task list for the client library. These may get PJIRA tasks someday, or some other format we decide upon.
Task list for the client library. These may get PJIRA tasks someday, or some other format we decide upon.
#Pre-project Tasks
#Start looking over and learning [[Eventlet]] most of the other documentation listed on this page
#*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 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]
#*Decide whether or not to incorporate [http://pypi.python.org/pypi/zc.buildout/1.0.0b30 buildout]
#*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
#Develop requirements specification - let's first get an idea of what it is, exactly, that we want to build
#*Requirements
#*Requirements
Line 20: Line 18:
#Implement the design
#Implement the design
#*Determine how to distribute the code so nobody's toes hurt and no elbows bumped
#*Determine how to distribute the code so nobody's toes hurt and no elbows bumped
Tasks that have been recently completed:
#*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]
== Status ==
== Status ==
*[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
*[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

Revision as of 05:57, 2 July 2008

This page is dedicated to the client library aspect of the Pyogp project. The more general page is Pyogp.

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... In the long, long run, the Client lib could be used as the basis for a lightweight client written in Python.

Tasks

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

  1. Start looking over and learning Eventlet most of the other documentation listed on this page
  2. Decide whether to doctest or not to doctest. We are certainly planning to use unittest
  3. Develop requirements specification - let's first get an idea of what it is, exactly, that we want to build
    • Requirements
    • Use cases - these might help to identify how the lib might be used by someone
    • 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
  4. 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.)
  5. Implement the design
    • Determine how to distribute the code so nobody's toes hurt and no elbows bumped

Tasks that have been recently completed:

    • Determine whether to 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 buildout

Status

  • Current Pyogp Repo - svn repo of the most up-to-date code we are using for the project
  • Interop Live Protocol - Current Interop project status, aka, what the beta agent domain has working
  • Tao Takashi's Pyogp - svn repo - Tao Takashi has hit the ground running with an experimental framework which has been made available here.
    • Read more at his blogpost describing the start of his work at his very long url.
  • Sai's Presence and Sai's Presence_cmd_line - Saijanai Kuhn's first attempts at some Python presence
  • Linden Pyogp - svn repo of Linden's first stab at framework, using Sai's code as a base
    • 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...
  • Interop Ruths - some news that may be of interest to us

Documentation

Components (and supporting environmental details)

These are the currently envisioned components.

  1. Login
  2. Caps (and while it's around, the UDP pipe)
  3. Message Handlers (see chttp)
  4. Basic web server parts for the Agent, Region and grid bits (ideally a snap in framework)

Licensing

  1. 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>
 Copyright 2008, Linden Research, Inc.
 
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
http://www.apache.org/licenses/LICENSE-2.0
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>