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.
JB Kraft wrote:
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)
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
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
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] <mailto:[EMAIL PROTECTED]>
sl: http://secondlife.com
_______________________________________________
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
------------------------------------------------------------------------
_______________________________________________
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
