Pier v. Plone

Hello,

I am exploring my options for a couple of websites. I am a big fan of
Squeak, Seaside and Pier. But I have been exploring and learning about
Plone.

There is a tremendous amount of energy and work behind Plone and
products available for it. Plone 3.0 is about to be released. They have
put a lot of work into UI usability and into a lot of areas which are
nice to not necessarily implement yourself.

That said, I don't really have a grasp as to how far Pier is from
Plone-like abilities for both the end user and the developer.

One thing I am looking at is the Plone4Artist product which implements a
very sweet package for multimedia and Plone.
http://www.plone4artists.com/

I do very much like Squeak over Python.
In general I like Seaside/Pier over Zope/Plone.

I know that Lukas has used Zope/Plone, but I don't know how current his
knowledge is.

How far is Pier from offering a competitive experience to end users and
developers with regard to something like Plone?

Is there any interest in the community of competing in that sphere?

Or do most here happily use Seaside/Pier as a toolbox and the bigger
application type CMS isn't on the radar?

And initially I speak as to a basic Plone 3.0 out-of-the-box
capabilities and user/developer experience. Not necessarily the plethora
of add-on products. Those can come later if the out-of-the-box
experience is compelling enough.

Naively it seems that content types are easier to develop in Pier as
opposed to Plone.

I just don't know how much I could build on Pier towards a Plone-like
experience in the time it takes to do some things in Plone. And I really
don't know how much of the machinery that makes Plone what it is, is in
Pier. Or the effort to get there.

Comments regarding my questions above or most anything relevant to Pier
v. Plone 3.0 are greatly appreciated.

Thanks.

Jimmie

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> I know that Lukas has used Zope/Plone, but I don't know how current  
> his
> knowledge is.

My knowledge of Zope and Plone dates back to 2002. I maintained some  
legacy Zope projects in 2003, but as I discovered Smalltalk and  
Seaside around the same time I never went back to Python again.

> How far is Pier from offering a competitive experience to end users  
> and
> developers with regard to something like Plone?

I have no idea in what state Zope/Plone is today. Maybe I should give  
another try ...

> Is there any interest in the community of competing in that sphere?

I am interested, but I can't compete against hundreds of companies  
and thousands of developers all alone.

> Or do most here happily use Seaside/Pier as a toolbox and the bigger
> application type CMS isn't on the radar?

I am using Seaside/Pier for all my web related projects.

> And initially I speak as to a basic Plone 3.0 out-of-the-box
> capabilities and user/developer experience. Not necessarily the  
> plethora
> of add-on products. Those can come later if the out-of-the-box
> experience is compelling enough.

To make the out-of-the-box experience of Pier (especially for those  
not knowing Smalltalk and Seaside) quite some work is required.

> Naively it seems that content types are easier to develop in Pier as
> opposed to Plone.

This is certainly the case, even if Zope/Plone improved a lot over  
the past 5 years.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Jimmie, I have been agonizing over the same choice for months. For now, I am sticking with
Plone for my clients.

I have worked with Smalltalk since the late 80's and Plone since it's inception on top of
CMF for Zope.

Plone Cons -

   Past performance - Historically, I have had major performance problems with Plone
including memory leaks leading to repeated server restarts on an almost hourly basis under
heavy loads. Performance has improved but I am still concerned for the site I am currently
creating using Plone.

   Software Stack - This is my biggest complaint. The Plone stack is too dependent on C
libraries and python modules and zope adapters. For example, connecting Plone to postresql
requires a postgresql adapter which consists of a stack in C, python and Zope. Like most
OpenSource, all the versions have to be compatible. Just the out of the box stack is
python C virtual machine binary -> python libraries -> Zope -> CMF -> Plone -> Plone
Standard Products. Addon products such as PIL (imaging library) add a 3 layer stack of C
module, python module and Zope module.

   Development environment doesn't hold a candle to Seaside.

Plone Pros -

   Very active community.
   Tons of interesting Products.
   Workflow and security model very easy to customise.
   Easy to add custom products with ArchGenXML and ArgoUML.
   Very Easy to add custom content types with ArchGenXML and ArgoUML.
   **Visual Tools like ArgoUML/ArchGenXML are what are really missing from Squeak. You use
ArgoUML to create a UML class diagram for your product or content type. You then run
ArchGenXML to create a Plone product from the class diagram. I am currently using this
process to create a site with 8 custom content types with cross references and it is very
easy.
http://plone.org/documentation/tutorial/archgenxml-getting-started


Squeak Cons -

   The flip side of all of the Plone Pros.

Squeak Pros -

   I much prefer Smalltalk to Python.
   I prefer the Smalltalk environment to any Python IDE.
   I think people write better Smalltalk tools/objects than Python programs.
   I prefer the architecture and tools of Seaside to Plone.
   Much shorter stack - Smalltalk VM -> Smalltalk source -> Seaside -> Magritte -> Pier.
   Fewer C module dependencies for add-on products/objects.


Personal Conclusion -

   Zope/Plone feels like a framework where you are locked into the frame.
   Smalltalk/Seaside feels like a great tool box to help you build whatever you want.
Unfortunately, I would have to build Plone when that is about all I need.

   If one only needs the functionality provided by Zope, Seaside is the better choice for
me. I would be more productive and have a better end product with Seaside versus Zope.

   I chose painful but functional Plone over Fun but less functional Pier based on the
Plone Workflow model, ArchGenXML for products and many available 3rd party products.

   I really hope to be able to make a different choice in the future.




Taun


Jimmie Houchin wrote:

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

FWIW, I'm using drupal for a musician's website I'm doing - just  
configure and tweak css - no coding necessary - tons of modules.

On Aug 14, 2007, at 3:44 PM, Taun wrote:


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Some remarks to the statements of Taun.

- rg performance - I don't see performance problems with a well
configured Plone 2.5.x environment when using CacheFu with Apache. If
this isn't enough you can use Squid or Varnish. A prerequisite is of
course enough RAM (>= 1 GB). Of course Plone is known, not being the
fastest.
- rg Software Stack - with 2.5.3 and the upcoming 3.0 release you have
the universal installer that takes care about all the dependencies of
your libraries. Anyway, I never run in problems on Debian based systems
with simply install with apt-get what you read in the install files.

I don't see that Pier can reach the the functionality that Plone
delivers today in near or mid future. If you make a list with
requirements what you need for your app and Plone covers most of them
*out of the box* then go with Plone. If you have, let's say 50% what is
not covered out of the box then it's a different picture. Of course you
can do everything with Plone and some developers do, but this doesn't
make always sense.

My idea is to use *both*. Plone and Seaside. Use Plone for everything
that's easy to use out of the box and use Seaside for requirements that
would need special python programming. It should be possible to bring
both together with either http://plone.org/products/htmlproxy (a proxy
based integration) or http://plone.org/products/windowz/releases (iFrame
based integration).
I haven't tried this approach but it's on my todo list.

regards,
Franz Josef



Taun schrieb:

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> My idea is to use *both*. Plone and Seaside. Use Plone for everything
> that's easy to use out of the box and use Seaside for requirements  
> that
> would need special python programming. It should be possible to bring
> both together with either http://plone.org/products/htmlproxy (a proxy
> based integration) or http://plone.org/products/windowz/releases 
> (iFrame
> based integration). I haven't tried this approach but it's on my  
> todo list.

I've done several proxy based integrations with Zope and Seaside.  
This works nicely and is completely transparent, as both application  
servers are mostly run behind Apache anyway. A visitor can't tell the  
difference of the Zope and Seaside parts, except by looking at the  
URL parameters.

Eventually I moved everything to SmallWiki (the Pier at that time).

