[Pyogp] pertaining to pyogp milestones and releases

[Enus Linden]

In the pyogp discussion on Friday morning, we found ourselves talking
about what might constitute a milestone which could be considered a
release point. For those who wish to explore further, please see
http://wiki.secondlife.com/wiki/User:Enus_Linden/Office_Hours/2008_August_15.

In general, consensus is that pyogp should try and target releases (0.1,
0.2, etc) to synchronize with the protocol documentation as defined in a
particular version. So, the functionality in the initial pyogp release
will intend to correspond to the current working doc at
http://wiki.secondlife.com/wiki/Open_Grid_Protocol, which is Draft 2 of
the protocol.

While pyogp adheres to the protocol as defined in this document, some
initial work is required to facilitate practical library use. Here is a
proposal for what features could be considered as representative of a
body of work in pyogp.lib.base that could be considered a 0.1 tagged
release.

1. authentication against an agent domain
2. login via rez_avatar/place
3. maintenance of presence against the agent domain
4. a functional messaging system (UPD, client <-> simulator)
5. maintenance of presence against the simulator (via messaging system)
6. avatar teleport
7. unit tests for all code in the lib

I'd also like to consider a similar target for pyogp.interop, where
interop tests were funcational for all of the above. This would also
include functional tests for the caps in the protocol.

Let's discuss this list please.

To get to a place where we are comfortable with a 0.1 release, what
remains to be done? I believe it is implementing the pending messaging
system refactoring, and some amount of good example scripts exercising
all of the above.

So, thoughts? Once we've agreed on things, I'll update the wiki with intent.

-enus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/pyogp/attachments/20080815/2a181a2d/attachment.htm

[Christian Scholz]

Hi!

Post by Enus Linden
In the pyogp discussion on Friday morning, we found ourselves talking
about what might constitute a milestone which could be considered a
release point. For those who wish to explore further, please see
http://wiki.secondlife.com/wiki/User:Enus_Linden/Office_Hours/2008_August_15.
In general, consensus is that pyogp should try and target releases (0.1,
0.2, etc) to synchronize with the protocol documentation as defined in a
particular version. So, the functionality in the initial pyogp release
will intend to correspond to the current working doc at
http://wiki.secondlife.com/wiki/Open_Grid_Protocol, which is Draft 2 of
the protocol.

If (when?) the protocol gets splitted into functional pieces we maybe
should also discuss if we do the same with our package structure. My
idea for both the protocol and the library would be to have separate
pieces which also might have alternatives which you can easily plug
together (like different IM services, later on different 3d models etc.).

Post by Enus Linden
While pyogp adheres to the protocol as defined in this document, some
initial work is required to facilitate practical library use. Here is a
proposal for what features could be considered as representative of a
body of work in pyogp.lib.base that could be considered a 0.1 tagged
release.
1. authentication against an agent domain
2. login via rez_avatar/place
3. maintenance of presence against the agent domain
4. a functional messaging system (UPD, client <-> simulator)
5. maintenance of presence against the simulator (via messaging system)
6. avatar teleport
7. unit tests for all code in the lib

The question here is what 3), 5) and 6) consist of. The actual loop IMHO
should be part of the application, not the library but the library
should provide all the tools you need (like
serialization/deserialization of packets, keeping track of
circuits/acks, providing caps infrastructure etc.). The rest very much
depends on how you need your application to run I think.

So in general these should be all working as Locklainn showed. As for 1)
I guess we wait for the auth changes before we should release it. Is
there any timeframe on when this is going to happen.

As the functionality seems mostly in place I think before getting to 0.1
we should have some things cleaned up, added:

- using exceptions throughout the lib (any comments on my proposal, btw?)
- using logging throughout the lib (example coming)
- finished refactoring of the message system
- changed the auth scheme if the change is happening soon.

So should this then be 0.1 or 0.2? If we go with draft numbers maybe it
should be 0.2? (although of course this would be strange for a first
release, maybe 0.1 now and then jumping on draft numbers?)

As for numbering I would propose the following:

0.x for lib releases according to the draft number (x=draft number)
0.x.y for bugfix releases (no new features) for draft x
1.0 for the first official release according to spec v1.0

and so on.

x can then also be higher than 9, so 0.26 would mean library release for
draft 26.

We should also make sure we make it clear in the docs that the API can
still change quite a lot. We don't know yet how people really will use
the library and what would make the most sense so I would assume that we
have to change something. We are still in a quite early stage.

From some release on we can claim it semi-stable then which means that
we need to track changes and deprecate old API calls and remove them in
the over-next release or so. This means we would have to stay
backwards-compatible at least 1 release. Not sure when this should/will
happen though, depends on how confident we are and how much additional
work we want ;-)

