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