> I don't see that Pier can reach the the functionality that Plone
> delivers today in near or mid future.

What are the missing parts in Seaside (vs. Zope) and Pier (vs. Plone)  
then?

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Hello Taun,

Thanks for the reply.

Taun wrote:
> Jimmie, I have been agonizing over the same choice for months. For now, I am sticking with
> Plone for my clients.

Me too. That's why I decided rather than just jumping into full bore
with Zope/Plone purely do to the size of community and a great end-user
experience to post a question here. I am glad I did.

> I have worked with Smalltalk since the late 80's and Plone since it's inception on top of
> CMF for Zope.
>
> Plone Cons -
>    Past performance - [snip]
>    Software Stack - [snip]
>
>    Development environment doesn't hold a candle to Seaside.

Oh absolutely. One of my big issues when doing Python. I've never
integrated an editor into my brain. :)

I was shocked the first time I installed Plone on my Ubuntu laptop.
AMD64 3200, 1.25gb ram, 100gb hard disk. It took about 30 minutes to
compile and install and was absolutely huge.

Looks reasonable. But I haven't yet learned how that works with Plone
3.0 and Zope 3 technologies. I do not know nor desire to Zope 2.


> Squeak Cons -
>    The flip side of all of the Plone Pros.

Yes. But that is why I posted. Does the community desire to over time
work in such a direction. If core Pier could move to and become =+ Plone
core, then we can start talking. Add-ons and products can come when the
machinery supports the basic usability and building blocks equal to and
better than Plone.

> Squeak Pros -
>    I much prefer Smalltalk to Python.
>    I prefer the Smalltalk environment to any Python IDE.
>    I think people write better Smalltalk tools/objects than Python programs.
>    I prefer the architecture and tools of Seaside to Plone.
>    Much shorter stack - Smalltalk VM -> Smalltalk source -> Seaside -> Magritte -> Pier.
>    Fewer C module dependencies for add-on products/objects.

Oh absolutely. I am working on website that I have to migrate to a
machine not under my control. Most likely Windows. I am a little
apprehensive about having him install Plone and me trying to
support/develop Plone/Python on Windows. I am not a Windows guy.

> Personal Conclusion -
>    Zope/Plone feels like a framework where you are locked into the frame.
>    Smalltalk/Seaside feels like a great tool box to help you build whatever you want.
> Unfortunately, I would have to build Plone when that is about all I need.
>
>    If one only needs the functionality provided by Zope, Seaside is the better choice for
> me. I would be more productive and have a better end product with Seaside versus Zope.

Cool.

>    I chose painful but functional Plone over Fun but less functional Pier based on the
> Plone Workflow model, ArchGenXML for products and many available 3rd party products.

Fortunately for me. One project I am working on is to replace the
current website which is done in an ancient version of MS SharePoint.
(Yuck!) So, surpassing it in usability is a fairly low target. And I
have the time to make it better after an initial equaling(or better) of
the capabilities.

The other project I am working on is my own. And for it I am willing to
work on improving Pier where it may need it, if in the end overall time
spent is equal to or less than a Plone version.

And for me that time includes, learning Python more sufficiently to get
my hands dirty in the Python side of Zope3/Plone3. Learn Zope3, Learn
Plone3. And develop both sites.

The learning curve for me is an advantage to Squeak/Seaside/Pier.

So I think a good question is...

If one is starting from ground zero. An understanding of programming and
maybe some web development. But no mastery of Python or Smalltalk or
there libraries. If the project requires doing Python or Smalltalk
programming in order to fully use the toolset or framework. (ie: not
simply a user of the application Plone/Pier).
Then which one gets a moderate website up and running the
fastest/easiest?   I know, very subjective.

> I really hope to be able to make a different choice in the future.

Me too. That's why I wanted to give Pier an opportunity before I stuck
my head into Plone and disappeared for an indeterminate amount of time.
If said time could be spent being more productive with better tools and
improving those tools and accomplishing the goal in similar time frame.
Then I am all Squeak/Seaside/Pier.