Post by Enus Linden
I'd also like to consider a similar target for pyogp.interop, where
interop tests were funcational for all of the above. This would also
include functional tests for the caps in the protocol.
Let's discuss this list please.
To get to a place where we are comfortable with a 0.1 release, what
remains to be done? I believe it is implementing the pending messaging
system refactoring, and some amount of good example scripts exercising
all of the above.
So, thoughts? Once we've agreed on things, I'll update the wiki with intent.

See above.

cheers,

Christian

[Enus Linden]

hi Tao,

In reference to your point about 3, 4 and 6 below: yes, i agree, that
having code in the lib that enables those features is what we are
looking for.

As for version numbers, i don't see a need to correspond with the
versioning numbers of the OGP docs, they will in time change as they
shift from Draft to another status. There could be short term
convenience, which could be lost down the road. Let's just start with
matching and if the relevance becomes lost, so be it.

I do like this:
0.x for lib releases according to the draft number (x=draft number)
0.x.y for bugfix releases (no new features) for draft x
1.0 for the first official release according to spec v1.0

I'm hoping to look at logging and exceptions tomorrow given the time...

enus

Christian Scholz wrote:
| Hi!
|
| Enus Linden wrote:
|> In the pyogp discussion on Friday morning, we found ourselves talking
about what might constitute a milestone which could be considered a
release point. For those who wish to explore further, please see
http://wiki.secondlife.com/wiki/User:Enus_Linden/Office_Hours/2008_August_15.
|>
|> In general, consensus is that pyogp should try and target releases
(0.1, 0.2, etc) to synchronize with the protocol documentation as
defined in a particular version. So, the functionality in the initial
pyogp release will intend to correspond to the current working doc at
http://wiki.secondlife.com/wiki/Open_Grid_Protocol, which is Draft 2 of
the protocol.
|
| If (when?) the protocol gets splitted into functional pieces we maybe
should also discuss if we do the same with our package structure. My
idea for both the protocol and the library would be to have separate
pieces which also might have alternatives which you can easily plug
together (like different IM services, later on different 3d models etc.).
|
|> While pyogp adheres to the protocol as defined in this document, some
initial work is required to facilitate practical library use. Here is a
proposal for what features could be considered as representative of a
body of work in pyogp.lib.base that could be considered a 0.1 tagged
release.
|>
|> 1. authentication against an agent domain
|> 2. login via rez_avatar/place
|> 3. maintenance of presence against the agent domain
|> 4. a functional messaging system (UPD, client <-> simulator)
|> 5. maintenance of presence against the simulator (via messaging system)
|> 6. avatar teleport
|> 7. unit tests for all code in the lib
|
| The question here is what 3), 5) and 6) consist of. The actual loop
IMHO should be part of the application, not the library but the library
should provide all the tools you need (like
serialization/deserialization of packets, keeping track of
circuits/acks, providing caps infrastructure etc.). The rest very much
depends on how you need your application to run I think.
|
| So in general these should be all working as Locklainn showed. As for
1) I guess we wait for the auth changes before we should release it. Is
there any timeframe on when this is going to happen.
|
| As the functionality seems mostly in place I think before getting to
0.1 we should have some things cleaned up, added:
|
| - using exceptions throughout the lib (any comments on my proposal, btw?)
| - using logging throughout the lib (example coming)
| - finished refactoring of the message system
| - changed the auth scheme if the change is happening soon.
|
| So should this then be 0.1 or 0.2? If we go with draft numbers maybe
it should be 0.2? (although of course this would be strange for a first
release, maybe 0.1 now and then jumping on draft numbers?)
|
| As for numbering I would propose the following:
|
| 0.x for lib releases according to the draft number (x=draft number)
| 0.x.y for bugfix releases (no new features) for draft x
| 1.0 for the first official release according to spec v1.0
|
| and so on.
|
| x can then also be higher than 9, so 0.26 would mean library release
for draft 26.
|
| We should also make sure we make it clear in the docs that the API can
still change quite a lot. We don't know yet how people really will use
the library and what would make the most sense so I would assume that we
have to change something. We are still in a quite early stage.
|
| From some release on we can claim it semi-stable then which means that
we need to track changes and deprecate old API calls and remove them in
the over-next release or so. This means we would have to stay
backwards-compatible at least 1 release. Not sure when this should/will
happen though, depends on how confident we are and how much additional
work we want ;-)
|
|> I'd also like to consider a similar target for pyogp.interop, where
interop tests were funcational for all of the above. This would also
include functional tests for the caps in the protocol.
|>
|> Let's discuss this list please.
|>
|> To get to a place where we are comfortable with a 0.1 release, what
remains to be done? I believe it is implementing the pending messaging
system refactoring, and some amount of good example scripts exercising
all of the above.
|>
|> So, thoughts? Once we've agreed on things, I'll update the wiki with
intent.
|
| See above.
|
| cheers,
|
| Christian
|
|