16 Aug
2007
16 Aug
'07
8:42 p.m.
Keith Hodges wrote:
I think we can compete -eventually.
Pier/seaside
etc are developed with a minimalist philosophy.
Is Pier?
I know it currently is somewhat minimalist right now. But I don't if
that is due to philosophy or due to the current situation of the community.
Lukas seems willing for Pier to compete in the Plone space. But is
incapable of doing it alone. Very understandable.
Plone/Zope
etc have an everything and the kitchen sink philosophy.
If you spend time integrating all of the minimalist bits we already have
then we may start to have a platform which can compete.
e.g 1 x Magma Server to n x Pier clients should work "out of the box".
Its just a matter of trying it and doing the configuration.
I have no experience with Magma. Is Magma ready to scale to millions of
objects and 10s to 100s of gigabytes of space? I know this isn't the
Magma list. But one of the two projects I am working on will have
10+million objects and 10s of gb of space to start with and grow from
there.
If it is ready. Then fantastic.
If not, we still have an excellent story in Glorp/Postgres or Gemstone.
My other project is small enough to do in image. (I wish the image
itself was scalable to 10s of millions of objects and 10s to 100s of gb
space. I have the disk space and many gb of ram. :)
Personally I am a kitchen sink kind of person since it
takes me a lot of
effort to see the path from A to B without concrete examples.
Me too. That's why I love the squeak-dev/web images.
If Pier seeks to be minimalist, which I'm still not sure, then I think
that we need to begin to either build a platform on top Seaside/Pier or
Seaside which can be the "full stack", "kitchen sink" providing an
excellent application which provides an excellent end user experience
and capabilities and provides the developer the abilities to deliver a
richer customizable experience to their clients.
Just need to ascertain whether that is Pier. Or if that is on top of
Pier or Seaside. Then start creating the target/roadmap so that over
time as people and resources become available we have clearly defined
goals and needs which can be accomplished. Then over time it can and
will happen. But if we never have direction and everything is just hodge
podge. It will never happen. We won't live long enough for evolution, we
need creation. :)
At present building pier/seaside apps are like
building a den with lego
rather than cardboard. You can assemble what you want out of lots of
little pieces, and it will be quite robust. If you want a custom piece
you take one you already have and adapt it a bit and carry on building.
With plone/zope, you take your cardboard boxes to build your den, the
boxes are bigger so you could build your whole den very easily, but
adapting boxes is much harder because they are a bit more flimsily
assembled and the underlying frameworks are not so concise. My limited
experience of zope a few years back when I did attempt to use it for
serious things (my ex-company corporate site uses it even today) under
the hood is that it is awful code/design. Easy things are easy and
slightly more difficult things are impossible.
I understand. My experience with Zope goes back to when it was Principia
and Bobo. Long before I knew of Squeak. I'm even credited in the first
Zope book. I helped proofread and sent back comments.
My problem was when I delved into the Zope source and I tried follow
source back to its roots to try understand things. I ran into way too
much magic. My brain could not contain all that. So I through my hands
up and left Zope looking for better ways.
That is one reason I love Smalltalk/Squeak. Everything is so much more
discoverable than searching through bazillion text files trying to make
cognitive sense of the array of interconnecting classes and objects and
mixins and... and... and...
In smalltalk/seaside everything is moderately
difficult, but everything
is doable in a moderately difficult kind of way..
But is it more difficult that doing ZPT, ZCML, .py, .txt, or whatever
else in the plethora of files per content object.
When you add pier, it becomes, some things are easy
you just configure
and arrange the components, and the rest is moderately difficult, but
still everything is doable in a moderately difficult kind of way once
you understand it.
If you want to build a mansion out of card board boxes then, you will
probably get going quite fast.
If you want to build a mansion out of lego its going to take some time.
Currently, to me, it seems that Plone wins when its Plone the
application. The more you go to the framework side, then the advantage
starts to slide over the Squeak/Seaside/Pier. I would like to see Pier
the application be able to compete with Plone the application.
I know it will take time. But as time goes on, if we keep making
progress, the decision "for" Pier becomes much easier. Neither Plone nor
Pier have "arrived" yet. But in some areas Plone is further down the road.
If we want a target and a time frame. And if equaling/beating Plone on
some of these is a legitimate goal. Then I would say we could look at
Plone 3.5. Work towards having a compelling story vis a vis Plone 3. and
before Plone 3.5 comes out have a compelling story towards it.
I am not necessarily proposing a time-line. But I am proposing that we
establish processes that move us towards a goal. As processes improve,
the product improves, the community grows and we hopefully start to
attain critical mass to achieve what we desire. I don't believe that the
critical mass (sustainable mass) for Squeak/Seaside/Pier is as large as
what is required for Python/Zope/Plone or even anywhere close.
I would like to be a part of this process.
Lukas said that http://bugs.squeak.org/ is the issue tracker for Seaside
and Pier. I haven't learned how to use that yet. But I will.
Is there a place where we establish and document processes for the
community to create Seaside/Pier the platform? A wiki? I didn't see any
such on seaside.st? Maybe this needs to be part of the establishing of
processes. A place to document established processes and goals.
A few more thoughts hopefully towards becoming a productive contributing
member of this community. I know I am not qualified for many of the core
areas of Pier, but hopefully I can help with components/products on top
of Pier core, documentation, etc.
Thanks to all who are participating in this dialog.
Jimmie