Thanks again for the reply.

Jimmie


[snip original message]

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Lukas Renggli wrote:
>> I know that Lukas has used Zope/Plone, but I don't know how current  
>> his knowledge is.
>
> My knowledge of Zope and Plone dates back to 2002. I maintained some  
> legacy Zope projects in 2003, but as I discovered Smalltalk and  
> Seaside around the same time I never went back to Python again.

I can certainly understand that.

>> How far is Pier from offering a competitive experience to end users  
>> and developers with regard to something like Plone?
>
> I have no idea in what state Zope/Plone is today. Maybe I should give  
> another try ...

Only for comparison, please. :)

>> Is there any interest in the community of competing in that sphere?
>
> I am interested, but I can't compete against hundreds of companies  
> and thousands of developers all alone.

Super! I understand you can't compete alone. But possibly if we started
an issue tracker with things that the community would like to see in a
Pier distribution so that we have a target to work towards. Then little
by little we can improve Pier to where Pier can be a top contender in
the CMS marketplace. At least so that those of who choose Smalltalk can
use the tool of our choice and be able to justify it to any PHB as
necessary. :)

>> Or do most here happily use Seaside/Pier as a toolbox and the bigger
>> application type CMS isn't on the radar?
>
> I am using Seaside/Pier for all my web related projects.

As I thought.

>> And initially I speak as to a basic Plone 3.0 out-of-the-box
>> capabilities and user/developer experience. Not necessarily the  
>> plethora of add-on products. Those can come later if the
 >> out-of-the-box experience is compelling enough.
>
> To make the out-of-the-box experience of Pier (especially for those  
> not knowing Smalltalk and Seaside) quite some work is required.

It would be nice to start learning what those areas are from those
experienced in both. Hopefully start adding them to the above issue tracker.

>> Naively it seems that content types are easier to develop in Pier as
>> opposed to Plone.
>
> This is certainly the case, even if Zope/Plone improved a lot over  
> the past 5 years.

I was watching a presentation on b-org: Creating content types the Plone
2.5 way.
http://video.google.com/videoplay?docid=-4512976899640436688&q=plone+duration%3Along&total=16&start=0&num=100&so=1&type=search&plindex=8
It seemed the methodology he was using was also applicable to Plone 3.

One guy during the presentation spoke of having to touch 16 files in
order to create content types following this model which was spoken of
as being a best practice.

I would say as far as easily spying out the land, look at the
"marketing" type materials on Plone.org. Movies.
http://plone.org/about/movies

Most of these movies are short. You could probably watch them in a
window on one side of your monitor, and do something else on the other.

I would initially skip the Better Web Dev. and the Recovery from
Addiction unless you want to see how Plone compares to Java,... etc.

Other videos from the 2006 Plone conference.
http://plone.org/events/conferences/seattle-2006/presentations/session-videos

These are longer, but if you have a big enough monitor. You can still
watch and get something done. :)

The video by Eben Moglen was excellent and not specific to Plone.
The video   What If Our Systems Could do the Rest? - Bob Boiko
was excellent for anybody doing CMS systems. Had nothing specific to Plone.

And then there is the laundry list of features in Plone 3.
http://plone.org/products/plone/features/3.0

That would give you some easy low lying fruit, just to see what people
exploring the CMS marketplace see when looking at Plone.

How does Pier compare when looking at these items?
What are those things that are appropriate for Seaside/Pier and we would
like to see in Pier?
What in this list are the low lying fruit?
   Reasonably short time to implement.

Lets start creating a target to shoot for.
What would be good projects for Google SoC?
What about those things that Esug sponsors?
What about students in general?

What can we do to enable and give direction to anybody who would like to
participate in improving the out-of-box Pier experience. What defines
Pier core? What do we want in a rich Pier distribution?

So I think the place to start is to see how Pier compares.
Then create a roadmap to get to where we want to be.
Enable the community to step up to the plate and contribute.

We can also pay attention to where we differ philosophically and where
we can exploit that difference. ie: the web heresy type stuff.

Just some thoughts.

Thanks for your time and for your contribution to the Squeak community.
It is appreciated.

Jimmie Houchin

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Franz Josef wrote:
> Some remarks to the statements of Taun.
[snip quote]
> I don't see that Pier can reach the the functionality that Plone
> delivers today in near or mid future. If you make a list with
> requirements what you need for your app and Plone covers most of them
> *out of the box* then go with Plone. If you have, let's say 50% what is
> not covered out of the box then it's a different picture. Of course you
> can do everything with Plone and some developers do, but this doesn't
> make always sense.

My projects definitely require Python or Smalltalk programming.

So it seems your saying that if Plone the app can do what you want, then
use Plone. Because Plone for the user is fine. But if you have to put on
your developer hat and get dirty, then you are on a sliding scale on
which at some point things can tip over to Squeak/Seaside/Pier. Correct?

But this is what I was looking for. It seems that I could spend a fair
amount of time in Zope/Plone creating and editing a plethora of files
and that I could spend far less time doing similar programming in
Squeak. Spend the difference on developing the things in Pier I might
want that Plone has available. Over time that would continue lower the
point of enter for Seaside/Pier on the above sliding scale. :)

It might not be the near or mid future, but if we create a target and
start working towards it. It could eventually come to pass that Pier is
competitive at certain levels and a winner on several. Just depends on
what your looking for.

I think that the productivity in Squeak/Seaside/Pier could enable us to
intersect with and compare nicely in the CMS marketplace at some point
in the future. The Plone people are already making their list for what
they want in Plone 3.5.

> My idea is to use *both*. Plone and Seaside. Use Plone for everything
> that's easy to use out of the box and use Seaside for requirements that
> would need special python programming. It should be possible to bring
> both together with either http://plone.org/products/htmlproxy (a proxy
> based integration) or http://plone.org/products/windowz/releases (iFrame
> based integration).

Okay. Here your talking about using Plone when you can be a user, and
using Pier when you need to be a developer. I can see some use cases
where this could be possible. But I would have to think about it.

Seems like it could become complicated if you have a user/member
database, authentication and such. Managing permissions to content
objects across two content systems seems potentially problematic.

Would require some thought.

Thanks for the reply.

Jimmie

[big snip]

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

On Aug 15, 2007, at 12:54 PM, Jimmie Houchin wrote:

I couldn't resist any longer ;)

These are my opinions from my experience, so take them with the  
proverbial grain of salt :)


My company is a Python shop - we have many commercial products on the  
desktop that are all written in Python and it has served us well...  
That being said, all our web development work is in ... Seaside


I have a lot of experience with Zope, I started using it when it was  
a commercial product known as Principia. I built several sites out of  
it in the 2.x timeframe, and have delved a bit into 3.0 to see how  
things had progressed.

The things that killed me over time were some of the main "selling  
points". With  Zope/Plone there is a plethora of third party modules  
and or plugins you can use, with varying levels of configurability or  
extensibility. I used several of these types of Zope plugins and was  
usually bit when the zope platform upgraded and they no longer  
worked, or were not backward compatible because of ZODB being  
underneath everything. I know that Plone mitigates some that risk;  
the Plone layer itself is dealing with it.

I intensely disliked that fact that I could create "products", mostly  
strait python code, use a templating language (ZPT or others), and  
also edit things through the web using the Zope interface. At first  
that all seemed great, but it just ate up brain cycles trying to get  
everything to talk together. Zope has a complicated model and getting  
to what you need can be a pain. Again, Plone may be easier as a layer  
on top.

