[Pyogp] revisiting architecture choices

[Enus Linden]

So I've been mulling it over, and philosophical concerns aside, I'd like
to think about the practical impacts of the architectural decisions we
made a month ago.

We've chosen to include components in pyogp that the group is finding
challenging to work with. Tao spends a lot of time describing how things
need to be done to work in the framework, and we aren't collectively
moving forward as quickly as we could due to uncertainty on how to do
things. I am concerned that the code will become a maintenance issue
down the road. I'm also concerned pyogp won't be an accessible code base
to open source devs, or Linden Lab devs themselves. It hasn't proven
itself to be so yet...

Issues challenging us will settle as we solve them, but that doesn't
solve accessibility and maintenance concerns I have.

The primary goal we have is to test OGP enabled grids; the agent domain,
region domain, sims, etc. We do this by building a client library and
test suite. It seems to me that we've made it more challenging for the
participants involved so far than in necessary.

I'm just thinking here. It's not too late to refactor back to a simpler
world. We lose some measure of flexibility and formality, but these can
be regained later if it's fitting. I think we would gain development
speed, accessibility, and maintainability, and ultimately more
functional code faster.

Thought I'd throw this out before the get together tomorrow. I do
appreciate and admire the work and the contributors. I just am feeling
troubled by how things are going, and want to do right by our time and
efforts...

Thoughts would be appreciated.

thanks

enus

---------

Enus Linden aka Aaron Terrell
email: ***@lindenlab.com
sl: http://secondlife.com

[Christian Scholz]

Hi!

Post by Enus Linden
So I've been mulling it over, and philosophical concerns aside, I'd like
to think about the practical impacts of the architectural decisions we
made a month ago.
We've chosen to include components in pyogp that the group is finding
challenging to work with. Tao spends a lot of time describing how things
need to be done to work in the framework, and we aren't collectively
moving forward as quickly as we could due to uncertainty on how to do
things. I am concerned that the code will become a maintenance issue
down the road. I'm also concerned pyogp won't be an accessible code base
to open source devs, or Linden Lab devs themselves. It hasn't proven
itself to be so yet...
Issues challenging us will settle as we solve them, but that doesn't
solve accessibility and maintenance concerns I have.
The primary goal we have is to test OGP enabled grids; the agent domain,
region domain, sims, etc. We do this by building a client library and
test suite. It seems to me that we've made it more challenging for the
participants involved so far than in necessary.
I'm just thinking here. It's not too late to refactor back to a simpler
world. We lose some measure of flexibility and formality, but these can
be regained later if it's fitting. I think we would gain development
speed, accessibility, and maintainability, and ultimately more
functional code faster.
Thought I'd throw this out before the get together tomorrow. I do
appreciate and admire the work and the contributors. I just am feeling
troubled by how things are going, and want to do right by our time and
efforts...
Thoughts would be appreciated.

Well, understandable issues. I for myself just can say that working with
it, once understood has helped to produce more maintainable code and
using buildout keeps you from installing all sorts of packages manually.
Of course only as long as it works :-/.

Accessibility is relative though. For instance I find mulib not really
that accessible, also due to the fact that it uses it's own registration
scheme for adding consumers and the like. Here I would find a more
standardized way of doing that easier.

But as said, it's understandable so I let you decide then on how you
want to go on.

I think I myself will nevertheless maintain a branch/copy/something
which builds on top of ZCA as for me it makes developing things faster
and more reliable because of the process it implies. If the decision is
to drop ZCA I will then think about some plan on how to make reuse
things from the lib package inside a ZCAified package.

-- Christian

[Lawson English]

Post by Christian Scholz
Hi!

