Christian Scholz wrote:
Hi!
Enus Linden schrieb:
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
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp
