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 ZCA3. 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
and5. 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 On Jul 24, 2008, at 10:27 PM, Enus Linden wrote:
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: [EMAIL PROTECTED] sl: http://secondlife.com _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp
