Lukas Renggli wrote: I can certainly understand that. Only for comparison, please. :) 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. :) As I thought. 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. 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+du… 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-vide… 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

good idea. Stef On 15 août 07, at 22:03, Jimmie Houchin wrote:

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:

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). What are the missing parts in Seaside (vs. Zope) and Pier (vs. Plone) then? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

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) 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. Don't know. 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. 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. Definitely want that. :) It would be nice to improve the story on doc management. 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. 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

Keith Hodges wrote: 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. 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. :) 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... But is it more difficult that doing ZPT, ZCML, .py, .txt, or whatever else in the plethora of files per content object. 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

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

On 8/24/07, Lukas Renggli &lt;renggli(a)iam.unibe.ch&gt; wrote: The stemming library is also Snowball can do stemming for multiple languages http://snowball.tartarus.org/ The PostgreSQL full text indexer tsearch2 uses it. Dave -- Dave Bauer dave(a)solutiongrove.com http://www.solutiongrove.com

Franz Josef wrote: [snip quote] 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. 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]

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