Post by Enus Linden
So I've been mulling it over, and philosophical concerns aside, I'd
like to think about the practical impacts of the architectural
decisions we made a month ago.
We've chosen to include components in pyogp that the group is finding
challenging to work with. Tao spends a lot of time describing how
things need to be done to work in the framework, and we aren't
collectively moving forward as quickly as we could due to uncertainty
on how to do things. I am concerned that the code will become a
maintenance issue down the road. I'm also concerned pyogp won't be an
accessible code base to open source devs, or Linden Lab devs
themselves. It hasn't proven itself to be so yet...
Issues challenging us will settle as we solve them, but that doesn't
solve accessibility and maintenance concerns I have.
The primary goal we have is to test OGP enabled grids; the agent
domain, region domain, sims, etc. We do this by building a client
library and test suite. It seems to me that we've made it more
challenging for the participants involved so far than in necessary.
I'm just thinking here. It's not too late to refactor back to a
simpler world. We lose some measure of flexibility and formality, but
these can be regained later if it's fitting. I think we would gain
development speed, accessibility, and maintainability, and ultimately
more functional code faster.
Thought I'd throw this out before the get together tomorrow. I do
appreciate and admire the work and the contributors. I just am
feeling troubled by how things are going, and want to do right by our
time and efforts...
Thoughts would be appreciated.

Well, understandable issues. I for myself just can say that working
with it, once understood has helped to produce more maintainable code
and using buildout keeps you from installing all sorts of packages
manually. Of course only as long as it works :-/.
Accessibility is relative though. For instance I find mulib not really
that accessible, also due to the fact that it uses it's own
registration scheme for adding consumers and the like. Here I would
find a more standardized way of doing that easier.
But as said, it's understandable so I let you decide then on how you
want to go on.
I think I myself will nevertheless maintain a branch/copy/something
which builds on top of ZCA as for me it makes developing things faster
and more reliable because of the process it implies. If the decision
is to drop ZCA I will then think about some plan on how to make reuse
things from the lib package inside a ZCAified package.

I've nothing against the ZCA, in fact I like it, from what I can
understand, but this is a short-term deadline vs long-term
architectural niceties and deadlines gotta win. Especially given that
there's only a relatively few missing lines of code here and there to
get things ready for the first deadline.

Seems to me that the overall structure of the system can be retained,
and we just sidestep ZCA for now and hardcode the interfaces between
modules keeping in mind that they could (and we hope, will) be ZCA-zied
when we have breathing room to work out the issues slowing us down.

Likewise, if the message handling module isn't quite ready, fallback to
my presence code UDP handler or whatever Enus managed to prettify from
that, and hand code the half-dozen payloads that will be need to support TP.

Its the architectural support that is blocking us, NOT the coding, IMHO.


Lawson

[Locklainn]

So here goes,
I mostly agree with what everyone has been saying. As I have been
writing code it have not been using ZCA because I'm just not sure where
it would be useful. I've been trying to think about it and plan
accordingly, but, as I have discussed with Tao, it seems like we are
just putting another layer of abstraction with no gain. What I mean is
that so far most interfaces we define have a 1 to 1 implementation. So
abstracting that interface gained us nothing other than abstraction. It
seems we do a lot of "just in case of the future" trains of thought,
which is very ideal, but it seems we are shooting ourselves in the foot
trying to do it. Meaning, we are planning for future changes, but most
likely the changes we are planning for won't occur.

Here are my less philosophical ideas:
1) I don't think it makes sense to take out ZCA and still try to code to
allow ZCA to be used at a later time. If we are going to code for ZCA,
we might as well use it. The coding is much different than normal coding
styles, so we can't have our cake and eat it too.
2) If we plan to stay with ZCA (which in all fairness doesn't seem like
too bad of an idea) we have to identify EXACTLY which parts we think
should be swappable. We don't have any design or architectural plan laid
out whatsoever, we haven't identified any components. Our design plan
just seems to be "GET IT DONE", and we pick up whatever IT is at the
time. So, with that said, ZCA can be effectively used if we identify
where we want to use it. Clearly everything shouldn't use ZCA as all
things don't need to be swappable components. Maybe we should come up
with some guidelines on how to decide.
3) I don't like the idea of splitting the project. The whole point of
this project was to pull together all the code that was currently in
place, integrate it, and expand it. Rather than having people working
independently on the same thing, we should make compromises and find the
best solution.
4) This one is directly for Tao: to me, it seems the problem lies in the
fact that we all can't see how ZCA gives us anything that using normal
OO coding styles can't. I mean, most software doesn't use ZCA and they
get along just fine. We have design patterns, OO design in general, and
all else to make things swappable and manageable. Why so driven to use
ZCA and not just design our code using GREAT OO design principles?
Coding to interfaces works outside of ZCA.

I hope I didn't offend anyone. In any case, I think we need a more solid
design to base our decisions on.
Thanks, and I REALLLLY hope this gets settled soon.

TJ

Post by Lawson English

Post by Christian Scholz
Hi!

Post by Enus Linden
So I've been mulling it over, and philosophical concerns aside, I'd
like to think about the practical impacts of the architectural
decisions we made a month ago.
We've chosen to include components in pyogp that the group is
finding challenging to work with. Tao spends a lot of time
describing how things need to be done to work in the framework, and
we aren't collectively moving forward as quickly as we could due to
uncertainty on how to do things. I am concerned that the code will
become a maintenance issue down the road. I'm also concerned pyogp
won't be an accessible code base to open source devs, or Linden Lab
devs themselves. It hasn't proven itself to be so yet...
Issues challenging us will settle as we solve them, but that doesn't
solve accessibility and maintenance concerns I have.
The primary goal we have is to test OGP enabled grids; the agent
domain, region domain, sims, etc. We do this by building a client
library and test suite. It seems to me that we've made it more
challenging for the participants involved so far than in necessary.
I'm just thinking here. It's not too late to refactor back to a
simpler world. We lose some measure of flexibility and formality,
but these can be regained later if it's fitting. I think we would
gain development speed, accessibility, and maintainability, and
ultimately more functional code faster.
Thought I'd throw this out before the get together tomorrow. I do
appreciate and admire the work and the contributors. I just am
feeling troubled by how things are going, and want to do right by
our time and efforts...
Thoughts would be appreciated.

Well, understandable issues. I for myself just can say that working
with it, once understood has helped to produce more maintainable code
and using buildout keeps you from installing all sorts of packages
manually. Of course only as long as it works :-/.
Accessibility is relative though. For instance I find mulib not
really that accessible, also due to the fact that it uses it's own
registration scheme for adding consumers and the like. Here I would
find a more standardized way of doing that easier.
But as said, it's understandable so I let you decide then on how you
want to go on.
I think I myself will nevertheless maintain a branch/copy/something
which builds on top of ZCA as for me it makes developing things
faster and more reliable because of the process it implies. If the
decision is to drop ZCA I will then think about some plan on how to
make reuse things from the lib package inside a ZCAified package.

I've nothing against the ZCA, in fact I like it, from what I can
understand, but this is a short-term deadline vs long-term
architectural niceties and deadlines gotta win. Especially given that
there's only a relatively few missing lines of code here and there to
get things ready for the first deadline.
Seems to me that the overall structure of the system can be retained,
and we just sidestep ZCA for now and hardcode the interfaces between
modules keeping in mind that they could (and we hope, will) be
ZCA-zied when we have breathing room to work out the issues slowing us
down.
Likewise, if the message handling module isn't quite ready, fallback
to my presence code UDP handler or whatever Enus managed to prettify
from that, and hand code the half-dozen payloads that will be need to
support TP.
Its the architectural support that is blocking us, NOT the coding, IMHO.
Lawson
_______________________________________________
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp

[Christian Scholz]

Post by Locklainn
So here goes,
I mostly agree with what everyone has been saying. As I have been
writing code it have not been using ZCA because I'm just not sure where
it would be useful. I've been trying to think about it and plan
accordingly, but, as I have discussed with Tao, it seems like we are
just putting another layer of abstraction with no gain. What I mean is
that so far most interfaces we define have a 1 to 1 implementation. So
abstracting that interface gained us nothing other than abstraction. It
seems we do a lot of "just in case of the future" trains of thought,
which is very ideal, but it seems we are shooting ourselves in the foot
trying to do it. Meaning, we are planning for future changes, but most
likely the changes we are planning for won't occur.

Well, in case of the network layer we actually have a use case. Another
one is for the pluggability of the serializer. The first allows somebody
for instance to implement a separate eventlet based layer and let the
library use this (and I use it internally for replacing the standard
layer with a test mockup layer).

I don't see the problem with the 1:1 situation. Interfaces IMHO help to
make clearer what the component is about as it distills the essentials
out. That's also why I proposed this way of working: first write a
doctest, then write interfaces, then implementation.

