Franz Josef wrote:
Lukas Renggli schrieb:
> What are the missing parts in Seaside (vs. Zope) and Pier (vs. Plone)
Lukas, I only can speak for Plone not Zope. And I hope my statement
wasn’t understood as an offensive. I would love to see that I’m wrong. I
also have to correct my sentence. I had not in mind the pure
functionality but the big picture with technical and non technical
aspects (Plone vs. Pier). Sorry for not being precise enough.
So when I compare a CMS with Plone I also look at:
- Support/Community - [snip]
- Maturity - [snip]
- Documentation - [snip]
This is why I wanted to get a feel for community interest, even if that
community is small. A small community with a target (goal) can be
powerful. I was hoping that if Pier was close enough, that we could
create that roadmap and work towards parity in many areas and
superiority in others.
As Plone didn't start where they are, neither will we. We have to
provide a compelling story for the developer and the end user. The end
user won't necessarily care about the underlying technology. But, they
might care about piles of dependencies. Thirty minute compile times.
(Yes, I include Linux users) Thousands of files... As I watched many of
the Plone videos it is very apparent that you have to make sure you have
the just right combinations for things to work. The right Python, Zope,
Plone, Archetypes, ... I heard many questions of can I use x with ZopeX,
PloneY, ProductOfQuestionZ? Its anything but simple.
All of Plone's end user experience isn't rosy. And this is an aspect
which I anticipate will never be pretty. It is the nature of file based
Squeak, Seaside, Pier on the other hand if we can deliver a nice end
user experience. Will always be nicer than most when it comes to
deployment. On the small side just install the VM, *.Sources, *.image,
*.changes files and your are ready. You could put them all on a cd and
run the thing. Almost nothing else can compete here. IMHO. (at least I
haven't seen anything else)
Parts that are more related to functionality where I see a gap:
- Internationalization - Plone supports over 35 languages including
right-to-left languages out of the box when it’s installed. It has a
good i18n framework and with LinguaPlone you can add the same conent in
whatever language you need.
I believe when we have the compelling story that we can sell, that these
things will come. But the machinery needs to be there to enable such.
- User Management - use Authentication Service (PAS) in Plone and
your users in a database, LDAP, etc. (haven’t seen something similar for
- Availability of more than 100 add on products that can be used from
end user (you don’t need to be a developer). Examples are full featured
web shops, message board systems, registration systems, newsletter
integration (details at <http://plone.org/products
This is nice but somewhat deceiving. This argument has been used by
Windows people to beat on everybody else for years. I am not saying that
that is what your doing. But in those 100+ add-ons we have many
duplications. But almost nobody is going to run 3 different blog
products, 4 different forum products, ... They'll pick the one they want
and go on. The others are just superfluous.
What we do need is some quality components which can compete in those
areas. The number being fewer is not significant if we can provide the
capability and do so well.
- Scalability - you get it out of the box with ZEO (run 1 to n Plone
instances on one content database. Guess this is doable with Magma or
Gemstone, but not today out of the box).
I think here the story would be that on the small end, keep it in the
image. If you have more data, use Glorp/Postgres. Scaling with
Glorp/Postgres would actually win a lot of people. Because there are
lots of people who don't like, prefer or have other reasons not to use
the ZODB. And with Glorp/Postgres you aren't fighting the way of the
system in order to use an RDBMS which some people feel like with Zope/Plone.
And then if you want OODB, you probably don't get any better than
Gemstone. Gemstone is officially supporting Seaside on there web product.
- Full-text Searching - all the content is searchable even Word or
OpenOffice documents and PDF files (with add ons under Linux also for
Excel and PowerPoint and other file types).
Full-text searching. Definitely want that. :)
It would be nice to improve the story on doc management.
It would be nice if someone of the Pier core developer or a more
experienced user than me (I must admit I only played around with Pier in
the web-dev-images. So perhaps I missed some important points of Pier)
could make an entry at <http://www.cmsmatrix.org/>
;. Then it’s easy to
compare Pier to all the other CMS.
Absolutely. Lukas or whomever might do a simple honest comparison. See
if and what work would want to be done for a release before putting an
entry on there. Then put it on there and work on improving our story.
IMHO Pier today is a powerful CMS framework for a Smalltalk/Squeak
programmer. Plone at the other side is also made to be as easy as
possible for an end user. Here I see a difference today. It would be
interesting how other people position Pier against other popular Open
Source CMS today (like Plone, Drupal, Joomla, etc.) and in what
direction they wish Pier will develop in the future.
Absolutely. That's why I keep speaking about the end use experience.
Let me clarify that just in case there is any confusion.
Pier the framework vs. Pier the application
Pier the framework makes the developers life easier.
Pier the application enables non-developers to take Pier and build
something interesting without knowing Squeak, Seaside, Pier programming,
etc. They just have to be a competent computer user.
That is the story that needs to be made compelling.
In the end if Pier the application has a great usability story, then
developers lives are easier, because we don't have to go out of our way
to provide those benefits to the end user. They come with the
application. We provide the content types, business logic, whatever else
that requires Smalltalk, Python, etc.
In the end, I believe that because of Smalltalk there is much of our
story which nobody can compete against easily. We just need to catch up
where we're behind. I believe that we can provide a compelling story for
Smalltalk isn't dying. :)
Its time for Smalltalk (Seaside, Pier) to provide the compelling use
case for the marketplace. We can do this. And as we go along, we will
pick up new co-laborers who are excited about the vision and want to be
a part of this story.
Got get busy. :)