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