Difference between revisions of "PyOGP Client Library Development"

From Second Life Wiki
Jump to navigation Jump to search
Line 1: Line 1:
This is the Development page for the [[Pyogp]] [[Pyogp/Client_Lib | Client Library]].
This is the Development page for the [[Pyogp]] [[Pyogp/Client_Lib | Client Library]].


== 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.
#Start looking over and learning [[Eventlet]] most of the other documentation listed on this page
#Start looking over and learning [[Eventlet]] most of the other documentation listed on this page
Line 48: Line 48:
#**#http://sim2.vaak.lindenlab.com:13001    Morris
#**#http://sim2.vaak.lindenlab.com:13001    Morris
#Presence - ability to be present on a grid
#Presence - ability to be present on a grid
== Licensing ==
# 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.
  <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>

Revision as of 07:36, 11 July 2008

This is the Development page for the Pyogp Client Library.

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

Components (and supporting environmental details)


Components

  1. Basic web server parts - deployable snap-in network framework.
    • Login server
    • Agent Domain
    • Region Domain
  2. Agent
  3. Capabilities - need some way to POST and GET to capabilities
  4. UDP Connections - some of the main functionality for a client happens in communication (2-way) with the server.
    • Message Handlers - other than having huge switch states or specific cases, we should create some message handlers that will handle the specific messages coming in. The current way this is handled in the viewer 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. We might consider something similar (this is because message handling is doing the same sort of thing as a web server, so might as well use currently working code).
      • To the sim - event queue (see chttp, SLGOGP_Draft_1#Event_Queues), using Capabilities
      • From the sim - when communication is sent to the client from the sim


Protocols
Protocols_Explained - here's a listing of the protocols that we may implement, and the implementation details about them as well.

  1. Login - ability to login to a login url, which will connect us to a simulator or agent domain
  2. Presence - ability to be present on a grid

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>