Why isn't Python king of the hill?
Geoffrey Gerrietts
I've spent a lot of time trying to come up with a response to
Martijn's comments and questions. It's taken me more time than I
thought it would. My first cut was approaching a novel in length.
I'm going to try to restrain myself to the salient points this
time. (Still didn't do all that good a job, did I?)
Martijn writes:
> [ deletia ]
> How does Zope's ZEO fit in this picture? I would think it'd
> help scale a Python app across a lot of boxes, right? Zope of
> course has a persistence toolkit; the ZODB. RPC mechanisms
> exist for Zope as well; for instance XML-RPC. How were these
> not satisfactory?
We use ZEO to centralize our actual Zope objects. Business
objects, the core of our dynamic model, are managed outside Zope.
In Zope, we have images and DTML content, with a few wrapper
objects around external entities. We use an authentication scheme
that uses Zope's ACL mechanisms but stores user records in a SQL
database.
I've looked at ZODB and ZEO some for my personal edification. If
I'm not mistaken, they provide a great mechanism for object
persistence with key-based retrieval. My evaluation suggested
that ZODB and ZEO were not very good at handling arbitrary
retrieval, or even retrieval at the level of a SQL select
statement. I don't think we should expect them to do that, but
that's a very real requirement for much or most business data.
I don't know a whole lot about Zope and XML-RPC. I've read bits
and pieces on one site or another. It looks pretty easy to use
when Zope is your XML-RPC server, and it looks pretty easy to use
when you're on the client end of an XML-RPC call. Developing a
server seems only slightly more complicated, and looks to be
something that could be automated or abstracted fairly readily.
We use ILU in the place where XML-RPC would be. I honestly can't
give you a compare-contrast as to how the two crack up against
one another, or why we picked ILU. I suspect that we use ILU
because it was available and mature when the site was being
pulled together. Maybe one of the original architects had some
good reusable code generation tools to use with ILU.
I think our deployment benefits from ILU's directory-based
approach. An ILU server publishes where it's running so that
clients can connect to it; that adds a little fault-tolerance and
scalability to the design. On the other hand, ILU's pretty rigid
about a lot of things, so in a few specific spots in our
application, we've sacrificed some of the freedoms that generally
come with programming in Python.
Now I've answered the questions (I think fairly), but I'd like to
take a step back and re-frame my comments.
I like Python and I like programming in Python. I took this job
because I would get to program in Python. Some of my peers don't
share my enthusiasm, which is a shame, but I think they're
learning to appreciate it.
When I think about designing a webapp, though, I don't think
about an app like the one I'm working on now. I think about an
app I worked on a couple years back, one that really deserved to
be a webapp but wasn't.
That app ran out of an office of a half-dozen fairly tech-savvy
librarians. They knew web stuff, but did not know programming.
They had to hire consultants to develop for them, and hire
consultants to do system administration for them.
When I think about designing a webapp, this is the webapp I think
about -- the one I never got to write. For the last year or year
and a half, that mental design has been done in Java. In moments
of weakness, I think that I could get away with using Jython, but
in the end I come back to straight Java. The Java toolkit won't
make development any faster, but it does have other compelling
features.
Some of the features are either lacking or hidden to my limited
vision in Python, notably decimal math and PDF generation.
There's a certain draw to being able to take a single webapp and
deploy it on any of a dozen different app servers that know how
to handle the content, though it's small. But the biggest draw is
that someone who's proficient with Java is not too hard to find.
Someone who's proficient with Python is considerably harder to
lay hands on.
Furthermore, while performance isn't a huge deal to those folks,
their app did show signs of growing to cover a lot more terrain.
It's conceivable that once the app was turned loose, it really
would need to worry about the kind of massive load that starts to
show off Python's seams.
I think that part of the issue here is that when I think about a
webapp, I don't think about an app that will be written and won't
change. I don't think about working on the same app for the rest
of my life, or even for more than a couple years. And I think
about something that's continually growing, and I plan as if it
will be as cool to the rest of the world as I think it is.
For more modest ambitions, the factors that weigh heavy on me may
seem irrelevant or even overweening. :) Meanwhile, I'll build all
my administration tools, glue apps, and prototypes in Python. :)
Thanks,
--G.
---
Geoff Gerrietts <ge...@homegain.com>
I think I'm really speaking only for myself here.
Martijn Faassen
> I've spent a lot of time trying to come up with a response to
> Martijn's comments and questions.
I didn't realize just a few of my curious questions would have this
effect. I'm interested in scalability issues, as I hope to be running
into them eventually. (yeah, I meant that; if I run into them that means
business is going well :).
> It's taken me more time than I
> thought it would. My first cut was approaching a novel in length.
> I'm going to try to restrain myself to the salient points this
> time. (Still didn't do all that good a job, did I?)
Read with interest.
> Martijn writes:
>> [ deletia ]
>> How does Zope's ZEO fit in this picture? I would think it'd
>> help scale a Python app across a lot of boxes, right? Zope of
>> course has a persistence toolkit; the ZODB. RPC mechanisms
>> exist for Zope as well; for instance XML-RPC. How were these
>> not satisfactory?
> We use ZEO to centralize our actual Zope objects. Business
> objects, the core of our dynamic model, are managed outside Zope.
> In Zope, we have images and DTML content, with a few wrapper
> objects around external entities. We use an authentication scheme
> that uses Zope's ACL mechanisms but stores user records in a SQL
> database.
How does Zope interact with the business objects? Through external
methods?
> I've looked at ZODB and ZEO some for my personal edification. If
> I'm not mistaken, they provide a great mechanism for object
> persistence with key-based retrieval. My evaluation suggested
> that ZODB and ZEO were not very good at handling arbitrary
> retrieval, or even retrieval at the level of a SQL select
> statement.
What do you mean with 'arbitrary retrieval'? I agree SQL select-like
retrieval still isn't doable very well with the ZODB; the relational
paradigm does well here, and accomplishing this kind of thing with the ZODB
seems to be difficult. The ZCatalog can help here, and the underlying
BTree implementation has been rewritten to decrease some bottlenecks
recently, but my experience with it is extremely limited; I can't
'think' Catalog yet when I think about my problems.
> I don't think we should expect them to do that, but
> that's a very real requirement for much or most business data.
Agreed; the ZODB isn't good at lots of writes either, and its paradigm
is so different from the relational one a relational style application
shouldn't be written in it. There may be other approaches with the
ZODB to accomplish the same things, but I rather like the data being
in a relational database, and don't feel up to too much experimenting
with critical data. Eventually the ZODB may get there and I'll be
watching it. Also interesting is recent thought going into improved
integration of Zope with relational databases.
> I don't know a whole lot about Zope and XML-RPC. I've read bits
> and pieces on one site or another. It looks pretty easy to use
> when Zope is your XML-RPC server, and it looks pretty easy to use
> when you're on the client end of an XML-RPC call.
I've played with this a bit and it's pretty trivial; almost the same
as calling into the ZODB directly, though with some important limitations
(I believe XML-RPC can't do very much with objects, such as object
parameters). SOAP will also be interesting in this area, but
I don't think Zope speaks this yet and I haven't played with it.
> Developing a
> server seems only slightly more complicated, and looks to be
> something that could be automated or abstracted fairly readily.
> We use ILU in the place where XML-RPC would be. I honestly can't
> give you a compare-contrast as to how the two crack up against
> one another, or why we picked ILU. I suspect that we use ILU
> because it was available and mature when the site was being
> pulled together. Maybe one of the original architects had some
> good reusable code generation tools to use with ILU.
> I think our deployment benefits from ILU's directory-based
> approach. An ILU server publishes where it's running so that
> clients can connect to it; that adds a little fault-tolerance and
> scalability to the design. On the other hand, ILU's pretty rigid
> about a lot of things, so in a few specific spots in our
> application, we've sacrificed some of the freedoms that generally
> come with programming in Python.
I suppose this could be somewhat comparable with running CORBA
servers, right? I don't have much experience in this area, though
I'm very curious to hear more about how you integrate Zope with
this.
> Now I've answered the questions (I think fairly), but I'd like to
> take a step back and re-frame my comments.
> I like Python and I like programming in Python. I took this job
> because I would get to program in Python. Some of my peers don't
> share my enthusiasm, which is a shame, but I think they're
> learning to appreciate it.
> When I think about designing a webapp, though, I don't think
> about an app like the one I'm working on now. I think about an
> app I worked on a couple years back, one that really deserved to
> be a webapp but wasn't.
> That app ran out of an office of a half-dozen fairly tech-savvy
> librarians. They knew web stuff, but did not know programming.
> They had to hire consultants to develop for them, and hire
> consultants to do system administration for them.
> When I think about designing a webapp, this is the webapp I think
> about -- the one I never got to write. For the last year or year
> and a half, that mental design has been done in Java. In moments
> of weakness, I think that I could get away with using Jython, but
> in the end I come back to straight Java. The Java toolkit won't
> make development any faster, but it does have other compelling
> features.
> Some of the features are either lacking or hidden to my limited
> vision in Python, notably decimal math and PDF generation.
Python has reportlab for PDF, which seems to work pretty well:
I believe there's a PEP about introducing decimal math into the
Python core as the default behavior eventually; there's a thread elsewhere
on the newsgroup. I'm not very familiar with these issues, though.
Do you need decimal math to avoid the subtle rounding errors and such
inherent in floats, when doing currency calculations and such?
> There's a certain draw to being able to take a single webapp and
> deploy it on any of a dozen different app servers that know how
> to handle the content, though it's small.
What do you mean by this, exactly? Are you referring to the whole
Enterprise JavaBeans framework (sorry if I confuse any of the
terminology here) that's been implemented by various vendors? I've
always been skeptical about how well that actually works, but here
I'm skeptical without any actual real knowledge. :)
> But the biggest draw is
> that someone who's proficient with Java is not too hard to find.
Are you sure about this? I mean, sure, lots of people are being cranked
out that can use Java to a certain extent, but is it really true
that it's not hard to find someone *good* at it?
> Someone who's proficient with Python is considerably harder to
> lay hands on.
But I'd think that anyone who's actually good at Java would be
retrainable to use Python in a matter of days. I was okay with C++
and various other languages at the time, and picked it up in no
time, and from what I've read here over the years I'm sure my story isn't
the only one.
I'll grant you the use of Zope may be different. :) Then again, I may
be too skeptical about this; I've seen a non-programmer but web-savvy
person go from absolutely no Zope *or* Python *or* SQL knowledge last october
to maintaining and extending a web app I wrote back then, right now.
He's fiddling with the DTML, adding stuff here and there. He's added
a bit of SQL too, and knows how to exploit acquisition. He's now moving
into bits of Python. There's a lot he doesn't understand yet, but
he sure is effective. I wonder if that's a purely isolated case or if this
happens more often. I've seen something similar happen with a few others
though (though they did have more programming experience), so Zope may
not be as confounding as think. :)
> Furthermore, while performance isn't a huge deal to those folks,
> their app did show signs of growing to cover a lot more terrain.
> It's conceivable that once the app was turned loose, it really
> would need to worry about the kind of massive load that starts to
> show off Python's seams.
Are Java's seams that much tighter? I know it's faster, on average,
though it does seem to consume oodles of memory. And then there's the
question about closing the seams; it would seem to me that this would
be easier to do in Python in many situations, because it's just a lot
more flexible.
> I think that part of the issue here is that when I think about a
> webapp, I don't think about an app that will be written and won't
> change. I don't think about working on the same app for the rest
> of my life, or even for more than a couple years. And I think
> about something that's continually growing, and I plan as if it
> will be as cool to the rest of the world as I think it is.
Any larger app will have to grow and change over time, so I consider
this as well for my Zope/Python/relational database apps, which is
why I'm interested in your ideas about what makes Java more suitable
for these purposes. Not so I can go and use Java, but for stealing
some ideas. :)
> For more modest ambitions, the factors that weigh heavy on me may
> seem irrelevant or even overweening. :)
Many people are using Python for rather less modest ambitions, however.
I'm certainly planning to. :)
> Meanwhile, I'll build all
> my administration tools, glue apps, and prototypes in Python. :)
Good!
Thanks for the interesting posting,
Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?
Aahz Maruch
Martijn Faassen <m.fa...@vet.uu.nl> wrote:
>
>I believe there's a PEP about introducing decimal math into the Python
>core as the default behavior eventually; there's a thread elsewhere on
>the newsgroup.
Not quite. There's currently a PEP for making the default *rational*
arithmetic; I'm currently working on a module based on the ANSI standard
for decimal floating-point arithmetic. There's already Tim Peters's
FixedPoint for fixed-point decimal arithmetic.
I'm staying out of the politics on this one and leaving it to the
experts; I don't even really know enough to implement decimal
arithmetic, but I'm doing it anyway. ;-)
--
--- Aahz <*> (Copyright 2001 by aa...@pobox.com)
Androgynous poly kinky vanilla queer het Pythonista http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6
"Characters exist to suffer, you know. An author needs a little sadism
in her makeup." --Brenda Clough
Darrell
Don’t need to use it much.
When I crossed over from C++ the lack of a beautiful graphical debugger worried me.
That worry was a waste of time.
Performance:
Slower than Java? I don’t believe it.
Of course it depends on how you frame the test.
cPython has access to code that runs directly in ‘C’ more readily than Java. IMO
Although pure Python statements likely run more slowly than Java.
Notice how slow regular expressions are in Jython compared to cPython.
I haven’t compared them lately though.
Multiprecision math:
http://sourceforge.net/projects/gmpy/
Finding developers:
I’ve had great luck training Python developers.
If they can read newsgroups, write some form of code and download examples.
Then they are perfect Python candidates.
Now they can focus on the high level view of what is this thing supposed to do?
How can we test it?
Not to mention they can get help because the code is readable.
If it’s not then they have a problem.
--Darrell
Geoffrey Gerrietts <ge...@homegain.com> wrote in message news:<mailman.991359661...@python.org>...
D-Man
| Geoffrey Gerrietts <ge...@homegain.com> wrote:
...
| > Now I've answered the questions (I think fairly), but I'd like to
| > take a step back and re-frame my comments.
...
| > When I think about designing a webapp, this is the webapp I think
| > about -- the one I never got to write. For the last year or year
| > and a half, that mental design has been done in Java. In moments
| > of weakness, I think that I could get away with using Jython, but
| > in the end I come back to straight Java. The Java toolkit won't
| > make development any faster, but it does have other compelling
| > features.
...
| > There's a certain draw to being able to take a single webapp and
| > deploy it on any of a dozen different app servers that know how
| > to handle the content, though it's small.
|
| What do you mean by this, exactly? Are you referring to the whole
| Enterprise JavaBeans framework (sorry if I confuse any of the
| terminology here) that's been implemented by various vendors? I've
| always been skeptical about how well that actually works, but here
| I'm skeptical without any actual real knowledge. :)
I don't have any experience with J2EE either, but I hear the term a
lot in discussions regarding the direction of our products in this
Java shop.
My question for you is : What about J2EE makes it so great? What
are the features that you really need/want? Why not start an
"Enterprise Python" spec, or something, to provide those features in
Python? If J2EE is the main reason to use Java (excluding the reason
in your next section), then let's take all the good ideas from it and
make them part of Python too. If Python had "PyEE" then it might be
easier to sell to management <grin>.
| > But the biggest draw is that someone who's proficient with Java is
| > not too hard to find. Someone who's proficient with Python is
| > considerably harder to lay hands on.
Given the ease of learning Python and the flexibility it offers, I
don't think this a real issue. As Martijn's examples show, any Java
programmer can learn Python quite easily. I've also heard many
comments on this list indicating that most of the people who know
python and java like python a lot better than java (myself included).
| > Furthermore, while performance isn't a huge deal to those folks,
| > their app did show signs of growing to cover a lot more terrain.
| > It's conceivable that once the app was turned loose, it really
| > would need to worry about the kind of massive load that starts to
| > show off Python's seams.
|
| Are Java's seams that much tighter? I know it's faster, on average,
| though it does seem to consume oodles of memory. And then there's the
| question about closing the seams; it would seem to me that this would
| be easier to do in Python in many situations, because it's just a lot
| more flexible.
Finn Bock recently posted on Jython-users some numbers someone else
gave him regarding CPython vs. Jython on JDK 1.4 beta.
http://www.geocrawler.com/archives/3/7017/2001/5/0/5834964/
Using PyStone it showed Jython to be quite a bit faster than CPython.
I was surprised, but using Python and Java together might be more
feasible in the near future.
| > I think that part of the issue here is that when I think about a
| > webapp, I don't think about an app that will be written and won't
| > change. I don't think about working on the same app for the rest
| > of my life, or even for more than a couple years. And I think
| > about something that's continually growing, and I plan as if it
| > will be as cool to the rest of the world as I think it is.
|
| Any larger app will have to grow and change over time, so I consider
| this as well for my Zope/Python/relational database apps, which is
| why I'm interested in your ideas about what makes Java more suitable
| for these purposes. Not so I can go and use Java, but for stealing
| some ideas. :)
:-) (see above questions regardig J2EE)
| > Meanwhile, I'll build all
| > my administration tools, glue apps, and prototypes in Python. :)
|
| Good!
|
| Thanks for the interesting posting,
I found it interesting too.
-D
Geoffrey Gerrietts
I think a little easier to keep myself on target this time, but
watch out! I bet I start to ramble near the end. :)
Martijn writes:
> How does Zope interact with the business objects? Through
> external methods?
>
> I suppose this could be somewhat comparable with running CORBA
> servers, right? I don't have much experience in this area, though
> I'm very curious to hear more about how you integrate Zope with
> this.
I don't want to get into a position where I'm spilling too much
proprietary information, so I'll be a little vague. I apologize
in advance for that.
The answers to these questions are related. We don't have a
really clean MVC separation in our app, though we're trying to
make it cleaner.
The "Model" portion of the architecture consists of an Oracle
database and lots of small object servers. We try to keep the
business logic at this layer of the app, with varying degrees of
success. These servers publish their availability through ILU.
The "Controller" portion of the architecture consists of external
methods. The external methods should ideally handle little more
than convert and validate input, then pass it off to the "Model"
part of the app, through ILU.
The "View" portion of the app is DTML in Zope, served from a ZEO
database.
One of the nice features we have working for us is a "Service"
product that holds a cache of connected ILU clients. These
clients can be accessed from Zope or from our (slightly modified)
external methods, though access from DTML is frowned on. I'm not
sure where we got the Service product, or whether it would even
work with current revs of Zope. I think Digital Creations might
have had a hand in developing that.
I think that answers the question without getting me in trouble?
:)
Martijn writes (quoting me):
> > I've looked at ZODB and ZEO some for my personal edification. If
> > I'm not mistaken, they provide a great mechanism for object
> > persistence with key-based retrieval. My evaluation suggested
> > that ZODB and ZEO were not very good at handling arbitrary
> > retrieval, or even retrieval at the level of a SQL select
> > statement.
>
> What do you mean with 'arbitrary retrieval'?
I'm meaning something more along the lines of a real indexing and
retrieval engine here. A query might be something like "I want
all objects that have the word 'spam' in any of their
attributes". This compares to key-based retrieval which says "I
want the object with the key 'spam'" or the SQL-style retrieval
which says "I want the objects that contain the word 'spam' in
the column 'eggs' in the table 'bacon'."
Our application doesn't require arbitrary retrieval in its
current incarnation.
Martijn writes (quoting me):
> > Some of the features are either lacking or hidden to my limited
> > vision in Python, notably decimal math and PDF generation.
>
> Python has reportlab for PDF, which seems to work pretty well:
>
> http://www.reportlab.com
And Aahz contributes:
> Not quite. There's currently a PEP for making the default *rational*
> arithmetic; I'm currently working on a module based on the ANSI standard
> for decimal floating-point arithmetic. There's already Tim Peters's
> FixedPoint for fixed-point decimal arithmetic.
It would appear "hidden to my limited vision" is the appropriate
answer here. :) I didn't know about FixedPoint, which would
address most of my concerns. And I look very forward to Aahz's
implementation of decimal FP arithmetic. :)
To answer an un-quoted question, fixed point or decimal math is
required because dollars are involved. Binary FP's approximations
show up in odd places when you're doing decimal math, which makes
people uncomfortable when dealing with money.
Martijn writes (quoting me):
> > There's a certain draw to being able to take a single webapp and
> > deploy it on any of a dozen different app servers that know how
> > to handle the content, though it's small.
>
> What do you mean by this, exactly? Are you referring to the whole
> Enterprise JavaBeans framework (sorry if I confuse any of the
> terminology here) that's been implemented by various vendors? I've
> always been skeptical about how well that actually works, but here
> I'm skeptical without any actual real knowledge. :)
I can't speak to how easy it is to move from one app server to
another. I /can/ speak for how much of the "hard work" is done
for you by some of these enterprise containers -- a whole lot!
I'm not sure how Python and the Python community as it currently
exists could actually /do/ the servlet thing. It's an API, but
it's also a specification of a standard; Sun can get away with
declaring The Standard because they have such tight control over
Java. Python's more open community proves something of a weakness
here -- Zope is "standard" in a de facto sense, but everyone who
sets out to develop a templating language or a content server or
an app server sets out to do it in their own way, with their own
set of interfaces in mind. That means moving between servers
requires a layer of adaptor code in the best case, or a total
rewrite in worst.
Martijn writes (quoting me):
> > But the biggest draw is that someone who's proficient with
> > Java is not too hard to find.
>
> Are you sure about this? I mean, sure, lots of people are being
> cranked out that can use Java to a certain extent, but is it
> really true that it's not hard to find someone *good* at it?
>
> > Someone who's proficient with Python is considerably harder to
> > lay hands on.
>
> But I'd think that anyone who's actually good at Java would be
> retrainable to use Python in a matter of days.
Java programmers are more numerous than Python programmers.
"Good" is relative. I think "able to work on an app I wrote" is a
decent measure of goodness, and I think it's pretty safe to say
that someone who knows enough Java to pass a programming class
taught in Java could find his way around most of the Java apps I
write. A person coming out of school with a class taught in
Python might not have too much trouble with most of what I do in
Python, either -- but while I know plenty of people who passed
their Java classes, I don't know of anyone who has even taken a
Python class.
I agree that a person could be retrained to use Python, and could
learn Zope. Python's not a terribly difficult language to learn,
and it's a language that keeps on giving the longer you use it.
But I do think that it would be difficult for someone hired as a
consultant to walk in cold and learn enough Python and Zope to
make sense of how the app worked.
My office here is filled with C programmers who learned python on
the job, PHP programmers who learned Zope on the job, Java
programmers who came in cold. They all got up to speed in very
short order.
On the other hand, if the site had been less successful, and the
company could not afford to bring on full-time staff and pay to
have them trained -- if the company needed to hire a couple
contract programmers to come in and change a few things, add a
few things -- the company would have looked a very long time for
someone proficient enough in Zope and Python to come in cold and
make the changes they needed.
And it was a fierce struggle for several months, with three or
four programmers who knew nothing of Python or Zope. Those days
are spoken of with awe and terror; it was difficult enough for
someone like me, who knew his way around Python, to come in and
figure out Zope and our architecture. I can't even imagine what
it must have been like for people who didn't even know the
language.
If the app were done in Java, it would be a lot easier to hire
people who knew at least a little Java and could find their way
around the servlet API and JSP, whether as permanent employees or
temporary contractors. That's just because of the demographics.
Meanwhile, it's also a lot easier -- at least in our area -- to
send your employees off to a three day class on Java or JSP and
servlets, and it's easier to learn all three topics from any
number of widely-published, well-written books. Zope training
involved flying Matt out here from Digital Creations, and the
documentation is scarce.
Martijn (quoting me):
> > Furthermore, while performance isn't a huge deal to those folks,
> > their app did show signs of growing to cover a lot more terrain.
> > It's conceivable that once the app was turned loose, it really
> > would need to worry about the kind of massive load that starts to
> > show off Python's seams.
>
> Are Java's seams that much tighter? I know it's faster, on average,
> though it does seem to consume oodles of memory. And then there's the
> question about closing the seams; it would seem to me that this would
> be easier to do in Python in many situations, because it's just a lot
> more flexible.
Good point and maybe a tough call. I think it's easier to scale
Java, because it's easier for good programmers to write scalable
apps and harder for bad programmers to write apps that don't
scale.
Java's got its warts, too, though. It's a long way away from a
Perfect Language, and it's a resource-hungry monster.
Martijn writes:
> Any larger app will have to grow and change over time, so I
> consider this as well for my Zope/Python/relational database
> apps, which is why I'm interested in your ideas about what
> makes Java more suitable for these purposes. Not so I can go
> and use Java, but for stealing some ideas. :)
Probably the sanest thing either of us could be doing in this
discussion. :)
Let's see if we can come up with a short list -- I don't think
these belong in the PEPs, really, maybe just ideas for people's
projects? Maybe the first idea is some kind of formalized
community that would provide support for these kinds of
discussions? I don't know.
But the ideas.
It would be very good if you could take an object, instantiate it
in the context of a container, and basically have proxies
propagated to all other applications that have instantiated that
container.
Let's put it a different way, more abstract and less tied to
implementation. It would be very good if you could write an
object that conforms to a reasonable interface, and in so doing
"gain" the ability to use the object in a distributed fashion.
Currently, you've got to do it all by hand, and you can't count
on the way you do it one time being re-usable the next time.
There's no /standard/ way of doing it, and there's more than one
way to do it. That's treading into Perl's territory, there....
Here's something I like about the servlet containers (app
servers) that I haven't seen in Zope yet (maybe it's there?):
managed sessions via cookies OR URL rewriting. Some of the
servlet containers even support persistent sessions and sessions
shared across multiple app servers. When you have fault-tolerance
at that level of the application, that's powerful juju.
This is actually three features in one: managed sessions, persistent
sessions, and distributed sessions. Managed sessions means
providing session tracking mechanisms (preferably configurable).
Persistent sessions means that the sessions can survive a crash
and restart of the server. And distributed sessions means that
the same session can be accessed regardless of which server
process is handling the current request. The last two depend on
the first, but sessions could be either distributed or persistent
without also being the other.
Here's another one, one we can beat Java to the punch on: it
would be nice if you could do object storage and retrieval into a
relational database using a simple management framework. The
upcoming Java Data Objects spec is an easy example to look at,
but also consider looking at Apple/NeXT's Enterprise Objects
Framework. I started working on something like this using
metaclasses, and was reasonably successful, but it's a complex
undertaking, and time consuming....
Martijn writes (quoting me):
> > For more modest ambitions, the factors that weigh heavy on me may
> > seem irrelevant or even overweening. :)
>
> Many people are using Python for rather less modest ambitions,
> however.
> I'm certainly planning to. :)
And I think that HomeGain is using Python in a pretty significant
application, too. We've got a lot of traffic and a whole bunch of
data. It can work! It just doesn't seem to have all the tools to
facilitate it, and it's not nearly as ubiquitous as other
solutions.
Speaking for myself again,
--G.
----
Geoff Gerrietts <ge...@homegain.com>
Martijn Faassen
> In article <9f7ai7$b4e$1...@newshost.accu.uu.nl>,
> Martijn Faassen <m.fa...@vet.uu.nl> wrote:
>>
>>I believe there's a PEP about introducing decimal math into the Python
>>core as the default behavior eventually; there's a thread elsewhere on
>>the newsgroup.
> Not quite. There's currently a PEP for making the default *rational*
> arithmetic; I'm currently working on a module based on the ANSI standard
> for decimal floating-point arithmetic. There's already Tim Peters's
> FixedPoint for fixed-point decimal arithmetic.
> I'm staying out of the politics on this one and leaving it to the
> experts; I don't even really know enough to implement decimal
> arithmetic, but I'm doing it anyway. ;-)
You evidently know far more than I, however.
So there's fixed-point, decimal floating-point and rational arithmetic..
And plain-old-confusing floats. :)
They all involve numbers with points in them.. and when you do math
with them, the answers may be different. That's about the extent
of my knowledge.
Perhaps I can use them in a 'voting system', like mission critical computers
do (in the space shuttle and all). Use all four techniques and average
the results. Or perhaps discard outlying values and then average, or use
a sophisticated weighting system.. Hmm.. :)
Regards,
Martijn Faassen
[description of a large scale Python/Zope system]
> I think that answers the question without getting me in trouble?
> :)
That's clear, thank you.
I'm interested in moving business logic out of Zope myself to do
better MVC stuff, though another approach I'm taking is to to
create more general Python/Zope components that help make the
business logic so short and explicit you don't need lots of code
for that anymore. :)
I'm not saying this approach is *working*; I'm just saying I tend to
think in that direction; split out abstractions from the application
into generic external components so the actual business logic can be 'smaller'.
One direction I'm currently thinking in is to split out workflow into
an explicit workflow component (a python-based workflow management
system, doing for workflow what relational database management systems do
for data). It's still a lot of vague ideas and nothing serious has been
hatched yet, though.
> Martijn writes (quoting me):
>> > I've looked at ZODB and ZEO some for my personal edification. If
>> > I'm not mistaken, they provide a great mechanism for object
>> > persistence with key-based retrieval. My evaluation suggested
>> > that ZODB and ZEO were not very good at handling arbitrary
>> > retrieval, or even retrieval at the level of a SQL select
>> > statement.
>>
>> What do you mean with 'arbitrary retrieval'?
> I'm meaning something more along the lines of a real indexing and
> retrieval engine here. A query might be something like "I want
> all objects that have the word 'spam' in any of their
> attributes". This compares to key-based retrieval which says "I
> want the object with the key 'spam'" or the SQL-style retrieval
> which says "I want the objects that contain the word 'spam' in
> the column 'eggs' in the table 'bacon'."
Ah, a powerful query system, then. Difficult, too. Could you give
a real life example of an actual arbitrary retrieval system? It's
not full-text-search search, right? (the ZCatalog I believe already
can do something like that, on multiple attributes).
> Our application doesn't require arbitrary retrieval in its
> current incarnation.
[numbers with a point in there somewhere snipped :)]
> To answer an un-quoted question, fixed point or decimal math is
> required because dollars are involved. Binary FP's approximations
> show up in odd places when you're doing decimal math, which makes
> people uncomfortable when dealing with money.
Okay, I figured.
> Martijn writes (quoting me):
>> > There's a certain draw to being able to take a single webapp and
>> > deploy it on any of a dozen different app servers that know how
>> > to handle the content, though it's small.
>>
>> What do you mean by this, exactly? Are you referring to the whole
>> Enterprise JavaBeans framework (sorry if I confuse any of the
>> terminology here) that's been implemented by various vendors? I've
>> always been skeptical about how well that actually works, but here
>> I'm skeptical without any actual real knowledge. :)
> I can't speak to how easy it is to move from one app server to
> another. I /can/ speak for how much of the "hard work" is done
> for you by some of these enterprise containers -- a whole lot!
Could you go into some more detail on this? I've heard this more often,
but I'm still not entirely clear on *what* work is done. :)
> I'm not sure how Python and the Python community as it currently
> exists could actually /do/ the servlet thing. It's an API, but
> it's also a specification of a standard; Sun can get away with
> declaring The Standard because they have such tight control over
> Java. Python's more open community proves something of a weakness
> here -- Zope is "standard" in a de facto sense, but everyone who
> sets out to develop a templating language or a content server or
> an app server sets out to do it in their own way, with their own
> set of interfaces in mind. That means moving between servers
> requires a layer of adaptor code in the best case, or a total
> rewrite in worst.
I'm not interested in promoting a standard, I'm just interested in
stealing ideas for Python-based APIs. I'm not interested in standardizing
these APIs. :)
I think Zope's new page template language (TAL and such) has some potential
to become something more close to a standard for templating XHTML, though
there will always be other systems, of course.
Zope itself is slowly moving into the direction to be a server for
simple Python objects, with (interface) adaptor layers on top to actually
use the object in the Zope framework (and publish it). This will hopefully
make it easier to exchange code with other Python software.
This all an aside; now spill the beans about what makes these Java
APIs so great! :)
> Martijn writes (quoting me):
>> > But the biggest draw is that someone who's proficient with
>> > Java is not too hard to find.
>>
>> Are you sure about this? I mean, sure, lots of people are being
>> cranked out that can use Java to a certain extent, but is it
>> really true that it's not hard to find someone *good* at it?
>>
>> > Someone who's proficient with Python is considerably harder to
>> > lay hands on.
>>
>> But I'd think that anyone who's actually good at Java would be
>> retrainable to use Python in a matter of days.
> Java programmers are more numerous than Python programmers.
No contest. They're being cranked out, though, so the average quality
is probably lower than that of still more-or-less self selected Python
programmers. But there are *so* many Java programmers it's definitely
more easy to find those.
[snip]
> I agree that a person could be retrained to use Python, and could
> learn Zope. Python's not a terribly difficult language to learn,
> and it's a language that keeps on giving the longer you use it.
> But I do think that it would be difficult for someone hired as a
> consultant to walk in cold and learn enough Python and Zope to
> make sense of how the app worked.
Are you sure that works for Java (or *any* language) though? :)
Wouldn't any significant application be non-trivial to figure out
for someone new to it, or do the standard APIs help so much?
[snip people coming up to speed easily]
> On the other hand, if the site had been less successful, and the
> company could not afford to bring on full-time staff and pay to
> have them trained -- if the company needed to hire a couple
> contract programmers to come in and change a few things, add a
> few things -- the company would have looked a very long time for
> someone proficient enough in Zope and Python to come in cold and
> make the changes they needed.
Agreed, I can see this concern, especially with Zope; not so much with
Python -- any decent programmer with some OO experience can pick up enough
Python in no time.
[snip]
> If the app were done in Java, it would be a lot easier to hire
> people who knew at least a little Java and could find their way
> around the servlet API and JSP, whether as permanent employees or
> temporary contractors. That's just because of the demographics.
> Meanwhile, it's also a lot easier -- at least in our area -- to
> send your employees off to a three day class on Java or JSP and
> servlets, and it's easier to learn all three topics from any
> number of widely-published, well-written books. Zope training
> involved flying Matt out here from Digital Creations, and the
> documentation is scarce.
I think we need to separate comparing Zope with the Java-style
solutions and Python to Java. I think there can be a good case made
that switching to Python is not that big a deal. Learning about
Zope is a whole different story, however. It's far easier than it
used to be, on the documentation side; community knowledge has also
increased. But your concerns with Zope make sense.
[snip scaling java versus scaling python; the jury is mostly out]
> Martijn writes:
>> Any larger app will have to grow and change over time, so I
>> consider this as well for my Zope/Python/relational database
>> apps, which is why I'm interested in your ideas about what
>> makes Java more suitable for these purposes. Not so I can go
>> and use Java, but for stealing some ideas. :)
> Probably the sanest thing either of us could be doing in this
> discussion. :)
> Let's see if we can come up with a short list -- I don't think
> these belong in the PEPs, really, maybe just ideas for people's
> projects?
Yup. Note that Zope is onto entity/session beans or whatever bizarro
terminology Java uses, though this is only in the exploration stages.
The proposed terms for Zope components are Content/Application/Presentation.
Here's a link into a 'half-baked wiki' (aren't they always?) discussing
this:
http://www.zope.org/Members/michel/Components/Components/NewReligion
> Maybe the first idea is some kind of formalized
> community that would provide support for these kinds of
> discussions? I don't know.
A 'Python generic application server APIs' mailing list? :)
I'm not sure if that'd work.
> But the ideas.
> It would be very good if you could take an object, instantiate it
> in the context of a container, and basically have proxies
> propagated to all other applications that have instantiated that
> container.
Note that XML-RPC sort-of-almost does something like this; it looks
like proxies, at least. There are actually several light-weight
RPC mechanisms for Python that use proxy-objects like this
(and I heard the now-cancelled Ultima Online 2 project rolled their
own).
Or what do you mean by 'other applications that have instantiated that
container'? Presumably they've instantiated a *proxy* of the container?
> Let's put it a different way, more abstract and less tied to
> implementation. It would be very good if you could write an
> object that conforms to a reasonable interface, and in so doing
> "gain" the ability to use the object in a distributed fashion.
Have you seen the interfaces PEP? The Python community is slowly
moving to supporting the notion of explicit interfaces (apart from
classes), with run-time querying and checking (does this object support
the 'foo' interface?).
> Currently, you've got to do it all by hand, and you can't count
> on the way you do it one time being re-usable the next time.
> There's no /standard/ way of doing it, and there's more than one
> way to do it. That's treading into Perl's territory, there....
Agreed that there's a need for this. Once we have interfaces,
remote querying and so on is only a small step away, of course.
> Here's something I like about the servlet containers (app
> servers) that I haven't seen in Zope yet (maybe it's there?):
> managed sessions via cookies OR URL rewriting. Some of the
> servlet containers even support persistent sessions and sessions
> shared across multiple app servers. When you have fault-tolerance
> at that level of the application, that's powerful juju.
[snip]
Check out 'Core Session Tracking' (not yet in the Zope core, they're but
working on it). I think it may come close to supporting all of
these, especially with ZEO.
http://www.zope.org/Members/mcdonc/Products/CoreSessionTracking
(see the release information, near the bottom for a description.
It also has extensive docs that you'll see when you install it)
[snip]
> Here's another one, one we can beat Java to the punch on: it
> would be nice if you could do object storage and retrieval into a
> relational database using a simple management framework. The
> upcoming Java Data Objects spec is an easy example to look at,
> but also consider looking at Apple/NeXT's Enterprise Objects
> Framework. I started working on something like this using
> metaclasses, and was reasonably successful, but it's a complex
> undertaking, and time consuming....
I believe there are various Zope projects looking into this
(and has received quite a bit of attention recently). One is
ZPatterns, something I never got into. Another recent project is
SmartObjects. Finally the Digital Creations folks are looking into
better relational database integration.
Lots of developments that haven't been fully baked yet, of course, but
they're sure being baked. :)
> Martijn writes (quoting me):
>> > For more modest ambitions, the factors that weigh heavy on me may
>> > seem irrelevant or even overweening. :)
>>
>> Many people are using Python for rather less modest ambitions,
>> however.
>> I'm certainly planning to. :)
> And I think that HomeGain is using Python in a pretty significant
> application, too. We've got a lot of traffic and a whole bunch of
> data. It can work! It just doesn't seem to have all the tools to
> facilitate it, and it's not nearly as ubiquitous as other
> solutions.
It's definitely not as ubiquitous, but the tools are being worked on.
And in some areas Python may be further along than the Java
competition, due to its flexible nature. ZEO developments are very
interesting, for instance. While Java certainly has object database, I
imagine they're not as transparent in use as the ZODB can be.
Thanks for your response!
Geoffrey Gerrietts
> So there's fixed-point, decimal floating-point and rational
> arithmetic..
> And plain-old-confusing floats. :)
>
> They all involve numbers with points in them.. and when you do math
> with them, the answers may be different. That's about the extent
> of my knowledge.
Here's a five minute explanation, and maybe I can dig up a link to a quick
tutorial on FP in general. (Ok, maybe it's more like a fifteen-minute
explanation. Somebody stop me!) Someone who knows better ought to correct me
if I'm talking out my butt.
=====
Floating Point systems
=====
FP numbers are stored as a mantissa times an exponent: 1.22 * (2 ** 15).
Let's look at a base-10 FP system real quick:
1.22 * (10 ** 4) = 12200
We are using 3 digits in the mantissa and 4 in the exponent.
If you want to express 1.2 or .012 in this system, no problem.
However, if you want to express 1.0002 or 100001, you have a problem. You
can't come up with a mantissa that accurately represents that. So you pick a
good representation that's close to what you're trying to describe.
You get three "zones" of inaccuracy in an FP system. The first is the one
you'd expect, at the outside edge of your number system. There's a point at
which your exponents can't get any bigger, so you can't get any more
positive or any more negative. This is usually represented as an overflow
error. In our sample number system, trying to represent 10 million would
cause an overflow error, because you really need a 2 digit exponent for
that.
You also get a zone "between" numbers, where you can't get enough precision
in your mantissa
to express a certain value. We've seen this already, with 1.0002 or 100001.
Generally the solution is to round off, so you get 1.00 * (10 ** 1) = 1.0
and 1.00 * (10 ** 5) = 100000.
Making sense so far, right?
The other place you get a problem is in fractions close to zero. There's a
"hole at zero", where anything smaller than 1.0 times your smallest negative
exponent falls into the "hole at zero". This is generally a larger range of
values than the range of possible values between two mantissa values.
=====
Decimal FP vs. Binary FP
=====
In a decimal FP system, your 'hole at zero' and the precision you're working
at are values that seem to correspond with the standard base-10 arithmetic
you learned in school. You can look at the number of digits in your mantissa
and predict where rounding will occur. That rounding will make the same kind
of sense it would if you were working with a currency system, or the metric
system, or whatever. If the next digit out from your precision is 5 or more,
you round up, otherwise round down.
Most computers use a binary FP system, though. That means that things that
divide nicely by two are expressed quite naturally. On the other hand,
values that do not divide nicely by two need to be approximated.
The big problem with binary FP is that most people (myself included) don't
know when to expect approximation rather than an exact result. Without doing
the actual translation math, it's hard to know whether the simple decimal
value you're looking at will turn into something big and burly when
translated to binary. For example, .1 is an infinitely-recurring binary
fraction. If you've got python on hand, type .1 at the prompt, and see what
I mean. :) (I note that my version of 1.5.2 doesn't display the problem --
it does some rounding under the covers. I'm not sure why, or how.)
=====
Fixed-Point
=====
As I understand it, fixed-point arithmetic scales the fractions into
integers, and keeps track of the scaling. An example might be that you would
represent .12 as 12 with a scaling factor of 10 ** -2. This differs from FP
in that the mantissa is always an integer.
When you do fixed-point arithmetic, you convert both numbers to an identical
scale, then perform integer math on them, then apply scaling to the result.
It's accurate in a decimal way, but it doesn't do so well when the numbers
have vastly different scales -- you might get overflows with your integer
mantissas.
I need to be reliably decimal-based for financial transactions, which are
all likely to have an identical scale. Fixed point will work fine for me,
even though it's not as efficient as a decimal-based floating-point would
be.
=====
Unbounded rationals
=====
Unbounded rationals would basically give the language the power to express
any rational number accurately. I confess that I'm not sure how it would go
about doing that exactly. I THINK it would do so by maintaining an internal
representation of the operation that gives rise to an infinitely-repeating
decimal, and use that expression in conjunction with known mathematical
properties to join in expressions with other values.
This is pretty complicated to do, and, according to several people, has some
real problems when common repeating decimals get into your calculations --
like .333 for instance. Your performance is highly variable depending on how
hard it is to keep track of the numbers you're using.
Ok, so that's more of a tutorial than I intended to provide, but I guess I'm
in a wordy mood today.
If you're still on sloppy ground, try this:
http://www.cs.utah.edu/~zachary/isp/applets/FP/FP.html
Then have a read of the FAQ at:
http://www2.hursley.ibm.com/decimalj/decfaq.html
They may not be any more articulate than I was, but if you get a couple
different people trying to explain it, it's sometimes easier to triangulate
the truth that lies between. :)
Thanks,
--G.
---
Geoff Gerrietts <ge...@homegain.com>
Software Engineer, HomeGain.com
510-655-0800 x4320
Don Dwiggins
> My question for you is : What about J2EE makes it so great? What
> are the features that you really need/want? Why not start an
> "Enterprise Python" spec, or something, to provide those features in
> Python? If J2EE is the main reason to use Java (excluding the reason
> in your next section), then let's take all the good ideas from it and
> make them part of Python too. If Python had "PyEE" then it might be
> easier to sell to management <grin>.
How about "EnterPy"? Easy to say, and fits nicely with Starship Python...
--
Don Dwiggins "Solvitur Ambulando"
Advanced MP Technology
dw...@advancedmp.net
Courageous
>They all involve numbers with points in them.. and when you do math
>with them, the answers may be different. That's about the extent
>of my knowledge.
While I'm sure you didn't mean it this way, I took the whole of your
post as a rather damning condemnation. This sort of confusion is
major bad mo-jo.
C//
D-Man
| D-Man writes:
| > My question for you is : What about J2EE makes it so great? What
| > are the features that you really need/want? Why not start an
| > "Enterprise Python" spec, or something, to provide those features in
| > Python? If J2EE is the main reason to use Java (excluding the reason
| > in your next section), then let's take all the good ideas from it and
| > make them part of Python too. If Python had "PyEE" then it might be
| > easier to sell to management <grin>.
|
| How about "EnterPy"? Easy to say, and fits nicely with Starship Python...
I like that. (I used to watch Star Trek: The Next Generation
sometimes and some of the newer ones occasionally)
-D
Grant Edwards
>The big problem with binary FP is that most people (myself
>included) don't know when to expect approximation rather than
>an exact result.
Always expect an approximation. Surprise is one of the 3 main
weapons of floating point...
The secret to using binary floating point successfully is to
_never_ expect an exact result and not to use binary floating
point if you require an exact result.
You may thing that 1.0 + 2.0 == 3.0 ought to be true, but you
should always treat floating point operations as if there are
small random numbers being thrown in at every step. So you
should check for
fabs((1.0 + 2.0) - 3.0) < [a small number]
Choosing the value for [a small number] is left as an exercise
for the reader.
--
Grant Edwards grante Yow! Did you find a
at DIGITAL WATCH in YOUR box
visi.com of VELVEETA??
Alex Martelli
news:slrn9hgpmo...@tuxtop.visi.com...
...
> _never_ expect an exact result and not to use binary floating
> point if you require an exact result.
>
> You may thing that 1.0 + 2.0 == 3.0 ought to be true, but you
And it is (on any FP system respecting IEEE 754 -- and any
other FP system I've ever heard about).
> should always treat floating point operations as if there are
> small random numbers being thrown in at every step. So you
I think this is exactly what Kahan describes as one of the
widespread (and false) myths about floating point.
Alex
Martijn Faassen
I meant my post to be humorous. I'm not condemning the need to have
predictable rounding behavior when dealing with money, and I am not
condemning the need to have fast floating point calculations. I'm
also not condemning the need to have predictable-to-newcomers
behavior. I think that'd give a motivation for decimals, plain-old-floats and
rationals.
I think the confusion can be minimized by clear documentation, just like
the confusion about unicode (so many encodings) can be.
The 'kinds' PEP is interesting in this respect as well. I haven't studied
it, but it seems to promise some unification in all this, which would be
good. I think it's important who are interested in adding different types
of floats to Python consider this or a like-minded proposal (the ability
to easily switch an entire calculation to using a different type of
floating point number, the ability to have Python complain instantly when you're
not mixing them right).
Geoffrey Gerrietts
Martijn writes, sometimes quoting me:
> Ah, a powerful query system, then. Difficult, too. Could you give
> a real life example of an actual arbitrary retrieval system? It's
> not full-text-search search, right? (the ZCatalog I believe already
> can do something like that, on multiple attributes).
Arbitrary and full-text are more or less identical. I can't speak
competently about ZCatalog. If it's got it, that's great -- but
I'm not sure what it is exactly, or how effective or efficient it
is to use that on a collection of large text. :)
> > I can't speak to how easy it is to move from one app server to
> > another. I /can/ speak for how much of the "hard work" is done
> > for you by some of these enterprise containers -- a whole lot!
>
> Could you go into some more detail on this? I've heard this
> more often,
> but I'm still not entirely clear on *what* work is done. :)
I think the meat of the response lies in answering this question.
I'm going to try to answer it first in regards to JSP and
servlets, and I'm going to mix in some of the J2EE stuff near the
end. I'm nowhere near as proficient with J2EE as I am with the
other two.
Meanwhile, others will I'm sure jump in and correct me where I'm
wrong. Or I /hope/ they will, because I'm sure to be wrong. :)
First, one framing quote:
> I'm not interested in promoting a standard, I'm just interested in
> stealing ideas for Python-based APIs. I'm not interested in
> standardizing these APIs. :)
That frames my first issue.
-----
STANDARDIZATION
-----
I think that's a big part of what's great about these API's.
They're standard! It's not just a question of whether you can
find a Java programmer or whether you can find a Python
programmer. The languages are not really a significant factor, so
much as the toolsets.
Finding Zope programmers is /hard/. Finding someone who's had
experience with WebSphere or WebLogic or one of the other servlet
containers is /easy/. The APIs are standard. Maybe they won't
develop their app in exactly the same way you developed yours,
but the odds are pretty good they'll be similar -- they're based
on the same APIs, making use of the same mechanisms.
Is it harder to cull the grain from the chaff when selecting
these programmers? Maybe. But it's easier to let go of someone
you have, than to hold on to someone you don't.
I hafta grant that standardization is in some ways problematic.
Bad standards can bestow ruin as easily as good ones can bestow
greatness. (Just look at C++! <wink>)
The Java servlet and JSP standards are pretty good, and I think
the J2EE stuff is pretty good, too. The standards are evolving in
a fairly nondestructive manner, and addressing some of the issues
left outstanding.
-----
REQUEST-CENTERED FRAMEWORK
-----
When I'm developing under Zope, I start with a page and work
back from that. It's possible to determine from the request which
bit of content to serve up -- you either make a conditional page,
or you stick a bit of code at the top of the page that does
redirection based on the contents of the request object.
That's reasonable, and it makes sense to people who have done
lots of server-side scripting. I think PHP and ASP kinda
encourage this sort of coding. You can do it with the Java
products too -- you just use JSP to develop your page content,
and bang-presto, you've got a page-centered application.
I don't want a page-centered application; in fact, I would go so
far as to say that page centering breaks the MVC (model / view /
controller) paradigm that I aspire toward in my software designs.
The way Zope is set up, it seems to me that it encourages a
design that embeds controller elements in the view.
You can hack around that; that's true. But it's a hack, and it's
not the "natural" way to program. Zope is set up to support (and
support well!) content with dynamic elements.
With a pure JSP site, you're still going to be hacking. You can
do some things to clean up the hack and make it less crude, but
JSP is like PHP or Zope: it's page-centered.
When you add servlets to the mix, though, you start eking your
way into deeper potential. Instead of requests being aimed at
your view components, requests are aimed at a servlet. The
servlet is invoked via routines that are designed to handle a
request. The objects associated with the request are a little
more "primitive" than the objects you pull out of Zope, but they
are handled in a fairly elegant fashion.
Having the servlet in charge of processing the request puts the
control into the controller, if you will. It makes it easy for
the app to center around the controller logic, without relying on
the view logic to hand over the reins.
Model/View/Controller separation is a topic of some discussion in
servlet circles. I think the jury's still out on the best way to
do it. I think that one of the more common solutions uses JSP as
the view components, servlets as the controller components, and
beans as the model components, with various and sundry utilities,
factories, and other classes thrown in to stitch it all together.
Do I need to define these? JSP is a lot like PHP or DTML -- you
write Java code in the page. Servlets have access to the request
directly, as well as repositories for session, request, and
application state. Beans are basically just any old object, but
with properly-named accessors and mutators for all public
attributes. When you move from a simple servlet container to an
enterprise servlet app, Enterprise Java Beans effectively take
the place of the Beans (though you can still use simple beans
locally). Let's talk about these components and their features in
a little more depth.
-----
JSP FEATURES
-----
Like I said, JSP is much like DTML or PHP in appearance. JSP has
a few "directives" that you can use to apply general processing
rules to your page. Of particular interest:
Your JSP pages get compiled into a servlet. I think that makes
them pretty fast when compared with something that does page
interpretation at request time.
Your JSP pages have access to at least four levels of state
(there might be another I'm forgetting): application, session,
request, and page. The first three correspond to the same state
repositories managed by the servlet. The 'page' context is for
local objects.
You can forward control to other servlets or JSP pages, and you
can also include pages. I believe (though I'm not sure I've
tested this) that a page you forward to gets a fresh "page"
context, while an include uses the current page context. Also,
forward is terminal, while an include will return control after
processing the child. Not too revolutionary here, but the
features are present.
You can embed Java. In fact, that's the way you do your
conditional display, and almost everything else interesting. This
can look kinda goofy in practice, but it does increase ease of
use.
You can associate a bean with an object, and map form properties
onto the bean's attributes. I think that this is most useful when
you're programming pure JSP, but it's pretty useful when you're
not.
You can create "custom tag libraries" for a more abstract and
less "page-centered" approach to reusable page content. Custom
tag libraries are more Java-centric than markup-centric.
-----
SERVLET FEATURES
-----
Most of what you get out of servlets is also available indirectly
in JSP if you jump through the right hoops. For pieces of the
application that don't need to display, though, there's not much
sense in hopping through the hoops -- it can be downright
annoying to need to. That's what makes servlets "natural" for the
controller component.
I've discussed session management before. Sounds like they're
doing some of that in newer Zope? That's good. It's a very hard
thing to do well. I would be concerned about ZEO and ZODB being
used in their unadulterated form to handle session management for
a high traffic site. It just seems like there'd be too much I/O
for ZODB/ZEO to handle it efficiently.
Servlet containers implement session management for you. The
servlet containers are presently not obliged to make these
sessions either persistent or distributable, but some of them do,
including at least one of the freely-available containers.
Persistent, distributable sessions provide good load balancing
and good failover.
Servlets get a request and a response object passed to them.
Generally you manipulate both. The request object has a list of
parameters and also a list of attributes. The former are
generally the form values while the latter is where you might
store state to pass it between servlets or between a servlet and
a JSP page.
Servlets can dispatch a request using either a forward or an
include, just like in JSP.
The container's handling of a servlet (or entire web app, which
is generally a bunch of servlets and lots of supporting pages) is
controlled by the "deployment descriptor", a file called web.xml.
This file has a standard, mandated format. It gives the developer
a great deal of control over how his or her servlet will be
instantiated, and how it will be managed once in memory.
Once written, a web application can be packed up into a .war file
(analogous to a .jar file) for easy deployment. The first time
the app is accessed, the .war file is unpacked. That makes
deployment remarkably (almost disgustingly) simple.
-----
ENTERPRISE JAVA BEANS
-----
The 'enterprise' in the J2EE stuff basically means "designed for
large and diverse environments" I think. When the word was first
used in the phrase "enterprise networking" it usually referred to
the challenges involved in getting Macs, PCs, and other hardware
all talking on the same LAN. These days, that's a non-problem.
Now enterprise generally seems to refer to anything of large
scope, and particularly applications distributed across multiple
pieces of hardware. But I think the "what the hell does that
mean" camp may have a point here. :)
Adding EJB entails a few sacrifices and a few big gains. Sticking
your servlets into the J2EE "framework" means that you hafta put
your "application" level state into an EJB or a database (or at
least knowing that anything you stick into the application
storage can't be counted on to persist any longer than the
request). You really need to make anything you put into the
session area serializable (though there are a couple exceptions
to that rule). There are a couple other rules that go along with
that, I can't put fingers on them off the top of my head. All the
sacrifices are really pretty minimal.
The big gains: you get the distribution and persistence of
sessions. That's a hard thing to do well. Your servlets load
balance across all the servers that are running them. That's a
pretty big win, too -- that's also pretty hard to do in a
reliable fashion. And you get the EJB stuff, which means your
backend model objects pretty much distribute themselves with no
real additional design effort -- the binding mechanism is all
there, the publication mechanism, the lookup mechanism. It's all
there.
The J2EE stuff makes deployment still one more step simpler, too.
It pushes parameters that might change during runtime out one
notch further, so that deployment configuration can be separated
from the details of servlet instantiation, URI mappings, and
other miscellany concerning the interaction of the app and the
app server.
There's lots more to the J2EE stuff than what I've identified
here. For where I'm at and the kinds of projects I'm thinking
about, it's enough to use a servlets + JSP + simple beans
architecture. The kinds of projects I'm thinking about and
drafting start small -- start out living on a single server. But
by following a half-dozen simple design principles (most of which
you'd pretty much follow anyway), moving a web app from servlets
and JSPs into a full J2EE app is a (fairly) straightforward
affair. I suspect (though I haven't had the chance to put it to
the test yet) that an app set up to use beans heavily could
pieces of the model re-written to capitalize on the J2EE features
without touching any of the controller or view code.
-----
JAVA DATA OBJECTS
-----
JDO is still in development, so it's maybe not fair of me to talk
about it. But since a good proportion of the Python/Zope
technologies that we're trotting out for comparison are still in
development, I figure I might as well. Like I said once before,
maybe we can beat Java to the punch here.
JDO is a way of mapping an object graph onto a database. I
haven't read the draft of the standard nearly as closely as I
should -- I'm the sort that waits for an implementation to play
with before learning the technology, because that's the way I
learn best. However, I'm told that it bears an uncanny
resemblance to the Enterprise Objects Framework from Apple (and
NeXT before that).
The EOF I've used, and the EOF I can comment on with a fair
amount of accuracy <wink>. The way EOF works, in its most potent
form, is thus: you develop a class with all its accessors and
mutators, plus all the business logic you might want to include.
You map some or all of its data fields to columns in your
database in what's called an entity description. You include
things like relationships to other entities -- does my Employee
entity have a one-to-one relationship with a Boss entity? Model it.
Does my Boss entity have a one-to-many relationship with Employee
entities? Model it.
Fetches can be performed by key, or by selector. Selectors can
pick out individual objects based on the properties of the
objects, or through elaborate path constructions that might trace
through a long series of relationships. An example: you might
fetch all Bosses who have an employee who has a spouse who has a
birthday this month. The selector might look something like:
employees.spouse.birthday.month == now.month
When you fetch these objects from the database, the EOF puts
"Faults" in the place of relationships. When you first try to
read from a fault object, it runs off and fetches the object from
the database.
But that's not all! EOF also provides sophisticated caching and
data source controls. EOF also provides multiple 'editing
contexts' with undo capabilities and the ability to nest editing
contexts so that changes can be made within the context of other
changes, and committed incrementally, or abandoned en masse.
EOF is a powerful tool for management of object graphs and
mapping the object graph onto the database. If even a fraction of
the power EOF offers developers comes through in JDO, that will
be a huge boon to anyone who works with a sophisticated dynamic
data model.
-----
AND HERE IT IS AGAIN...
-----
The best part of it all is that all the things outlined above are
STANDARD. They're part of the API. When programmers learn
WebLogic or WebSphere or Tomcat or Enhydra or whatever else, they
learn to develop to the servlet API. JSP is an extension of the
servlet API; it's a five-minute lesson taught to a servlet
programmer, or a gentle introduction to an HTML hacker.
Sure, your webapp may do some funky things with the technology,
and the way you do MVC might be different, and maybe you've got a
toolkit or two that you've integrated or a different templating
engine. But the core of the architecture is the same, and the
application is as simple or as complex as you make it from there.
I choose to keep it simple, and I choose to write the code so
that it's easily extended toward J2EE in case I need that kind of
robustness. For now, a single server running a servlet container
is good enough, and in the immediate future, that breaks out
quite nicely into a database server and maybe Enhydra on the
front end running on a couple boxes. If the load continues to
grow, though, I may need to go to a full-fledged J2EE model, and
pull the backend objects out onto their own machines so that the
servlet machines only hafta worry about processing requests. I've
got lots of room to grow, and the upgrade path is very clear.
Meanwhile, the API's required are standardized and well-known.
I'm pretty confident that someone who's developed web apps under
the servlet API could grasp my architecture and start
contributing within a day, two at the worst. I'm pretty confident
that someone who knows a bit of Java could climb on board inside
a week and be adding significant features.
What's more, I'm pretty confident that if I was on another
project when the customer needed work done, my attentions might
not even be necessary.
I will note, in closing, that recent days have been something of
a reawakening of faith in the darkened halls of my soul. Sunlight
has begun to break through the clouds as I consider Python all
over again. I have enjoyed this discussion a great deal, and
enjoyed most of all that it has stirred my humility some -- I
haven't seen all there is to see in the Python world, and much of
what I haven't seen is quite promising.
Thanks! :)
--G.
Geoffrey Gerrietts
corrected privately, and wanted to correct myself publicly lest I mislead
someone. I try not to play fast and loose with the facts, but my
explanations sometimes exceed my understanding <wink>.
Fixed-point is scaled in advance. This means that you do not need to track
the scaling factor: since everything is being done to the same scale,
there's just one scaling factor. You scale all your numbers for storage and
calculation, then move the decimal point back when you want to display them.
Rational numbers are tracked as a numerator and denominator, nothing more
complicated than that. The danger with rational numbers is that they require
a lot of storage space, and that the integers involved sometimes get really,
really big. I'm told that you can't reasonably limit the size of the
integers, either, because if you do, your accuracy will suffer even worse
than if you'd stuck to floats. I guess that means that asking for the answer
to exactly the right question could result in a single absolutely enormous
number, and it could take a very long time to arrive at that number.
I was also informed that when a float and a rational are combined, that the
result should be coerced to a float, because the rational is accurate and
the float is an approximation.
I would credit the source of all this fine information, but I think that
doing so without his permission is something of an ethical violation, since
he sent a private reply? Anyway, I wanted to correct myself soon, so I'll
thank him when I'm allowed. :)
Thanks,
--G.
Grant Edwards
>> _never_ expect an exact result and not to use binary floating
>> point if you require an exact result.
>>
>> You may thing that 1.0 + 2.0 == 3.0 ought to be true, but you
>
>And it is (on any FP system respecting IEEE 754 -- and any
>other FP system I've ever heard about).
I know that it is. But when you start depending on that fact,
you're doomed.
>> should always treat floating point operations as if there are
>> small random numbers being thrown in at every step. So you
>
>I think this is exactly what Kahan describes as one of the
>widespread (and false) myths about floating point.
Of course it is not true. But if you pretend it is, you've got
a much better chance of producing working code.
--
Grant Edwards grante Yow! And furthermore,
at my bowling average is
visi.com unimpeachable!!!
E. Mark Ping
Grant Edwards <gra...@visi.com> wrote:
>On Sat, 2 Jun 2001 09:42:34 +0200, Alex Martelli <ale...@yahoo.com> wrote:
>>And it is (on any FP system respecting IEEE 754 -- and any
>>other FP system I've ever heard about).
>
>I know that it is. But when you start depending on that fact,
>you're doomed.
That's silly and just plain wrong. You should depend on understanding
how FP works. And in this case, 1.0 + 2.0 == 3.0 every time on every
platform that I've run into--I don't know that because I just happened
to try it out, but rather I know how the FP works on those platforms
and know that it is correct.
>>> should always treat floating point operations as if there are
>>> small random numbers being thrown in at every step. So you
>>
>>I think this is exactly what Kahan describes as one of the
>>widespread (and false) myths about floating point.
>
>Of course it is not true. But if you pretend it is, you've got
>a much better chance of producing working code.
You should definitely read Pete Becker's articles in the June, July
and October 2000 issues of The C/C++ Users Journal. He explains why
you're statement is insufficient and incorrect. For instance, two
very large numbers might really be the same, but be off by a bit.
Checking the difference of the values will yield another large number,
and a method like "IsCloseTo" will incorrectly fail.
Really, floating point arithmetic has well-defined semantics; guessing
and treating them as if they have random components is the lazy and
error-prone way to use them.
--
Mark Ping
ema...@soda.CSUA.Berkeley.EDU
Grant Edwards
>>I know that it is. But when you start depending on that fact,
>>you're doomed.
>
>That's silly and just plain wrong. You should depend on understanding
>how FP works. And in this case, 1.0 + 2.0 == 3.0 every time on every
>platform that I've run into--I don't know that because I just happened
>to try it out, but rather I know how the FP works on those platforms
>and know that it is correct.
So do I. But every time I've seen an application _depend_ on
exact representations, its caused problems. Perhaps the FP
code you've seen was better, but in my experience code that
depends on exact represention has caused problems.
>>>> should always treat floating point operations as if there are
>>>> small random numbers being thrown in at every step. So you
>>>
>>>I think this is exactly what Kahan describes as one of the
>>>widespread (and false) myths about floating point.
>>
>>Of course it is not true. But if you pretend it is, you've got
>>a much better chance of producing working code.
>
>You should definitely read Pete Becker's articles in the June, July
>and October 2000 issues of The C/C++ Users Journal. He explains why
>you're statement is insufficient and incorrect. For instance, two
>very large numbers might really be the same, but be off by a bit.
Huh? They're the same, but they're not the same?
>Checking the difference of the values will yield another large number,
>and a method like "IsCloseTo" will incorrectly fail.
How can it fail? Either A is within X% of B or it isn't.
What's the problem?
>Really, floating point arithmetic has well-defined semantics; guessing
>and treating them as if they have random components is the lazy and
>error-prone way to use them.
I'm not guessing. I know how IEEE floating point works and
have implimented various parts of it over the years. The
applications programmers I've dealt with would have been far,
far better off if they never depended on exact representation.
I'm sure you hang out with a much brighter crowd than I.
--
Grant Edwards grante Yow! Did I say I was a
at sardine? Or a bus???
visi.com
Alex Martelli
news:9fb5fl$26kf$1...@agate.berkeley.edu...
...
> Really, floating point arithmetic has well-defined semantics; guessing
> and treating them as if they have random components is the lazy and
> error-prone way to use them.
It's ONE lazy and error-prone way; another one is not keeping
the possible errors and approximations always in one's mind
(and there are others yet, but those are the main two, I think).
I think they're widespread. I've been guilty of both (and yet
others besides) at various points in my life and career, and I do
not personally know anybody (who has done significant numerical
programming) who can claim he has never been guilty of either
while looking at me eye to eye and keeping a straight face (there
must be such people somewhere, I'm sure -- just not in my circle
of real life acquaintances).
Alex
E. Mark Ping
Alex Martelli <ale...@yahoo.com> wrote:
>It's ONE lazy and error-prone way; another one is not keeping
>the possible errors and approximations always in one's mind
>(and there are others yet, but those are the main two, I think).
Too true, actually. It's more common to simply pretend the issue
doesn't exist, from what I've seen.
>I do
>not personally know anybody (who has done significant numerical
>programming) who can claim he has never been guilty of either
>while looking at me eye to eye and keeping a straight face (there
>must be such people somewhere, I'm sure -- just not in my circle
>of real life acquaintances).
Granted. We've all been sinners in the past. But that's not the same
as *advocating* it.
--
Mark Ping
ema...@soda.CSUA.Berkeley.EDU
E. Mark Ping
Grant Edwards <gra...@visi.com> wrote:
>On Sat, 2 Jun 2001 16:49:58 +0000 (UTC), E. Mark Ping
><ema...@CSUA.Berkeley.EDU> wrote:
>>That's silly and just plain wrong. You should depend on
>>understanding how FP works. And in this case, 1.0 + 2.0 == 3.0
>>every time on every platform that I've run into--I don't know that
>>because I just happened to try it out, but rather I know how the FP
>>works on those platforms and know that it is correct.
>
>So do I. But every time I've seen an application _depend_ on exact
>representations, its caused problems. Perhaps the FP code you've
>seen was better, but in my experience code that depends on exact
>represention has caused problems.
Ah, but your example was exact representation of *integers*, not just
any value.
>>You should definitely read Pete Becker's articles in the June, July
>>and October 2000 issues of The C/C++ Users Journal. He explains why
>>you're statement is insufficient and incorrect. For instance, two
>>very large numbers might really be the same, but be off by a bit.
>
>Huh? They're the same, but they're not the same?
Sorry I didn't state it very clearly. I meant that two values might
have been arrived at by different computation paths and be different
only because of limitations of FP. That is, had they not been limited
by finite precision, they would be the same value.
>>Checking the difference of the values will yield another large
>>number, and a method like "IsCloseTo" will incorrectly fail.
>
>How can it fail? Either A is within X% of B or it isn't. What's the
>problem?
But your algorithm didn't specify %, rather you said:
fabs((1.0 + 2.0) - 3.0) < [a small number]
If it were percentage, you'd be adding a division operation too.
That's getting to be a large amount of overhead.
The point is to understand FP well enough to use it correctly in your
particular code. Sometimes that may be exact representation,
sometimes not.
>>Really, floating point arithmetic has well-defined semantics;
>>guessing and treating them as if they have random components is the
>>lazy and error-prone way to use them.
>
>I'm not guessing. I know how IEEE floating point works and have
>implimented various parts of it over the years. The applications
>programmers I've dealt with would have been far, far better off if
>they never depended on exact representation.
The reason I said "guessing" was because you claimed that:
>>>Of course it is not true. But if you pretend it is, you've got a
>>>much better chance of producing working code.
When your code should never have a "chance" of working. It should be
correct and you should know why. Again, I realize that we've just
about all knowingly taken chances in the past, but that's not the same
as advocating it.
--
Mark Ping
ema...@soda.CSUA.Berkeley.EDU
Grant Edwards
>>>Checking the difference of the values will yield another large
>>>number, and a method like "IsCloseTo" will incorrectly fail.
>>
>>How can it fail? Either A is within X% of B or it isn't. What's the
>>problem?
>
>But your algorithm didn't specify %, rather you said:
>
> fabs((1.0 + 2.0) - 3.0) < [a small number]
>
>If it were percentage, you'd be adding a division operation too.
>That's getting to be a large amount of overhead.
I did say that choosing the value of [a small number] was left
as an exercies for the reader. In some cases it must be an
absolute value, in other cases relative to the values being
compared -- obviously it depends on the system requirements.
--
Grant Edwards grante Yow! Look into my eyes and
at try to forget that you have
visi.com a Macy's charge card!
Grant Edwards
>>So do I. But every time I've seen an application _depend_ on exact
>>representations, its caused problems. Perhaps the FP code you've
>>seen was better, but in my experience code that depends on exact
>>represention has caused problems.
>
>Ah, but your example was exact representation of *integers*, not just
>any value.
What I've seen happen: code is written by a programmer who
knows that the input values are going to be integer values that
can be represented exactly. It works fine for a few years.
Then the system requirements are changed slightly and an input
that was previously integer valued, is now non integer-valued.
Or the input scaling is changed so that the integral values can
no longer be represented exactly. In either case, the system
stops working right.
If the original design hadn't assumed exact representation, the
problem is avoided.
--
Grant Edwards grante Yow! I'm CONTROLLED by
at the CIA!! EVERYONE is
visi.com controlled by the CIA!!
Tim Peters
> ...
> Rational numbers are tracked as a numerator and denominator, nothing
> more complicated than that. The danger with rational numbers is that
> they require a lot of storage space, and that the integers involved
> sometimes get really, really big.
They *can*, and that can make them as surprising to newbies as anything
else. OTOH, sometimes they don't <wink>. For example, let's imagine a
hypothetical Python using rational arithmetic, and a newbie computing
sum = 0
for i in range(1, 101):
sum += 1/i
It can be very surprising at first that the result is
14466636279520351160221518043104131447711
-----------------------------------------
2788815009188499086581352357412492142272
In floating-point instead they'd get
5.1873775176396206
and much quicker. OTOH, it may be years before they learn (and perhaps "the
hard way") that adding the reciprocals from largest to smallest is
numerically worse than adding them in the other direction under f.p. (and
whether binary or decimal) -- but it doesn't matter at all under rationals.
On the third hand, if you're just adding dollars-and-cents things under a
rational system, all the denominators are the same and then nothing "gets
real big" under the covers (the denominator of the final result won't be
larger than 100).
Unfortunately, *all* finite representations of reals suffer surprises, some
gross, some subtle. If you have more than one choice, you need some amount
of expertise to choose wisely, and no single system is best for all
purposes.
> I'm told that you can't reasonably limit the size of the integers,
> either, because if you do, your accuracy will suffer even worse
> than if you'd stuck to floats.
Eh -- highly debatable. Much work has been done on so-called "floating
slash" (or "flash") systems, but they still have a specialized audience. If
there are physical reasons to suspect the true results are relatively simple
fractions, they can beat the accuracy pants off of f.p. But for newbies
they (IMO) combine the worst of all worlds: exact results in simple cases,
but "suddenly and for no reason at all" <wink> inexact results creep in
without warning.
> I guess that means that asking for the answer to exactly the right
> question could result in a single absolutely enormous number, and
> it could take a very long time to arrive at that number.
This was a common newbie experience in ABC (a language Guido worked on
before Python, where all arithmetic was rational by default). In "serious
work", just as experts need to keep track of worst-case error bounds in f.p.
arithmetic, when using rational arithmetic for problems where exact results
aren't required, experts need to keep track of worst-case *size* bounds and
explicitly round back at appropriate points to keep computation time
tractable.
a-fast-answer-is-useless-if-it's-wrong-but-an-exact-answer-is-useless-
if-you-can't-get-it-by-the-time-it's-needed-ly y'rs - tim
Phil Martel
> Martijn writes:
> > So there's fixed-point, decimal floating-point and rational
> > arithmetic..
> > And plain-old-confusing floats. :)
> >
> > They all involve numbers with points in them.. and when you do math
> > with them, the answers may be different. That's about the extent
> > of my knowledge.
>
>
> Here's a five minute explanation, and maybe I can dig up a link to a quick
> tutorial on FP in general. (Ok, maybe it's more like a fifteen-minute
> explanation. Somebody stop me!) Someone who knows better ought to correct
me
> if I'm talking out my butt.
>
> =====
> Unbounded rationals
> =====
>
> Unbounded rationals would basically give the language the power to express
> any rational number accurately. I confess that I'm not sure how it would
go
> about doing that exactly. I THINK it would do so by maintaining an
internal
> representation of the operation that gives rise to an infinitely-repeating
> decimal, and use that expression in conjunction with known mathematical
> properties to join in expressions with other values.
>
> This is pretty complicated to do, and, according to several people, has
some
> real problems when common repeating decimals get into your calculations --
> like .333 for instance. Your performance is highly variable depending on
how
> hard it is to keep track of the numbers you're using.
>
variables, "Numerator" and "Denominator". For unbounded rationals, they
should be long integers. Arithmetic operations are done like fractional
arithmetic. Using the notation N/D to represent the unbpunded rational with
Mumerator = N and Denominator = D,
Addition: A/B + C/D = (A * D + B * C)/(B * D)
Multiplication: A/B * C/D = (A * C)/(B * D)
Division: A/B / C/D = A/B * D/C = (A * D)/(B * C)
It is traditional, though not absolutely necessary, to remove any common
factors from the Numerator and Denominator, thus:
1/6 + 1/4 = (1 * 4 + 6 * 1 )/(6 * 4 ) = 10/24 which would reduce to 5/12
If you use rational arithmetic, you avoid repeating decimals. 0.333333 is an
approximation for 1/3
Best wishes,
--Phil Martel
Martijn Faassen
>> Ah, a powerful query system, then. Difficult, too. Could you give
>> a real life example of an actual arbitrary retrieval system? It's
>> not full-text-search search, right? (the ZCatalog I believe already
>> can do something like that, on multiple attributes).
> Arbitrary and full-text are more or less identical. I can't speak
> competently about ZCatalog. If it's got it, that's great -- but
> I'm not sure what it is exactly, or how effective or efficient it
> is to use that on a collection of large text. :)
I'm not entirely sure if it can do full-text on all attributes at
once (though that's relatively easy to fix, though the order of
the result set may make not much sense), but it can do full-text
on a single attribute. I haven't got much experience with it either,
so I can't tell you much more. :)
>> > I can't speak to how easy it is to move from one app server to
>> > another. I /can/ speak for how much of the "hard work" is done
>> > for you by some of these enterprise containers -- a whole lot!
>>
>> Could you go into some more detail on this? I've heard this
>> more often,
>> but I'm still not entirely clear on *what* work is done. :)
> I think the meat of the response lies in answering this question.
Good, as it's my main question. :)
> I'm going to try to answer it first in regards to JSP and
> servlets, and I'm going to mix in some of the J2EE stuff near the
> end. I'm nowhere near as proficient with J2EE as I am with the
> other two.
Just a random note; I heard that WebWare for Python looks quite a bit
like "that Java stuff", at least in inspiration, so it may be interesting
for you to take a look at it.
> Meanwhile, others will I'm sure jump in and correct me where I'm
> wrong. Or I /hope/ they will, because I'm sure to be wrong. :)
> First, one framing quote:
>> I'm not interested in promoting a standard, I'm just interested in
>> stealing ideas for Python-based APIs. I'm not interested in
>> standardizing these APIs. :)
> That frames my first issue.
> I think that's a big part of what's great about these API's.
> They're standard!
[standardization can be good and helps you find people]
Agreed; makes sense. It's just that I personally am more interested in
the other stuff, not that fact that it's standard. I can't do much to
make something a standard anyway, so I'll just look at stealing the ideas.
The better the Python stuff gets, the more likely it is there are more
people that know about it, too, of course.
> -----
> REQUEST-CENTERED FRAMEWORK
> -----
> When I'm developing under Zope, I start with a page and work
> back from that. It's possible to determine from the request which
> bit of content to serve up -- you either make a conditional page,
> or you stick a bit of code at the top of the page that does
> redirection based on the contents of the request object.
Or you can do evil and cool stuff with AccessRules (the whole SiteRoot
stuff).
[snip]
> I don't want a page-centered application; in fact, I would go so
> far as to say that page centering breaks the MVC (model / view /
> controller) paradigm that I aspire toward in my software designs.
> The way Zope is set up, it seems to me that it encourages a
> design that embeds controller elements in the view.
What exactly do you mean by embedding controller elements in the
view? I'm not entirely sure what you'd refer to as the controller here.
[snip]
> When you add servlets to the mix, though, you start eking your
> way into deeper potential. Instead of requests being aimed at
> your view components, requests are aimed at a servlet. The
> servlet is invoked via routines that are designed to handle a
> request. The objects associated with the request are a little
> more "primitive" than the objects you pull out of Zope, but they
> are handled in a fairly elegant fashion.
> Having the servlet in charge of processing the request puts the
> control into the controller, if you will. It makes it easy for
> the app to center around the controller logic, without relying on
> the view logic to hand over the reins.
Hm, yes, I think this makes sense (though it could lead to horrible
URLs). Of course you don't give the details here so I'm not
entirely sure I get the entire picture right.
[Model/View/Controller as JSP/Servlets/Beans]
> -----
> JSP FEATURES
> -----
> Like I said, JSP is much like DTML or PHP in appearance. JSP has
> a few "directives" that you can use to apply general processing
> rules to your page. Of particular interest:
[JSP pages get compiled, not interpreted]
We're not going to accomplish this in Python, though of course you
could still write (possibly with C extensions) a fast interpreter for
web pages in Python. Anyway, we're generally not using Python because
insane speeds are the issue, so while this isn't a major bottleneck for
me I'm not going to bother too much with this.
> Your JSP pages have access to at least four levels of state
> (there might be another I'm forgetting): application, session,
> request, and page. The first three correspond to the same state
> repositories managed by the servlet. The 'page' context is for
> local objects.
Right, in Zope you'd have 'acquired things', session object (if you
have Core Session Tracking or something similar installed), REQUEST
object and folder context, for these. I'm just trying to translate
the concepts.
> You can forward control to other servlets or JSP pages, and you
> can also include pages.
What do you mean by 'forwarding control'? Control of what?
> I believe (though I'm not sure I've
> tested this) that a page you forward to gets a fresh "page"
> context, while an include uses the current page context. Also,
> forward is terminal, while an include will return control after
> processing the child. Not too revolutionary here, but the
> features are present.
Ah, I think I more or less understand. I'm not sure what the use of
forward is compared to include, though. Why'd you ever want to forward
control and never come back? Generate half a page with one JSP page,
and the other with another?
> You can embed Java. In fact, that's the way you do your
> conditional display, and almost everything else interesting. This
> can look kinda goofy in practice, but it does increase ease of
> use.
> You can associate a bean with an object, and map form properties
> onto the bean's attributes. I think that this is most useful when
> you're programming pure JSP, but it's pretty useful when you're
> not.
Right, Zope's REQUEST object does this automatically (the 'form' subobject).
> You can create "custom tag libraries" for a more abstract and
> less "page-centered" approach to reusable page content. Custom
> tag libraries are more Java-centric than markup-centric.
> -----
> SERVLET FEATURES
> -----
> Most of what you get out of servlets is also available indirectly
> in JSP if you jump through the right hoops. For pieces of the
> application that don't need to display, though, there's not much
> sense in hopping through the hoops -- it can be downright
> annoying to need to. That's what makes servlets "natural" for the
> controller component.
Right, in Zope, you'd use Python Scripts (through the web),
External Methods (not through the web) for this. You may want to
bundle them into objects, and use ZClasses or program Python
Zope products. A little bit of Python tends to go a long way, of course,
and it helps to have high-level reusable components like ZSQL methods.
> I've discussed session management before. Sounds like they're
> doing some of that in newer Zope? That's good. It's a very hard
> thing to do well. I would be concerned about ZEO and ZODB being
> used in their unadulterated form to handle session management for
> a high traffic site. It just seems like there'd be too much I/O
> for ZODB/ZEO to handle it efficiently.
They're working on various improvements to that too, of course.
ZODB without undo for sessions for instance. ZODB layered on top of
various stuff, like the berkely database. By default Core Session Tracking
just keeps the sessions in RAM and they expire after a customizable time.
> Servlet containers implement session management for you. The
> servlet containers are presently not obliged to make these
> sessions either persistent or distributable, but some of them do,
> including at least one of the freely-available containers.
> Persistent, distributable sessions provide good load balancing
> and good failover.
Right, the intention in Zope is to do this with ZEO and Core Session
Tracking.
> Servlets get a request and a response object passed to them.
Like Zope's DTML pages, and of course you can pass those along
to Python Scripts or other python code.
> Generally you manipulate both. The request object has a list of
> parameters and also a list of attributes. The former are
> generally the form values while the latter is where you might
> store state to pass it between servlets or between a servlet and
> a JSP page.
Something similar is done with REQUEST. REQUEST.set() can be used
to store state for similar purposes. You can of course also directly
call methods and pass parameters that way. ZPublisher makes some of
that stuff work automatically.
> Servlets can dispatch a request using either a forward or an
> include, just like in JSP.
> The container's handling of a servlet (or entire web app, which
> is generally a bunch of servlets and lots of supporting pages) is
> controlled by the "deployment descriptor", a file called web.xml.
> This file has a standard, mandated format. It gives the developer
> a great deal of control over how his or her servlet will be
> instantiated, and how it will be managed once in memory.
> Once written, a web application can be packed up into a .war file
> (analogous to a .jar file) for easy deployment. The first time
> the app is accessed, the .war file is unpacked. That makes
> deployment remarkably (almost disgustingly) simple.
Neat. With Zope exporting subfolders or simply copying Data.fs is relatively
painless, but you need to copy over any external methods and special
Python products manually, which isn't hard but an extra step.
> -----
> ENTERPRISE JAVA BEANS
> -----
[discussion of what 'enterprise' could mean]
Enterprise is a typical buzzword. :) 'scalable' is a much better word
to use if you want it to use in large evironments, and 'portable' works
fine for diverse environments, I'd say. :)
'Has a lot of features for business use' fits the rest of the buzzword,
I guess.
> Adding EJB entails a few sacrifices and a few big gains. Sticking
> your servlets into the J2EE "framework" means that you hafta put
> your "application" level state into an EJB or a database (or at
> least knowing that anything you stick into the application
> storage can't be counted on to persist any longer than the
> request). You really need to make anything you put into the
> session area serializable (though there are a couple exceptions
> to that rule). There are a couple other rules that go along with
> that, I can't put fingers on them off the top of my head. All the
> sacrifices are really pretty minimal.
Okay, parts of this is a small problem with ZODB as well, of course.
I suspect ZODB makes this even easier, as it exploits Python's
flexibility.
Integration with relational databases is another issue; it'd
be nice if there was a nicer mapping to objects. I believe WebWare has
something like that. (MiddleKit?)
> The big gains: you get the distribution and persistence of
> sessions. That's a hard thing to do well. Your servlets load
> balance across all the servers that are running them. That's a
> pretty big win, too -- that's also pretty hard to do in a
> reliable fashion. And you get the EJB stuff, which means your
> backend model objects pretty much distribute themselves with no
> real additional design effort -- the binding mechanism is all
> there, the publication mechanism, the lookup mechanism. It's all
> there.
Sort of like ZEO with Core Session Tracking. :)
Of course this is still being heavily developed, but it seems to
be getting near offering equivalent features.
> The J2EE stuff makes deployment still one more step simpler, too.
> It pushes parameters that might change during runtime out one
> notch further, so that deployment configuration can be separated
> from the details of servlet instantiation, URI mappings, and
> other miscellany concerning the interaction of the app and the
> app server.
Hm, I'm not sure what this part means, exactly. I can't translate it to
any Zope terms, which is how I tend to think about things, myself.
[scaling from a small server to a large distributed system]
This is definitely neat. One of the things that makes ZEO great too;
it makes multiple distributed object database act like it's just one.
I haven't had to use it either, yet, though.
> -----
> JAVA DATA OBJECTS
> -----
> JDO is still in development, so it's maybe not fair of me to talk
> about it. But since a good proportion of the Python/Zope
> technologies that we're trotting out for comparison are still in
> development, I figure I might as well.
Yes, I'm not trotting them out so much to do 'see, we have that too!',
though there is a component in that, but to learn more about both
by comparing the two, and to see if there are interesting directions
which Zope is missing. I think Java's system works better for
model/view/controller type situations right now; Zope's framework for that
is currently still in design phases. Java also has clear (standardized)
interfaces for it, something which Zope needs a lot more of.
I don't know how to compare ZEO with the scalability features you sketched
out. I would guess it's a question of tradeoffs; which is better probably
depends on your requirements and development style.
> Like I said once before,
> maybe we can beat Java to the punch here.
Python certainly has a lot of flexibility to work in its favor here,
though I don't know if we have the development resources in the
Python/Zope world to go fast on this. These discussions often seem to
devolve into feature wishlists and pie-in-the-sky designing.
That said, I think Digital Creations has got the message that integration
with relational databases is deemed important by Zope users, and
people are of course thinking about this. (in general, we don't seem to be
missing many desired features, though we may not have most of them implemented
yet. That is a good thing to know)
[snip JDO is like EOF]
> The EOF I've used, and the EOF I can comment on with a fair
> amount of accuracy <wink>. The way EOF works, in its most potent
> form, is thus: you develop a class with all its accessors and
> mutators, plus all the business logic you might want to include.
> You map some or all of its data fields to columns in your
> database in what's called an entity description. You include
> things like relationships to other entities -- does my Employee
> entity have a one-to-one relationship with a Boss entity? Model it.
> Does my Boss entity have a one-to-many relationship with Employee
> entities? Model it.
> Fetches can be performed by key, or by selector. Selectors can
> pick out individual objects based on the properties of the
> objects, or through elaborate path constructions that might trace
> through a long series of relationships. An example: you might
> fetch all Bosses who have an employee who has a spouse who has a
> birthday this month. The selector might look something like:
> employees.spouse.birthday.month == now.month
Would this get translated into a query into a relational database?
> When you fetch these objects from the database, the EOF puts
> "Faults" in the place of relationships. When you first try to
> read from a fault object, it runs off and fetches the object from
> the database.
A proxy pattern.
> But that's not all! EOF also provides sophisticated caching and
> data source controls. EOF also provides multiple 'editing
> contexts' with undo capabilities and the ability to nest editing
> contexts so that changes can be made within the context of other
> changes, and committed incrementally, or abandoned en masse.
Does this use relational database transaction features?
(with subtransactions?)
Note that the ZODB can already do transactions with subtransactions;
the interesting bits here seem to be in the relationship modelling and
querying, and the relational database integration. I believe ZPatterns
may be able to do some of this, but I've never looked into them in
detail.
> EOF is a powerful tool for management of object graphs and
> mapping the object graph onto the database. If even a fraction of
> the power EOF offers developers comes through in JDO, that will
> be a huge boon to anyone who works with a sophisticated dynamic
> data model.
Yes, sounds very interesting. I'll keep this in mind when I think about
relational database integration in Zope. It's certainly been a fairly hot
topic recently. Perhaps I should point some Zope folks to your post. :)
[reiteration that standard APIs are important]
*part* of the good effects you attribute to standard APIs can be
dealt with by good API *documentation* instead. Another part deals with
user interface; I do think Zope's web UI helps people who have little
programming experience tremendously; I've seen this happen several time.
A hot topic in the Zope world has to do with explicit interfaces,
and clear documentation for them. This inspired PEP 245, currently
under consideration for 2.2. While I don't agree with some of
the details of that PEP, I do think the ability to have a form
of explicit interfaces (run time checked if checked for at all!
ability to lie about implementing an interface! this is Python :)
is very important to the future health of Zope and similar large
Python systems.
http://python.sourceforge.net/peps/pep-0245.html
> I will note, in closing, that recent days have been something of
> a reawakening of faith in the darkened halls of my soul. Sunlight
> has begun to break through the clouds as I consider Python all
> over again. I have enjoyed this discussion a great deal, and
> enjoyed most of all that it has stirred my humility some -- I
> haven't seen all there is to see in the Python world, and much of
> what I haven't seen is quite promising.
> Thanks! :)
And thank you for your extensive description! It must have been a lot of
work writing it, but I certainly enjoyed reading about it. I have a much
clearer idea of what Java's web application architecture is all about
now, and how it maps to systems like Zope. For some time I've been
very interested in making Zope's component model work better by
having explicit interfaces and model/controller/view type abstractions.
It's certainly been very interesting to hear how other systems have
approached these issues.
Bob Drzyzgula
On Sat, Jun 02, 2001 at 09:52:57PM +0000, Grant Edwards wrote:
> On Sat, 2 Jun 2001 21:28:45 +0000 (UTC), E. Mark Ping <ema...@CSUA.Berkeley.EDU> wrote:
>
> >>So do I. But every time I've seen an application _depend_ on exact
> >>representations, its caused problems. Perhaps the FP code you've
> >>seen was better, but in my experience code that depends on exact
> >>represention has caused problems.
> >
> >Ah, but your example was exact representation of *integers*, not just
> >any value.
>
> What I've seen happen: code is written by a programmer who
> knows that the input values are going to be integer values that
> can be represented exactly. It works fine for a few years.
One occasionally useful source of solid thought on this
issue is of course Knuth's Seminumerical Algorithms,
Chapter 4, "Arithmetic". Knuth goes so far as to refuse to
use the normal operators +, -, x and / for floating point
operations (from Section 4.2.1, 3/e):
Since floating point is inherently approximate, not
exact, we will use "round" symbols [graphic of the
normal operators with circles drawn around them] to
stand for floating point addition, subtraction...
At the beginning of section 4.2.2, he goes on:
Floating point computation is by nature inexact, and
programmers can easily misuse it so that the computed
answers consist almost entirely of "noise". One of the
principal problems of numerical analysis is to determine
how accurate the results of certain numerical methods
will be. There's a credibility gap. We don't know
how much of the computer's answers to believe. Novice
computer users solve the problem by implicitly trusting
the computer as an infallible authority; they tend
to believe that all digits of a printed answer are
significant. Disillusioned computer users have just
the opposite approach; they are constantly afraid that
their answers are almost meaningless. Many serious
mathematicians have attempted to analyze a sequence of
floating point operations rigorously, but have found the
task so formidable that they have tried to be content
with plausibility arguments instead.
Knuth of course goes on to explain, in mind-numbing
detail, *exactly* "how much of the computer's
answers to believe"...
That chapter also includes around eighty pages on
rational arithmetic, FWIW.
Yes-i'm-new-to-this-list-please-don't-hit-me-ly y'rs,
--Bob Drzyzgula
Nick Perkins
"Tim Peters" <tim...@home.com> wrote in message
news:mailman.991519987...@python.org...
[ paraphrased ]
> > Rational numbers can be as surprising to newbies as anything else...
Indeed.
>>> from math import *
>>> sqrt(2)**2
2.0000000000000004
>>> sin(pi)
1.2246063538223773e-016
Neither of these 'errors' would be eliminated by using Rationals.
I am sure there are many similar examples.
note that:
>>> cos(pi)
-1.0
actually works, for some reason (luck?)
Thomas Wouters
> sum = 0
> for i in range(1, 101):
> sum += 1/i
> In floating-point instead they'd get
>
> 5.1873775176396206
This must be a very hypothetical python, given that in current Python they'd
get
1
instead <nudge/wink>.
--
Thomas Wouters <tho...@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Huaiyuan
> On Sat, Jun 02, 2001 at 06:12:59PM -0400, Tim Peters wrote:
> > sum = 0
> > for i in range(1, 101):
> > sum += 1/i
>
> > In floating-point instead they'd get
> >
> > 5.1873775176396206
>
> This must be a very hypothetical python, given that in current Python they'd
> get
> 1
> instead <nudge/wink>.
Not hypothetical; but alternative:
CMUCL release x86-linux 2.5.2 18c+ 2 May 2001 build 2174, running on nomad
Send questions to cmucl...@cons.org.
...
Loaded subsystems:
Python 1.0, target Intel x86
* (loop for i from 1 to 100 summing (/ 1 i))
14466636279520351160221518043104131447711/2788815009188499086581352357412492142272
* (coerce * 'double-float)
5.187377517639621d0
Sorry, couldn't resist...
--huaiyuan
Tim Peters
> >>> from math import *
> >>> sqrt(2)**2
> 2.0000000000000004
> >>> sin(pi)
> 1.2246063538223773e-016
>
> Neither of these 'errors' would be eliminated by using Rationals.
> I am sure there are many similar examples.
>
> note that:
> >>> cos(pi)
> -1.0
> actually works, for some reason (luck?)
Floats aren't random -- so luck isn't *really* an issue. What is an issue
is that the mathematical PI isn't exactly representable as a float (and
binary vs decimal has nothing to do with *this* one), so the machine pi is
really some other number,
pi = PI + tiny
where "tiny" is an error in the last bit (or so) introduced by finite
precision. Using angle sum formulas,
sin(pi) =
sin(PI+tiny) = cos(tiny)*sin(PI) + sin(tiny)*cos(PI) =
cos(tiny)*0 + sin(tiny)*(-1) =
-sin(tiny) =
[expanding]
-tiny - tiny**3/6 - ...
tiny**3/6 is too small to have any effect when added to tiny (finite
precision again), so the result you see is plain old -tiny. If you got 0
instead, it would be wrong! If you carry on the example,
>>> math.sin(math.pi)
1.2246063538223773e-016
>>> math.log(_)/math.log(2)
-52.858531444606918
>>>
you can see the result is about 2**-52, right where "it should be" for a
low-bit error in PI given that floats have 53 bits of precision.
For the other one,
cos(pi) =
cos(PI+tiny) = cos(PI)*cos(tiny) - sin(PI)*sin(tiny) =
(-1)*cos(tiny) - 0*sin(tiny) =
-cos(tiny) =
[expanding]
-1 - tiny**2/2 - ...
Since tiny is about 2**-52, tiny**2/2 is about 2**-105, and that's too small
to have any effect when added to the 53-bit value of -1.0. So -1.0 on the
nose is what you get.
Of course sin() and cos() aren't actually *implemented* like that, but a
careful implementation will deliver the same result in the end.
Geoffrey Gerrietts
> Or you can do evil and cool stuff with AccessRules (the whole
> SiteRoot stuff).
> [ ... quotes from me about controller-centered models ... ]
> What exactly do you mean by embedding controller elements in the
> view? I'm not entirely sure what you'd refer to as the
> controller here.
I'm not sure how to manipulate AccessRules; I think this might be
one of the Zope features that we currently hafta do without.
I think maybe I'm running along here under the assumption that
everyone more or less understands Model/View/Controller, and
understands it in the same way that I do. Let me try to define my
terms.
The "View" element of an application is exclusively responsible
for presentation. Your forms and your reports, basically; in a
web application, this is your HTML and the code that generates
your HTML.
The "Controller" element responds to user input and interfaces it
with the business objects of the model. The controller is in
some ways like glue code, but this is (or can be) where you might
have form validation logic, or where you translate your form
fields into the attributes of a data object. The controller
element is typically the center of your application; it might be
compared to the main() function in a C program. It presents
various views when required, retrieves model objects, and glues
them all together.
The "Model" refers to your business objects and your business
logic. The model should describe the data elements in your
problem domain, and should include methods for manipulating them
and performing calculations upon them.
Again, this is my understanding of the MVC super-architecture;
others may have a different take on pieces of it. I know a lot of
people try very hard to push everything down to the model; I tend
to want to keep the logic and data that describes the problem
domain in the model, the stuff that describes the current
application in the controller, and the stuff that implements the
current deployment medium in the view. This promotes maximum
reuse, and makes it easier to re-target your application. Going
to client/server with an applet or even an application written in
SWING isn't exactly trivial, but it's an exercise in rewriting
the view and some of your controller, not a start-from-scratch.
> Hm, yes, I think this makes sense (though it could lead to horrible
> URLs). Of course you don't give the details here so I'm not
> entirely sure I get the entire picture right.
The URLs need not be any more "terrible" than in any other web
application, including any Zope application. If your main servlet
responds to all URLs that begin with '/myapp', any sub-path is
something that the servlet can switch on. The difference here is
that /myapp doesn't map to a folder object either on the
filesystem or in some content repository. It's mapped in the
application server to mean "invoke this servlet"; additional path
information is passed on to the servlet.
So if http://myhost/myapp points at my main controller servlet,
then the "myapp" servlet needs to know what to do when you access
the URL http://myhost/myapp/login. In some cases, it will
directly invoke some action, which will in turn decide whether
this is an initial request or a post of form-values, and then
perform the appropriate processing. That processing may entail
the include of or forward to a JSP page. In other cases, the main
controller servlet may defer handling to another servlet. This is
where your local architecture can grow baroque, especially if you
don't make the decisions about how things will be done up front.
Meanwhile, your controller has the request before anything else.
That means the controller can take action based on form values or
other request parameters. As far as I know, Zope provides a
solution for the most common application of this (user
authentication), but does not provide much in the way of a
toolkit for other similar problems.
An example might be a look-and-feel switch -- if you have a
cobranded application, you might serve from a different batch of
pages, or use decorations and stylesheets from a different
directory hierarchy.
You /can/ do these things in Zope, it just requires hacking
around the way Zope is set up to serve pages, not invoke
processing logic.
> [Model/View/Controller as JSP/Servlets/Beans]
I think Model/View/Controller as Beans/JSP/Servlets is more
accurate, but yes. :)
> [JSP pages get compiled, not interpreted]
>
> We're not going to accomplish this in Python, though of course
> you could still write (possibly with C extensions) a fast
> interpreter for web pages in Python. Anyway, we're generally
> not using Python because insane speeds are the issue, so while
> this isn't a major bottleneck for me I'm not going to bother
> too much with this.
Or you could take your Zope objects and turn them into actual
python code objects that generate HTML and perform some actions
when called. It's not going to suddenly challenge C for
near-hardware speeds, but it's a significant step ahead of
doing the lexical parsing at runtime -- at least the Python
interpreter is written in C.
I don't think it's a huge priority, but it's one of the things
the Java stuff does to reduce runtime load, which in turn
promotes better scaling and better overall peformance.
> > Your JSP pages have access to at least four levels of state
> > (there might be another I'm forgetting): application, session,
> > request, and page. The first three correspond to the same state
> > repositories managed by the servlet. The 'page' context is for
> > local objects.
>
> Right, in Zope you'd have 'acquired things', session object (if you
> have Core Session Tracking or something similar installed), REQUEST
> object and folder context, for these. I'm just trying to translate
> the concepts.
Almost.
I think the acquired things don't map onto application state
quite like you suggest. There's one repository, shared by all the
sessions running inside a single process. This isn't initialized
with web-content properties. It's a place to stick objects at
runtime.
I don't know what the session object gets you, or how it gets it
for you, but I assume that's correct. The REQUEST object does map
to the request context. The page context maps more closely to the
namespace of a DTML document.
> > You can forward control to other servlets or JSP pages, and you
> > can also include pages.
>
> What do you mean by 'forwarding control'? Control of what?
>
> [ snip my explanations ]
>
> Ah, I think I more or less understand. I'm not sure what the use of
> forward is compared to include, though. Why'd you ever want to forward
> control and never come back? Generate half a page with one JSP page,
> and the other with another?
<dtml-return> and RESPONSE.redirect() provide more-or-less
similar functionality in DTML, as compared with the use of
<dtml-var> to include a method.
My typical page processing paradigm is to submit form data to the
page that renders the form. If all the data are acceptable and no
processing errors arise, I forward on to another page. If all the
data are not acceptable, I redisplay the current page with error
messages. Others do it other ways.
> > You can associate a bean with an object, and map form properties
> > onto the bean's attributes. I think that this is most useful when
> > you're programming pure JSP, but it's pretty useful when you're
> > not.
>
> Right, Zope's REQUEST object does this automatically (the
> 'form' subobject).
Except that your "form" subobject is one standard object, not an
object customized for your particular form. The servlet API
allows you to pick the attributes off the REQUEST object, too;
it's just somewhat more convenient to load up a bean.
> > I've discussed session management before. Sounds like they're
> > doing some of that in newer Zope? That's good. It's a very hard
> > thing to do well. I would be concerned about ZEO and ZODB being
> > used in their unadulterated form to handle session management for
> > a high traffic site. It just seems like there'd be too much I/O
> > for ZODB/ZEO to handle it efficiently.
>
> They're working on various improvements to that too, of course.
> ZODB without undo for sessions for instance. ZODB layered on
> top of various stuff, like the berkely database. By default
> Core Session Tracking just keeps the sessions in RAM and they
> expire after a customizable time.
>
> > Servlet containers implement session management for you. The
> > servlet containers are presently not obliged to make these
> > sessions either persistent or distributable, but some of them do,
> > including at least one of the freely-available containers.
> > Persistent, distributable sessions provide good load balancing
> > and good failover.
>
> Right, the intention in Zope is to do this with ZEO and Core Session
> Tracking.
The current solution is a reasonable solution, but it doesn't
scale well. Your front-end load balancing hasta be session-aware,
so it can redirect to the right instance of Zope.
Using ZEO and Core Session Tracking could be The Right Thing. It
certainly seems like the two technologies could be combined
reasonably. Until it's arrived, though, you're still rolling your
own sessions if you deploy on more than one box.
> > Servlets get a request and a response object passed to them.
>
> Like Zope's DTML pages, and of course you can pass those along
> to Python Scripts or other python code.
Yes, but the servlets ARE Java code, which means that you don't
NEED to stick a block of code at the top of every page, designed
to invoke them.
> Neat. With Zope exporting subfolders or simply copying
> Data.fs is relatively
> painless, but you need to copy over any external methods and special
> Python products manually, which isn't hard but an extra step.
Yeah, Zope isn't all that hard to roll out, as long as you do
everything in Zope. You can still get sync problems with the
external dependencies, though. If you use a lot of those (and I
suspect that you will in a logic-intensive app), then you're
likely going to hafta come up with some other deployment
mechanism.
> > Adding EJB entails a few sacrifices and a few big gains. Sticking
> > your servlets into the J2EE "framework" means that you hafta put
> > your "application" level state into an EJB or a database (or at
> > least knowing that anything you stick into the application
> > storage can't be counted on to persist any longer than the
> > request). You really need to make anything you put into the
> > session area serializable (though there are a couple exceptions
> > to that rule). There are a couple other rules that go along with
> > that, I can't put fingers on them off the top of my head. All the
> > sacrifices are really pretty minimal.
>
> Okay, parts of this is a small problem with ZODB as well, of course.
> I suspect ZODB makes this even easier, as it exploits Python's
> flexibility.
Well, except that we're not talking about just ZODB or ZEO here,
we're talking about distributing dynamic (by which I mean
run-time) state. That includes things like concurrent access
issues and synchronization of access, RMI techniques, and
whatever else it takes to implement these things.
It's also not just Session stuff. If you could publish arbitrary
objects to the ZEO store and retrieve them by key -- something
I'm sure is possible, but not sure how difficult -- you'd be
close.
> Sort of like ZEO with Core Session Tracking. :) Of course this
> is still being heavily developed, but it seems to be getting
> near offering equivalent features.
I can't speak to that, because I haven't used (and can't really,
at the moment) Core Session Tracking, let alone using it with
ZEO.
>
> > The J2EE stuff makes deployment still one more step simpler, too.
> > It pushes parameters that might change during runtime out one
> > notch further, so that deployment configuration can be separated
> > from the details of servlet instantiation, URI mappings, and
> > other miscellany concerning the interaction of the app and the
> > app server.
>
> Hm, I'm not sure what this part means, exactly. I can't
> translate it to any Zope terms, which is how I tend to think
> about things, myself.
I might argue that trying to put everything into Zope terms is
part of what's limiting your comprehension. :) Zope is really a
very different animal.
Still, if you were to take your Zope application, and all its
external methods, and all the little mini-servers that helped
distribute your backend processing job, and stuck them all in a
big tar file, then had one configuration file that detailled ALL
the configuration details that would vary from machine to machine
within an installation, and all the details that would vary from
installation to installation -- if you assembled that tarball and
that config file, you'd have the deployment mechanism used by the
Enterprise stuff.
> Yes, I'm not trotting them out so much to do 'see, we have that
> too!', though there is a component in that, but to learn more
> about both by comparing the two, and to see if there are
> interesting directions which Zope is missing. I think Java's
> system works better for model/view/controller type situations
> right now; Zope's framework for that is currently still in
> design phases. Java also has clear (standardized) interfaces
> for it, something which Zope needs a lot more of.
All of which I'll agree with. And I'm not trying to suggest that
Zope is a poor product, either. I just don't feel like it's a
good choice for a web-based application -- a website with some
dynamic elements, maybe, and I could even see it being used for
an online store.
And I confess that the more we talk about these things, the more
optomistic I am about the future. Java's solutions and toolkits
are great (or at least pretty good), but I would like a good,
solid alternative to all that wordy Java.
> I don't know how to compare ZEO with the scalability features
> you sketched out. I would guess it's a question of tradeoffs;
> which is better probably depends on your requirements and
> development style.
I think ZEO is really cool. I like it a lot, but it seems like it
only answers about half my concerns. That's also true about the
enterprise java beans -- the Java Data Objects are really more
interesting to me from the standpoint of my dynamic data model,
but both ZEO and EJB do really well for providing keyed access to
persistent objects. I think ZEO is a little more light-weight
than EJB? I'm not sure how effectively you can "synchronize" the
ZEO stuff against multiple threads / processes contending for the
same data.
> > Like I said once before,
> > maybe we can beat Java to the punch here.
>
> Python certainly has a lot of flexibility to work in its favor here,
> though I don't know if we have the development resources in the
> Python/Zope world to go fast on this. These discussions often seem to
> devolve into feature wishlists and pie-in-the-sky designing.
That's maybe true, but like I said, I started work on it at one
point, and probably put a few solid days of effort into it. What
I've arrived at might be less than perfect -- in fact, it IS less
than perfect -- but it was a running start at something that
would marshal a database table into an object.
Even at that level of utility, it's a very, very useful tool.
> [ snip lots, including a description of EOF's qualifiers ]
> Would this get translated into a query into a relational database?
Yes. EOF provides a couple different ways to do things -- you can
build up these qualifiers piecewise, or you can write out the
query string. But then EOF goes and traces it through its
internal mapping of entities to database elements, and produces a
SQL query that retrieves the appropriate object.
> > When you fetch these objects from the database, the EOF puts
> > "Faults" in the place of relationships. When you first try to
> > read from a fault object, it runs off and fetches the object from
> > the database.
>
> A proxy pattern.
Yes, and very effective in reducing the strain on the database
while still preserving the whole notion of composed objects.
There's also a means by which you can pre-fetch some of the
relationships -- that way, if you're planning an operation that
will iterate over all the eggs in a spam_and_eggs_breakfast, you
don't need to go back to the database multiple times.
> > But that's not all! EOF also provides sophisticated caching and
> > data source controls. EOF also provides multiple 'editing
> > contexts' with undo capabilities and the ability to nest editing
> > contexts so that changes can be made within the context of other
> > changes, and committed incrementally, or abandoned en masse.
>
> Does this use relational database transaction features?
> (with subtransactions?)
It doesn't require relational database transaction features, and
I believe that it provides access to transactions at a more
direct level. EOF's "editing contexts" are in-memory
representations. Basically, every time you create an editing
context, any object modified in that context is first copied from
its parent context, then modified. If you abandon the changes,
the context closes and you never write the changes back onto the
parent context. Commit them, and all your changed objects are
promoted back into the parent context.
This is especially handy when you're building sequences of web
pages several pages deep before the final commit. You can nest
your editing contexts, and when the user hops back four pages,
you can either make the hop with him and toss the deeper changes,
or even just hop around with him and wait for him to commit the
whole lot of them.
> *part* of the good effects you attribute to standard APIs can
> be dealt with by good API *documentation* instead. Another part
> deals with user interface; I do think Zope's web UI helps
> people who have little programming experience tremendously;
> I've seen this happen several time. A hot topic in the Zope
> world has to do with explicit interfaces, and clear
> documentation for them. This inspired PEP 245, currently under
> consideration for 2.2. While I don't agree with some of the
> details of that PEP, I do think the ability to have a form of
> explicit interfaces (run time checked if checked for at all!
> ability to lie about implementing an interface! this is Python :)
> is very important to the future health of Zope and similar large
> Python systems.
I think I agree with you here. I've worked around the interface
issue in the past (subclass empty classes, then test to see if
my instance is a subclass of a particular empty class), but it
seems like being able to unambiguously promise to implement a
certain interface is much /clearer/.
I think Zope's web UI is a mixed blessing. It cuts down on the
learning curve to get in and start making changes, but in the
end, it becomes an impediment to being able to work smoothly -- a
simple CVS archive of the DTML would be more practical later in
the game.
And yeah, documentation could correct a lot, especially if the
documentation addressed best practices and common problems
experienced when developing larger and more complicated sites.
But I can't comment extensively on Zope -- like I said, I'm stuck
on an old version. That means all the docs that I've read point
people at ways of doing things that don't work for me, and even
most of the advice on the mailing list refers to features I can't
access. Many of my issues with Zope may be that Zope as I know it
isn't nearly as sophisticated as Zope as it could be. :)
Always a pleasure,
--G.
Martijn Faassen
> A further episode in the discussion between Martijn and myself:
>> Or you can do evil and cool stuff with AccessRules (the whole
>> SiteRoot stuff).
>> [ ... quotes from me about controller-centered models ... ]
>> What exactly do you mean by embedding controller elements in the
>> view? I'm not entirely sure what you'd refer to as the
>> controller here.
> I'm not sure how to manipulate AccessRules; I think this might be
> one of the Zope features that we currently hafta do without.
AccessRules are voodoo. I've only played with them a little. Here is
an example of what you can do; unfortunately written in DTML, but
you can also write it in Python:
http://www.zope.org/Members/4am/SiteAccess2/otheruse
So, it can be used to embed variables in the URL path itself instead of as the
argument; sometimes this can be clearer.
> I think maybe I'm running along here under the assumption that
> everyone more or less understands Model/View/Controller, and
> understands it in the same way that I do. Let me try to define my
> terms.
I more or less understand it, but not the same way you do. :)
[snip view description]
Right, this was clear to me. Presentation, reporting.
> The "Controller" element responds to user input and interfaces it
> with the business objects of the model. The controller is in
> some ways like glue code, but this is (or can be) where you might
> have form validation logic, or where you translate your form
> fields into the attributes of a data object. The controller
> element is typically the center of your application; it might be
> compared to the main() function in a C program. It presents
> various views when required, retrieves model objects, and glues
> them all together.
I can't think of a good translation of this to Zope, as you
said, in Zope control and view tend to be rather intertwined. This is
not to say you can't use a pattern that does much like this, but it's
less cleanly separated.
[snip model]
This part was clear to me too.
I'm not sure why 'controller' wasn't clear to me, but it's always been
the vaguest part of MVC to me...
[snip]
>> Hm, yes, I think this makes sense (though it could lead to horrible
>> URLs). Of course you don't give the details here so I'm not
>> entirely sure I get the entire picture right.
> The URLs need not be any more "terrible" than in any other web
> application, including any Zope application. If your main servlet
> responds to all URLs that begin with '/myapp', any sub-path is
> something that the servlet can switch on. The difference here is
> that /myapp doesn't map to a folder object either on the
> filesystem or in some content repository.
Nor does it map to a method on some object, as what happens in Zope,
really. The content repository is just something behind that, but not
essential (just useful) to object publishing.
> It's mapped in the
> application server to mean "invoke this servlet"; additional path
> information is passed on to the servlet.
[snip]
> Meanwhile, your controller has the request before anything else.
> That means the controller can take action based on form values or
> other request parameters. As far as I know, Zope provides a
> solution for the most common application of this (user
> authentication), but does not provide much in the way of a
> toolkit for other similar problems.
> An example might be a look-and-feel switch -- if you have a
> cobranded application, you might serve from a different batch of
> pages, or use decorations and stylesheets from a different
> directory hierarchy.
> You /can/ do these things in Zope, it just requires hacking
> around the way Zope is set up to serve pages, not invoke
> processing logic.
For many of those things (look and feel switch for instance) you
can use Acquisition. The alternative is to intercept the traversal
at some point to do something special. Access Rules are one way to do
that. Finally, if your URL end up at a Python script at some point
in the path, the rest of the path coming after that can be processed by
it and you can do whatever you like, I believe.
[snip]
[speed of view templates]
> Or you could take your Zope objects and turn them into actual
> python code objects that generate HTML and perform some actions
> when called. It's not going to suddenly challenge C for
> near-hardware speeds, but it's a significant step ahead of
> doing the lexical parsing at runtime -- at least the Python
> interpreter is written in C.
Sure. In short, there are a ton of optimization opportunities here, if
necessary.
> I don't think it's a huge priority, but it's one of the things
> the Java stuff does to reduce runtime load, which in turn
> promotes better scaling and better overall peformance.
True, though page generation could in general probably be easily
distributed, so throwing more hardware at the problem is relatively
doable. It's harder to scale controllers and models, I expect.
>> > Your JSP pages have access to at least four levels of state
>> > (there might be another I'm forgetting): application, session,
>> > request, and page. The first three correspond to the same state
>> > repositories managed by the servlet. The 'page' context is for
>> > local objects.
>>
>> Right, in Zope you'd have 'acquired things', session object (if you
>> have Core Session Tracking or something similar installed), REQUEST
>> object and folder context, for these. I'm just trying to translate
>> the concepts.
> Almost.
> I think the acquired things don't map onto application state
> quite like you suggest. There's one repository, shared by all the
> sessions running inside a single process. This isn't initialized
> with web-content properties. It's a place to stick objects at
> runtime.
Hm.. I'm not sure about an exact equivalent this in Zope.
Generally of course objects in Zope can always refer to runtime
objects, and this frequently happens (I initialize a bunch of
widget and validator singleton objects in my Formulator component
for instance and any instance of a Formulator Form in the object
database can use these).
> I don't know what the session object gets you, or how it gets it
> for you, but I assume that's correct.
It's quite similar to REQUEST in that you can attach almost
arbitrary Python objects to it.
> The REQUEST object does map
> to the request context. The page context maps more closely to the
> namespace of a DTML document.
>> > You can forward control to other servlets or JSP pages, and you
>> > can also include pages.
>>
>> What do you mean by 'forwarding control'? Control of what?
>>
>> [ snip my explanations ]
>>
>> Ah, I think I more or less understand. I'm not sure what the use of
>> forward is compared to include, though. Why'd you ever want to forward
>> control and never come back? Generate half a page with one JSP page,
>> and the other with another?
> <dtml-return> and RESPONSE.redirect() provide more-or-less
> similar functionality in DTML, as compared with the use of
> <dtml-var> to include a method.
Ah, okay, I see. Though RESPONSE.redirect() does a client-side forward.
> My typical page processing paradigm is to submit form data to the
> page that renders the form. If all the data are acceptable and no
> processing errors arise, I forward on to another page. If all the
> data are not acceptable, I redisplay the current page with error
> messages. Others do it other ways.
Plug: this type of thing becomes pretty easy to build with Formulator. :)
>> > You can associate a bean with an object, and map form properties
>> > onto the bean's attributes. I think that this is most useful when
>> > you're programming pure JSP, but it's pretty useful when you're
>> > not.
>>
>> Right, Zope's REQUEST object does this automatically (the
>> 'form' subobject).
> Except that your "form" subobject is one standard object, not an
> object customized for your particular form. The servlet API
> allows you to pick the attributes off the REQUEST object, too;
> it's just somewhat more convenient to load up a bean.
Formulator allows you to customize whatever ends up in your REQUEST, or
can return a result dictionary. Of course that's my own component.
I think form handling is something that can be done better in Zope,
so I'm writing a component to do that.
[snip]
> The current solution is a reasonable solution, but it doesn't
> scale well. Your front-end load balancing hasta be session-aware,
> so it can redirect to the right instance of Zope.
Does it? It just needs to transmit the changes to the session object
database, right? That's similar to what it is already doing. Or do
you mean such a setup without ZEO?
> Using ZEO and Core Session Tracking could be The Right Thing. It
> certainly seems like the two technologies could be combined
> reasonably. Until it's arrived, though, you're still rolling your
> own sessions if you deploy on more than one box.
I think people already have setups running like that, though I'm not
sure.
>> > Servlets get a request and a response object passed to them.
>>
>> Like Zope's DTML pages, and of course you can pass those along
>> to Python Scripts or other python code.
> Yes, but the servlets ARE Java code, which means that you don't
> NEED to stick a block of code at the top of every page, designed
> to invoke them.
True, it would be nice to have some way to do that more easily in
Zope. It shouldn't be that hard to whip up, but someone has to come
up with it and make it standard practice.
>> Neat. With Zope exporting subfolders or simply copying
>> Data.fs is relatively
>> painless, but you need to copy over any external methods and special
>> Python products manually, which isn't hard but an extra step.
> Yeah, Zope isn't all that hard to roll out, as long as you do
> everything in Zope. You can still get sync problems with the
> external dependencies, though. If you use a lot of those (and I
> suspect that you will in a logic-intensive app), then you're
> likely going to hafta come up with some other deployment
> mechanism.
A benefit of Java's "We are the world" approach, I guess, which
I usually dislike.
[snip]
> Well, except that we're not talking about just ZODB or ZEO here,
> we're talking about distributing dynamic (by which I mean
> run-time) state. That includes things like concurrent access
> issues and synchronization of access, RMI techniques, and
> whatever else it takes to implement these things.
You mean that the whole system can switch to another server in the
middle of handling a single request?
> It's also not just Session stuff. If you could publish arbitrary
> objects to the ZEO store and retrieve them by key -- something
> I'm sure is possible, but not sure how difficult -- you'd be
> close.
That should be pretty trivial from Python. I mean, just use a persistent
dictionary, or, to be more efficient, a BTree, stored in the ZODB.
>> Sort of like ZEO with Core Session Tracking. :) Of course this
>> is still being heavily developed, but it seems to be getting
>> near offering equivalent features.
> I can't speak to that, because I haven't used (and can't really,
> at the moment) Core Session Tracking, let alone using it with
> ZEO.
I haven't worked with ZEO yet either, so I can't make too many
claims about it. Core Session Tracking I've only used in its most
simple form. Eventually I hope to get to using both, though. Let's
call this discussion part of preparing for it. I learn about the
issues this way.
>> > The J2EE stuff makes deployment still one more step simpler, too.
>> > It pushes parameters that might change during runtime out one
>> > notch further, so that deployment configuration can be separated
>> > from the details of servlet instantiation, URI mappings, and
>> > other miscellany concerning the interaction of the app and the
>> > app server.
>>
>> Hm, I'm not sure what this part means, exactly. I can't
>> translate it to any Zope terms, which is how I tend to think
>> about things, myself.
> I might argue that trying to put everything into Zope terms is
> part of what's limiting your comprehension. :) Zope is really a
> very different animal.
But does that mean this ability is important? I mean, if I can't
think of a Zope equivalent (x exists in Zope *or* x is needed in Zope
but we don't have it (yet))...but I can't think of the need here.
> Still, if you were to take your Zope application, and all its
> external methods, and all the little mini-servers that helped
> distribute your backend processing job, and stuck them all in a
> big tar file, then had one configuration file that detailled ALL
> the configuration details that would vary from machine to machine
> within an installation, and all the details that would vary from
> installation to installation -- if you assembled that tarball and
> that config file, you'd have the deployment mechanism used by the
> Enterprise stuff.
Okay.. there are vague sounds coming from Digital Creations that
they want to move the source code into a ZEO database as well,
later on (offering tools to temporarily export them to the filesystem).
This sounds like what you're talking about.
>> Yes, I'm not trotting them out so much to do 'see, we have that
>> too!', though there is a component in that, but to learn more
>> about both by comparing the two, and to see if there are
>> interesting directions which Zope is missing. I think Java's
>> system works better for model/view/controller type situations
>> right now; Zope's framework for that is currently still in
>> design phases. Java also has clear (standardized) interfaces
>> for it, something which Zope needs a lot more of.
> All of which I'll agree with. And I'm not trying to suggest that
> Zope is a poor product, either.
I realize that. It's just that Zope is my main experience with
web application programming, which is why I talk about it so
much here. :)
> I just don't feel like it's a
> good choice for a web-based application -- a website with some
> dynamic elements, maybe, and I could even see it being used for
> an online store.
> And I confess that the more we talk about these things, the more
> optomistic I am about the future. Java's solutions and toolkits
> are great (or at least pretty good), but I would like a good,
> solid alternative to all that wordy Java.
I agree Zope still needs to grow. The interfaces are too vague right now,
and that needs to become more solid. In my opinion that is the most important
thing that Zope needs to do and Java has already done. All the rest is
can be done by both with some creativity, perhaps excluding some
of the enterprise style features.
[snip]
[object/relational database mapping]
>> > Like I said once before,
>> > maybe we can beat Java to the punch here.
>>
>> Python certainly has a lot of flexibility to work in its favor here,
>> though I don't know if we have the development resources in the
>> Python/Zope world to go fast on this. These discussions often seem to
>> devolve into feature wishlists and pie-in-the-sky designing.
> That's maybe true, but like I said, I started work on it at one
> point, and probably put a few solid days of effort into it. What
> I've arrived at might be less than perfect -- in fact, it IS less
> than perfect -- but it was a running start at something that
> would marshal a database table into an object.
> Even at that level of utility, it's a very, very useful tool.
Any chance you'll open source it? By the way, any useful documentation
on this entire issue that I could browse through?
>> [ snip lots, including a description of EOF's qualifiers ]
>> Would this get translated into a query into a relational database?
> Yes. EOF provides a couple different ways to do things -- you can
> build up these qualifiers piecewise, or you can write out the
> query string. But then EOF goes and traces it through its
> internal mapping of entities to database elements, and produces a
> SQL query that retrieves the appropriate object.
Very interesting.
[snip more very interesting stuff about this object to database mapping]
> This is especially handy when you're building sequences of web
> pages several pages deep before the final commit. You can nest
> your editing contexts, and when the user hops back four pages,
> you can either make the hop with him and toss the deeper changes,
> or even just hop around with him and wait for him to commit the
> whole lot of them.
Is the whole set of changes somehow referred to by a session object?
Extremely interesting. Definitely need to look a lot deeper into this.
See if Python has something along these lines, and if not, see which
people are interested in building such a beastie.
[explicit interfaces]
> I think I agree with you here. I've worked around the interface
> issue in the past (subclass empty classes, then test to see if
> my instance is a subclass of a particular empty class), but it
> seems like being able to unambiguously promise to implement a
> certain interface is much /clearer/.
[zope UI can help beginners]
> I think Zope's web UI is a mixed blessing. It cuts down on the
> learning curve to get in and start making changes, but in the
> end, it becomes an impediment to being able to work smoothly -- a
> simple CVS archive of the DTML would be more practical later in
> the game.
Agreed that there are definitive negative tradeoff. Besides the
great need for explicit interfaces of some kind in Zope (well documented),
the secondmost important thing I see that Zope needs to add is the ability to
smoothly transition from filesystem representation of object database contents
such as DTML and Python code to ZODB object representation and back.
Explicit interfaces would make learning and extending Zope a lot
easier, and filesystem representation would suddenly enable a host
of filesystem based development tools, from editors to version
control systems; it would make the *process* of developing for Zope
much easier.
[snip]
Thanks for your very interesting post. I'm learning quite a bit here.