Post by Locklainn
1) I don't think it makes sense to take out ZCA and still try to code to
allow ZCA to be used at a later time. If we are going to code for ZCA,
we might as well use it. The coding is much different than normal coding
styles, so we can't have our cake and eat it too.
2) If we plan to stay with ZCA (which in all fairness doesn't seem like
too bad of an idea) we have to identify EXACTLY which parts we think
should be swappable. We don't have any design or architectural plan laid
out whatsoever, we haven't identified any components. Our design plan
just seems to be "GET IT DONE", and we pick up whatever IT is at the
time. So, with that said, ZCA can be effectively used if we identify
where we want to use it. Clearly everything shouldn't use ZCA as all
things don't need to be swappable components. Maybe we should come up
with some guidelines on how to decide.

As said, for me it's also about documentation and way of coding which
came out of the invention of the ZCA as a side effect. At least having
defined interfaces makes sense to me and does not really add that much.

Post by Locklainn
3) I don't like the idea of splitting the project. The whole point of
this project was to pull together all the code that was currently in
place, integrate it, and expand it. Rather than having people working
independently on the same thing, we should make compromises and find the
best solution.

I wasn't so much talking about splitting, more adding a layer to a maybe
ZCA-less library. This also would save me from always saying "see, with
ZCA this now would be very easy." ;-)

Post by Locklainn
4) This one is directly for Tao: to me, it seems the problem lies in the
fact that we all can't see how ZCA gives us anything that using normal
OO coding styles can't. I mean, most software doesn't use ZCA and they
get along just fine. We have design patterns, OO design in general, and
all else to make things swappable and manageable. Why so driven to use
ZCA and not just design our code using GREAT OO design principles?
Coding to interfaces works outside of ZCA.

Well, I have seen it happen with bigger project that OO sometimes is
quite inflexible. I gave some examples of how Zope2 looked like in the
end which led to a complete rewrite (and the invention of ZCA). ZCA was
invented out of a need to make a framework more pluggable. And at some
point you might need some registration of components so I proposed ZCA
because it's a solved problem there.

Lose coupling of components as ZCA brings us is also a topic which is
discussed in the software engineering scene and I at least have seen the
benefits in big projects where I see the before/after state. I agree
though that it shouldn't be overdone but what I mean is not that classes
should not mark up their interface but instead that classes do not need
to be dissected into adapters where this is not necessary.
And OO is not always that pluggable, because you usually cannot simply
change the superclass of some class you are using as it's all hardwired
then. And even then I would btw. propose to add interface definitions to
those classes to make clear for the user what the interface actually is.
It's less clutter then than doing it inside the code.

But as said, I will let you decide and maybe getting rid of ZCA might
also help me to spend my nights again with something else than defending
it and solving bugs :-) And if it helps to gain more developers, that's
ok as well.

-- Christian

[Dahlia Trimble]

With all due respect to those more involved than I...

I was a little hesitant to mention this since I haven't been contributing,
but I was thinking that it's getting way out of hand with the advanced
programming goodies and simplicity was being ignored. Is the idea to create
a perfect showcase python application, or to test the OGP protocol? Hard to
tell at this point. It certainly doesn't look like something that less
experienced python programmers would be able to use.

Let's not forget the KISS rule.

So I've been mulling it over, and philosophical concerns aside, I'd like to
think about the practical impacts of the architectural decisions we made a
month ago.
We've chosen to include components in pyogp that the group is finding
challenging to work with. Tao spends a lot of time describing how things
need to be done to work in the framework, and we aren't collectively moving
forward as quickly as we could due to uncertainty on how to do things. I am
concerned that the code will become a maintenance issue down the road. I'm
also concerned pyogp won't be an accessible code base to open source devs,
or Linden Lab devs themselves. It hasn't proven itself to be so yet...
Issues challenging us will settle as we solve them, but that doesn't solve
accessibility and maintenance concerns I have.
The primary goal we have is to test OGP enabled grids; the agent domain,
region domain, sims, etc. We do this by building a client library and test
suite. It seems to me that we've made it more challenging for the
participants involved so far than in necessary.
I'm just thinking here. It's not too late to refactor back to a simpler
world. We lose some measure of flexibility and formality, but these can be
regained later if it's fitting. I think we would gain development speed,
accessibility, and maintainability, and ultimately more functional code
faster.
Thought I'd throw this out before the get together tomorrow. I do
appreciate and admire the work and the contributors. I just am feeling
troubled by how things are going, and want to do right by our time and
efforts...
Thoughts would be appreciated.
thanks
enus
---------
Enus Linden aka Aaron Terrell
sl: http://secondlife.com
_______________________________________________
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/pyogp/attachments/20080725/00fe6f1a/attachment.htm