In Seaside, I write in Smalltalk, whether I am using Magritte, Pier,  
ShoreComponents, Scriptaculous, etc; and a BIG plus for me: since  
this is a smaller community, I can actually hire the developers of  
these technologies to customize, implement, or train and I really  
know what I  am getting. It's not so easy in larger communities.

I am someone who has been using Seaside off and on since 2003, and  
did not come from an OO background, so have had significant hurdles  
in doing things in OOish ways. I can still create just about any kind  
of web app I want and do it much, much faster than any of the other  
ways I have used, including ASP, PHP, cherrypy, albatross, cold  
fusion, etc. No one else might enjoy my code, however ;)

Anyway, my vote is go Pier and Seaside, but your mileage may vary :)

Cheers,

Brian





_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Seaside, Magritte and Pier all use the bug tracker of Squeak:

        http://bugs.squeak.org

Select the project 'Squeak Package' and choose Seaside, Magritte or  
Pier as the category.

>> To make the out-of-the-box experience of Pier (especially for those
>> not knowing Smalltalk and Seaside) quite some work is required.
>
> It would be nice to start learning what those areas are from those
> experienced in both. Hopefully start adding them to the above issue  
> tracker.

Please report bugs and other issues there. Or just commit your  
enhancements to the code repositories, there is public write access  
everywhere.

> And then there is the laundry list of features in Plone 3.
> http://plone.org/products/plone/features/3.0

That's a nice feature list. I don't think we are too far away from  
that ...

> How does Pier compare when looking at these items?

Quickly scanning through the list I identify the following features  
as already present:

- LiveSearch
- Human-readable URLs
- Powerful page editor (but that could still be improved)
- Flexible navigation and always-updated site maps
- Adjustable templates on content
- Powerful standard content types
- Content is automatically formatted for printing
- Standards-compliant XHTML and CSS
- Accessibility compliant
- Pervasive RSS feed support
- Rich ecosystem of free add-on products
- Cross-platform
- Microformat support
- "Hot backup" support
- Cut/copy/paste operations on content
- Always-updated table of contents
- Portlets engine
- Wiki support
- Support for the search engine Sitemap protocol
- Support for multiple mark-up formats
- Easy collaboration and sharing

Things like the following points are extremely easy to implement:

- Link and reference integrity checking
- Automatic previous/next navigation

All the points related to versioning require a minor re-design of  
some internal data structures. That kind of stuff was already present  
at some point in the past, but got lost in the process because I was  
not satisfied with the implementation:

- Working Copy support
- Versioning, history and reverting content
- etc.

Other stuff is a bit more complicated, but I don't see anything that  
wouldn't be possible to add within a couple of hours or days of  
development effort.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

On 8/15/07, Jimmie Houchin <[hidden email]> wrote:
>
> Yes. But that is why I posted. Does the community desire to over time
> work in such a direction. If core Pier could move to and become =+ Plone
> core, then we can start talking. Add-ons and products can come when the
> machinery supports the basic usability and building blocks equal to and
> better than Plone.

And don't just look at Plone.  Joomla is very nice as well with all
sorts of cool features and add ons (e.g. for the less technical
members of your web site team you can set up specific email addresses
that if they send mail to the Joomla website the mail gets turned into
an article with a template you configure to display it)

I can't imagine the answer being anything but "yes of course!".  Pier
can and should compete in the CMS world.

As was mentioned in this thread, with Joomla, and I'm sure Plone and
everything else out there, you can get all kinds of components and
load them into your site to add new features.  But there is always the
issue of trying to integrate them.  And in some cases you have to do
complicated configurations of different software stacks.

In Pier we have all the integration of a homogeneous system.  Pier can
run any component made for Pier *or* Seaside.  So if someone writes
things for base Seaside, or even some other framework under Seaside
Pier can potentially use it.  And with the Pier #call:/#answer:
scheme, as well as normal message sending, composability really can be
a matter of simply sending a message to a component to do it's job.

And for building new components, I don't know what the Joomla or Plone
frameworks look like but it's hard for me to imagine them being easier
to make something new then Seasides, i.e. simply create a normal
model-domain object and put a render method, or just a Magritte
description to display it!

I also personally think that in Seaside we have a much better chance
to avoid the configuration nightmare of some of these things.  No
config files!  One should be able to configure and change anything
from the code or inside the website itself.

We could even have a component that generates apache rewrite rules for
your site. :)

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

good idea.

Stef

On 15 août 07, at 22:03, Jimmie Houchin wrote:



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Lukas Renggli schrieb:
> What are the missing parts in Seaside (vs. Zope) and Pier (vs. Plone)  
> then?
>
> Lukas
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 - there are 167 companies from 44 countries listed
at plone.net who offer commercial support. I know there are a lot more.
A lot of them help to improve Plone and/or write add ons.
- Maturity - see the number of websites and how prominent some of them
are that run with Plone (<http://plone.net/sites>).
- Documentation - several books are available, you will find about 250
documents alone at <http://plone.org/documentation> (useful and
comprehensive, most of them up2date (what’s not the default for a
community driven Open Source project). You can join an annual conference
(325 attendees registered 2006).

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.
- User Management - use Authentication Service (PAS) in Plone and manage
your users in a database, LDAP, etc. (haven’t seen something similar for
Pier).
- Availability of more than 100 add on products that can be used from an
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>).
- 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).
- 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).

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.

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.

Regards,
Franz Josef


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Hello Franz,

Franz Josef wrote:
Absolutely correct.

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
systems.

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 manage
> your users in a database, LDAP, etc. (haven’t seen something similar for
> Pier).

Don't know.

> - Availability of more than 100 add on products that can be used from an
> 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
the marketplace.

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. :)

Jimmie



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

I think we can compete -eventually.

Pier/seaside
 etc are developed with a minimalist philosophy.
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.

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.

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.

In smalltalk/seaside everything is moderately difficult, but everything
is doable in a moderately difficult kind of way..

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.

best regards

Keith








_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

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. :)

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

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

I can hardly do anything about these points, other than using Pier  
for all sites I am building myself (which I already do, of course).  
This is also why Pier exists in the first place and where most  
features come from.

> 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.

If people provide translations that would be certainly a nice addition.

> - Availability of more than 100 add on products that can be used  
> from an
> 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>).

There is already a big number of extensions. Have a look at my  
proposal [1] for the ESUG Innovation Awards 2007 [2]. And don't  
forget to vote for Pier, this will certainly help to further improve  
it ...

[1] http://www.iam.unibe.ch/~scg/Archive/Reports/Reng07c.pdf
[2] http://www.esug.org/conferences/ 
15thinternationalsmalltalkjointconference2007/
innovationtechnologyawards/submissions/

> - 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).

There is already a full-text search. It does not included uploaded  
files though. If somebody would implement readers for those strange  
binary formats, that would certainly be an easy thing to add to the  
search results.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Lukas,
I've created a page on Swiki <http://wiki.squeak.org/squeak/572> that
shows how you can use extrnal converters to get the plain text out from
various file formats like pdf, postscript, excel, word and powerpoint.
There are also some small examples to evaluate. Perhaps this will help
you or other Pier developer to implement a full-text search for some
external file formats.

Regards,
Franz Josef

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> I've created a page on Swiki <http://wiki.squeak.org/squeak/572> that
> shows how you can use extrnal converters to get the plain text out  
> from
> various file formats like pdf, postscript, excel, word and powerpoint.
> There are also some small examples to evaluate. Perhaps this will help
> you or other Pier developer to implement a full-text search for some
> external file formats.

Thanks for writing down this summary.

I am afraid that I don't have the time to work on this. Maybe a  
Google Summer of Code project? The stemming library is also  
interesting, but I am afraid that this only works for english  
sources? Maybe there are multilingual stemming libraries where we can  
just pipe the results from the converters?

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki