[Pyogp] What we should do

[Timothy Loughlin (Locklainn Linden)]

Hey guys,
Thanks for the update Enus. I'll start busting out the wiki outlines so
that we know what they are about.

As for the task list, I have been thinking about the lib and harness and
have really thought the same thing as Tao, that we should really start
at ground zero:

- What is the lib supposed to do?
- What is the test harness supposed to do?
- What functionality is in lib.base and what optional packages could be
created (like lib.agentdomain)

Also, I have been thinking about the tests, looking at Leyla's request
rez test script. The client library is most likely going to use (or
should) OO design principles. This means that some things are going to
be objects that encapsulates some code, of which we should be testing.
For instance, to test login we have to test each step of login and yet
be able to login all at once. We either have to code the objects to pass
information to the caller to test the returned info (responses from
server), or do something else (there are testing patterns people use).
So, this is something we should start thinking about right away, how we
are going to test each "unit" of the code inside an object.

I think we should also start discussing at a high level what we're going
to need. For instance, I think we should layout which interfaces we are
going to need and which implementations we should implement. Right now
we have some interfaces that Tao came up with. I think we should look
over what we really want and determine if we should change what he
already has. So, he has interfaces for the place_avatar and the
seed_capability, but these are really just capabilities. Do we need 3
interfaces for them? Which scales to having an interface for every
capability we can post to. So, whether or not we change it, I think we
should open up a dialog about what things we are going to need and where
they go.

[Christian Scholz]

Hi!

Post by Timothy Loughlin (Locklainn Linden)
Also, I have been thinking about the tests, looking at Leyla's request
rez test script. The client library is most likely going to use (or
should) OO design principles. This means that some things are going to
be objects that encapsulates some code, of which we should be testing.
For instance, to test login we have to test each step of login and yet
be able to login all at once. We either have to code the objects to pass
information to the caller to test the returned info (responses from
server), or do something else (there are testing patterns people use).
So, this is something we should start thinking about right away, how we
are going to test each "unit" of the code inside an object.

That's why I tried to keep components small so they can be tested
individually. The first test case is more or less the big picture test
case which also shows how to use it.
Separate tests for the caps system and so on should be done, too.

The test harness I would think would be more high level so that only the
functionality defined in the spec is tested but not the inner workings.

Post by Timothy Loughlin (Locklainn Linden)
I think we should also start discussing at a high level what we're going
to need. For instance, I think we should layout which interfaces we are
going to need and which implementations we should implement. Right now
we have some interfaces that Tao came up with. I think we should look
over what we really want and determine if we should change what he
already has. So, he has interfaces for the place_avatar and the
seed_capability, but these are really just capabilities. Do we need 3
interfaces for them? Which scales to having an interface for every
capability we can post to. So, whether or not we change it, I think we
should open up a dialog about what things we are going to need and where
they go.

Well, the SeedCapability and Capability classes maybe could be merged. I
just wanted to make sure you cannot accidently call get() on a cap which
is not a seed cap.

The idea behind IPlaceAvatar was to be able to test every capability
indivually if you want to. The needed logic can then be put into small
adapter components and does not need to reside in the agent. That's
probably mostly the format of the payload send to the cap url.

-- Tao