[Meadhbh S. Hamrick (Infinity Linden)]

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 486 bytes
Desc: This is a digitally signed message part
Url : http://lists.secondlife.com/pipermail/pyogp/attachments/20080725/edf3e46c/PGP.pgp

[JB Kraft]

I thought I could mention here, fwiw and from a python head out here in the
aether, that the project pretty much lost me as a potential contributor with
the architectural decisions. The time I can spend on any particular open
source project is weighed heavily against the curve of learning the "way" of
it. There is only so much time I can put into non-paying work. Plain old
python I have been with for years but I just don't have time or inclination
to adapt to a bunch of other ways of doing things unless there is a very
compelling reason to do so. A bonus is if I can apply that "way" to my
regular work and none of these particular components offer that that I can
see.

Anyway, I, for one, do hope things get back to basics as I would very much
like to contribute and wanted to mention it as a case for attracting other
bodies that was mentioned in a couple of other posts in this thread.

best regards
JB

On Fri, Jul 25, 2008 at 1:51 PM, Meadhbh S. Hamrick (Infinity Linden) <

I should chime in here as I'm probably the lead instigator in the "this is
getting unnecessarily complicated" wing of the PyOGP project.
For the most part, i'm going to stay out of discussions re: the values of
ZCA, webob, grok, buildout, etc. They are all great projects.
However...
Right now, it seems there's not enough "there" there in PyOGP to justify
placing a ZCA, buildout, webob, grok based infrastructure around it. If we
can't use "plain ol' python" to code a simple library to manage connections,
send and receive messages, then there's something seriously wrong with
Python, OGP or the world in general.
Fortunately, I don't think we can't use "plain ol' python" to build our
components, and then add a zope framework around it. Er... which is a round
about way of saying...
1. we can use "plain ol' python" to build our core library
2. we can code to interfaces without Zope or ZCA
3. we don't even need to eggify the code in order to demonstrate it running
4. eggification, buildout, ZCA, webob and grok are all useful, and can be
integrated at a later date
and
5. at the moment, I think it's advantageous to use only those bits of
python that ship with 2.4 (or even 2.3) to demonstrate working code. Then
add eggification, buildout, ZCA, webob and grok.
Also... I would like to thank Tao / CS / MrTopf for being available to
dispel a number of misconceptions i had about these components and about the
structure of the source tree.
And with that... I'm going to shut up and go write some more code.
-Cheers
-meadhbh / infinity
So I've been mulling it over, and philosophical concerns aside, I'd like to
think about the practical impacts of the architectural decisions we made a
month ago.
We've chosen to include components in pyogp that the group is finding
challenging to work with. Tao spends a lot of time describing how things
need to be done to work in the framework, and we aren't collectively moving
forward as quickly as we could due to uncertainty on how to do things. I am
concerned that the code will become a maintenance issue down the road. I'm
also concerned pyogp won't be an accessible code base to open source devs,
or Linden Lab devs themselves. It hasn't proven itself to be so yet...
Issues challenging us will settle as we solve them, but that doesn't solve
accessibility and maintenance concerns I have.
The primary goal we have is to test OGP enabled grids; the agent domain,
region domain, sims, etc. We do this by building a client library and test
suite. It seems to me that we've made it more challenging for the
participants involved so far than in necessary.
I'm just thinking here. It's not too late to refactor back to a simpler
world. We lose some measure of flexibility and formality, but these can be
regained later if it's fitting. I think we would gain development speed,
accessibility, and maintainability, and ultimately more functional code
faster.
Thought I'd throw this out before the get together tomorrow. I do
appreciate and admire the work and the contributors. I just am feeling
troubled by how things are going, and want to do right by our time and
efforts...
Thoughts would be appreciated.
thanks
enus
---------
Enus Linden aka Aaron Terrell
sl: http://secondlife.com
_______________________________________________
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp
_______________________________________________
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/pyogp/attachments/20080725/28ab582f/attachment.htm

[Lawson English]

Top posting:

If the latest build instructions work out-of-the-box for everyone, I
think many of the issues that have been raised go away.

grok merely lets you use ZCA without an XML file, if I understand things
correctly, so its not that big a deal. ZCA has potential all over the
place, and if buildout ever gets working, I far prefer "easy_install
<package>" to any other way of installing something that I've seen
besides a real end-user install wizard.

L.

Post by JB Kraft
I thought I could mention here, fwiw and from a python head out here
in the aether, that the project pretty much lost me as a potential
contributor with the architectural decisions. The time I can spend on
any particular open source project is weighed heavily against the
curve of learning the "way" of it. There is only so much time I can
put into non-paying work. Plain old python I have been with for years
but I just don't have time or inclination to adapt to a bunch of other
ways of doing things unless there is a very compelling reason to do
so. A bonus is if I can apply that "way" to my regular work and none
of these particular components offer that that I can see.
Anyway, I, for one, do hope things get back to basics as I would very
much like to contribute and wanted to mention it as a case for
attracting other bodies that was mentioned in a couple of other posts
in this thread.
best regards
JB
On Fri, Jul 25, 2008 at 1:51 PM, Meadhbh S. Hamrick (Infinity Linden)
I should chime in here as I'm probably the lead instigator in the
"this is getting unnecessarily complicated" wing of the PyOGP
project.
For the most part, i'm going to stay out of discussions re: the
values of ZCA, webob, grok, buildout, etc. They are all great
projects.
However...
Right now, it seems there's not enough "there" there in PyOGP to
justify placing a ZCA, buildout, webob, grok based infrastructure
around it. If we can't use "plain ol' python" to code a simple
library to manage connections, send and receive messages, then
there's something seriously wrong with Python, OGP or the world in
general.
Fortunately, I don't think we can't use "plain ol' python" to
build our components, and then add a zope framework around it.
Er... which is a round about way of saying...
1. we can use "plain ol' python" to build our core library
2. we can code to interfaces without Zope or ZCA
3. we don't even need to eggify the code in order to demonstrate it running
4. eggification, buildout, ZCA, webob and grok are all useful, and
can be integrated at a later date
and
5. at the moment, I think it's advantageous to use only those bits
of python that ship with 2.4 (or even 2.3) to demonstrate working
code. Then add eggification, buildout, ZCA, webob and grok.
Also... I would like to thank Tao / CS / MrTopf for being
available to dispel a number of misconceptions i had about these
components and about the structure of the source tree.
And with that... I'm going to shut up and go write some more code.
-Cheers
-meadhbh / infinity

Post by Enus Linden
So I've been mulling it over, and philosophical concerns aside,
I'd like to think about the practical impacts of the
architectural decisions we made a month ago.
We've chosen to include components in pyogp that the group is
finding challenging to work with. Tao spends a lot of time
describing how things need to be done to work in the framework,
and we aren't collectively moving forward as quickly as we could
due to uncertainty on how to do things. I am concerned that the
code will become a maintenance issue down the road. I'm also
concerned pyogp won't be an accessible code base to open source
devs, or Linden Lab devs themselves. It hasn't proven itself to
be so yet...
Issues challenging us will settle as we solve them, but that
doesn't solve accessibility and maintenance concerns I have.
The primary goal we have is to test OGP enabled grids; the agent
domain, region domain, sims, etc. We do this by building a client
library and test suite. It seems to me that we've made it more
challenging for the participants involved so far than in necessary.
I'm just thinking here. It's not too late to refactor back to a
simpler world. We lose some measure of flexibility and formality,
but these can be regained later if it's fitting. I think we would
gain development speed, accessibility, and maintainability, and
ultimately more functional code faster.
Thought I'd throw this out before the get together tomorrow. I do
appreciate and admire the work and the contributors. I just am
feeling troubled by how things are going, and want to do right by
our time and efforts...
Thoughts would be appreciated.
thanks
enus
---------
Enus Linden aka Aaron Terrell
sl: http://secondlife.com
_______________________________________________
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp

_______________________________________________
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp
------------------------------------------------------------------------
_______________________________________________
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp