Re: [Zope-dev] Open Letter to zope-dev

2001-12-01 Thread Robert Rottermann



Friends,first thing I want is to express my 
huge gratitude to have something like Zope and its community.I 
have read all the all the mail that has been stirred by "that" open letter.I 
agree very much and I am willing to contribute as much as I can that zope should 
grow 10x.I found two things missing in the discussion so far that are 
crucial to attain this goal:- documentationTo start using Zope 
doing something more than trivial is an incredibly frustrating thing. Hunting 
for the right piece of documentation is very very hard. The community is very 
helpful I agree readily. However asking it should be the last resort and being 
forced to use it as an important part of the developement effort is very 
cumbersome and time consuming. And does not really take the frustration out of 
the process.Bruce Eckels postings to this list show that even a developer of 
his statue is prone to the same effect.I am a seasoned programmer that 
started to deal with Zope exactly one year ago. It is only now that I learn 
where to look for what piece of information and to decide which one is relevant 
and which one is not.- translation supportInternationalisation 
is crucial. English in the user interface is just not tolerated in a non English 
speaking part of the world. It is 10 years ago something like that would have 
been acceptable. I am from Switzerland where we pride ourselves to be 
multilingual (6 Million inhabitants 4 major languages, English being the fifth). 
However nobody would think of having anything like English on a public 
website.There are a number of efforts towards translation support. However 
to have any of them to succeed it needs the support of ZC which just does not 
exist.Now I have to hurry getting breakfast(or I get into 
troubles)Robert




Re: [Zope-dev] Open Letter to zope-dev

2001-12-01 Thread Paul Everitt


Agreed completely on both of those points.  There's double good news on 
both:

1) Someone plans to do something about it.

2) Both are with community involvement.

On documentation, someone in the community has committed to taking over 
the Documentation page on zope.org and finally organizing the myriad of 
useful, but unlocatable, doc resources out there.

The second is pretty exciting as well.  I saw a presentation in Paris by 
Juan David Palomar, of Localizer fame.  (The presentation is now up at 
http://estce.act.uji.es:9673/localizer).  The presentation impressed me 
on the need to get someone into the core of Zope that knows all these 
details, but also convinced me that the Zope3 effort needs to anticipate 
the needs of i18n and l10n.

I spoke with the guys here doing the extreme programming session on 
Zope3, and they agreed.

To say it again:

1) I think the world of Zope needs to grow 10x in the next year.

2) ZC can't do it, and much of the action in Zope is non-U.S., 
particularly Europe.

3) Thus, Zope needs a strong, competitive internationalization story.

ZBabel and Localizer are good starts, but as jdavid says, both should be 
thought of as non-core projects that start influencing the core 
step-by-step.

--Paul

Robert Rottermann wrote:

 Friends,
 first thing I want is to express my huge gratitude to have something 
 like Zope and its community.
  
 I have read all the all the mail that has been stirred by that open 
 letter.
 I agree very much and I am willing to contribute as much as I can that 
 zope should grow 10x.
 I found two things missing in the discussion so far that are crucial to 
 attain this goal:
  
 - documentation
 To start using Zope doing something more than trivial is an incredibly 
 frustrating thing. Hunting for the right piece of documentation is very 
 very hard. The community is very helpful I agree readily. However asking 
 it should be the last resort and being forced to use it as an important 
 part of the developement effort is very cumbersome and time consuming. 
 And does not really take the frustration out of the process.
 Bruce Eckels postings to this list show that even a developer of his 
 statue is prone to the same effect.
 I am a seasoned programmer that started to deal with Zope exactly one 
 year ago. It is only now that I learn where to look for what piece of 
 information and to decide which one is relevant and which one is not.
  
 - translation support
 Internationalisation is crucial. English in the user interface is just 
 not tolerated in a non English speaking part of the world. It is 10 
 years ago something like that would have been acceptable. I am from 
 Switzerland where we pride ourselves to be multilingual (6 Million 
 inhabitants 4 major languages, English being the fifth). However nobody 
 would think of having anything like English on a public website.
 There are a number of efforts towards translation support. However to 
 have any of them to succeed it needs the support of ZC which just does 
 not exist.
  
 Now I have to hurry getting breakfast
 (or I get into troubles)
  
 Robert
  
  
 
  
 
 
  
 




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Open Letter to zope-dev

2001-12-01 Thread Joachim Werner

Hi!

  This is a totally different business model than the one Zope Corp. is
using
  right now, but it might help refinancing the overhead a good community
needs
  to have ...


 Would it have to be done by ZC?

No, of course not.

And there could be more than one of course (though we'd need a Zope
Standards Base like the LSB then ;-))

Joachim


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Open Letter to zope-dev

2001-12-01 Thread Joachim Werner

 The second is pretty exciting as well.  I saw a presentation in Paris by
 Juan David Palomar, of Localizer fame.  (The presentation is now up at
 http://estce.act.uji.es:9673/localizer).  The presentation impressed me
 on the need to get someone into the core of Zope that knows all these
 details, but also convinced me that the Zope3 effort needs to anticipate
 the needs of i18n and l10n.

 ZBabel and Localizer are good starts, but as jdavid says, both should be
 thought of as non-core projects that start influencing the core
 step-by-step.

Hi!

I fully agree that ZBabel and Localizer don't have to be core projects right
now. But the core must be made fit for i18n to make sure that we don't have
to patch things like the user folder implementation or the Help! button in
the code. In Zopw 2.5, there still seem to be hot spots to fix with regard
to i18n.

The next step would be to agree on ONE syntax for use in Python, ZPT, and
DTML (not necessarly the same for each, but not more than ONE way for each).
So there can be two or more implementations of internationalization to
choose from, but Product maintainers do not have to provide two or more sets
of DTML/ZPT files. BTW, it is not too hard to make ZBabel accept
Localizer-style tags (which I already implemented in a CVS branch) and vice
versa.

The remaining difference between ZBabel and Localizer is a rather political
one:

We, the ZBabel team, are for consequent late binding of translations. That
means that we are against having multiple sets of properties for languages.
There will only be one set of properties, e.g. in English, and then the
BabelTower is used to translate them. This is for non-content things.

For content, we prefer the generic approach of ZBabel objects, that actually
is able to internationalize everything from images to CMF news (at least in
theory). The concept could be extended to have real content negotiation
support for Zope. I tried to outline that a bit in my comments at
http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ExplicitNam
espaceControlInURLs, which seems to be too hidden to be read. I envision a
Zope server to be able to return a content object (e.g. an image) in a
variety of supported formats and versions, just by setting the browser
content negotiation settings right or choosing an appropriate URL. E.g., a
browser that can display png images should get them where appropriate, and
somebody who doesn't have MS Word installed should get a PDF version of a
document instead, etc. etc. (same with language versions).

Joachim




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Open Letter to zope-dev

2001-12-01 Thread Andreas Jung


- Original Message -
From: Joachim Werner [EMAIL PROTECTED]
To: Paul Everitt [EMAIL PROTECTED]; Robert Rottermann [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Saturday, December 01, 2001 08:22
Subject: Re: [Zope-dev] Open Letter to zope-dev


  The second is pretty exciting as well.  I saw a presentation in Paris by
  Juan David Palomar, of Localizer fame.  (The presentation is now up at
  http://estce.act.uji.es:9673/localizer).  The presentation impressed me
  on the need to get someone into the core of Zope that knows all these
  details, but also convinced me that the Zope3 effort needs to anticipate
  the needs of i18n and l10n.

  ZBabel and Localizer are good starts, but as jdavid says, both should be
  thought of as non-core projects that start influencing the core
  step-by-step.

 Hi!

 I fully agree that ZBabel and Localizer don't have to be core projects
right
 now. But the core must be made fit for i18n to make sure that we don't
have
 to patch things like the user folder implementation or the Help! button in
 the code. In Zopw 2.5, there still seem to be hot spots to fix with
regard
 to i18n.


Of course there are hot spots. I have asked multiple times for help on the
mailing
lists and the Eurozope site to identify such related hot spots.
Also I had expect some input of the community regarding at unicode support
inside Zope. But there has been no feedback. It looks like no one needs
unicode
support in Zope ?! :-) Anyway, as a first step Zope 2.5 provides full
unicode
support for the ZCatalog. I would like to see some volunteers that could
help
to set up a list of requirements (the list is almost there on the Eurozope
site
I think) and possible solutions that could be integrated into the Zope core.
Referring to the open letter to zope-dev I could also charge the community
for zero feedback. But this is not the place and time for flamewars. Instead
we should bundle the power of ZC and the community. The opening of the CVS
is a good starting point but I would like to see more people contributing.

Cheers,
Andreas






___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Open Letter to zope-dev

2001-12-01 Thread Joachim Werner

 Of course there are hot spots. I have asked multiple times for help on the
 mailing
 lists and the Eurozope site to identify such related hot spots.
 Also I had expect some input of the community regarding at unicode support
 inside Zope. But there has been no feedback. It looks like no one needs
 unicode
 support in Zope ?! :-) Anyway, as a first step Zope 2.5 provides full
 unicode
 support for the ZCatalog. I would like to see some volunteers that could
 help
 to set up a list of requirements (the list is almost there on the Eurozope
 site
 I think) and possible solutions that could be integrated into the Zope
core.
 Referring to the open letter to zope-dev I could also charge the
community
 for zero feedback. But this is not the place and time for flamewars.
Instead
 we should bundle the power of ZC and the community. The opening of the CVS
 is a good starting point but I would like to see more people contributing.

I didn't want to blame anybody.

BTW: I have already mentioned the two areas Help! button and acl_user add
screen a couple of times. These seem to be the two that really are not
translateable via DTML. Another issue might be the system messages.

In general, if the error handling in general (including the authentication
errors that are not curently customizable without diving into the code) is
revamped in Zope 3.0 (which I hope), all error messages should be made
translateable one way or the other.

But of course translations also have their limits. Yesterday I was asked by
a collegue whether we should also translate the names of the permissions and
roles ... I said Maybe not ... ;-)

Regarding the unicode support, everything works flawlessly without as long
as one just needs German and English. That's why I don't have too much
expertise about unicode.

Joachim


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



core i18n support (was [Zope-dev] Open Letter to zope-dev)

2001-12-01 Thread Robert Rottermann

Andreas,
sorry if I have not reacted to a questions for assistance in the realm of
i18n. I must have missed them.
I rarely go to EuroZope since this site seems badly maintained.

However I really would like to help with the internationalization of Zope
since most of what we do here a my company must be multilingual.
I do have considerable experience making programs translatable and I did a
multilanguage CMF (with which I never was really happy)
Some 6 Months ago I started to collect what is there regarding i18n and
Zope. I did get a sizable number of answers. However there where two rather
unfortunate tendencies:
- multiple, different and incompatible attempts from our side
- missing involvement and therefore no shepherding from ZC's side

If, as Paul assures, the second point is about to be rectified it might be
now the time to do a second such compilation and then start doing it.

Robert

- Original Message -

From: Andreas Jung [EMAIL PROTECTED]
To: Joachim Werner [EMAIL PROTECTED]; Paul Everitt [EMAIL PROTECTED];
Robert Rottermann [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Saturday, December 01, 2001 2:50 PM
Subject: Re: [Zope-dev] Open Letter to zope-dev



 - Original Message -
 From: Joachim Werner [EMAIL PROTECTED]
 To: Paul Everitt [EMAIL PROTECTED]; Robert Rottermann [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Sent: Saturday, December 01, 2001 08:22
 Subject: Re: [Zope-dev] Open Letter to zope-dev


   The second is pretty exciting as well.  I saw a presentation in Paris
by
   Juan David Palomar, of Localizer fame.  (The presentation is now up at
   http://estce.act.uji.es:9673/localizer).  The presentation impressed
me
   on the need to get someone into the core of Zope that knows all these
   details, but also convinced me that the Zope3 effort needs to
anticipate
   the needs of i18n and l10n.
 
   ZBabel and Localizer are good starts, but as jdavid says, both should
be
   thought of as non-core projects that start influencing the core
   step-by-step.
 
  Hi!
 
  I fully agree that ZBabel and Localizer don't have to be core projects
 right
  now. But the core must be made fit for i18n to make sure that we don't
 have
  to patch things like the user folder implementation or the Help! button
in
  the code. In Zopw 2.5, there still seem to be hot spots to fix with
 regard
  to i18n.


 Of course there are hot spots. I have asked multiple times for help on the
 mailing
 lists and the Eurozope site to identify such related hot spots.
 Also I had expect some input of the community regarding at unicode support
 inside Zope. But there has been no feedback. It looks like no one needs
 unicode
 support in Zope ?! :-) Anyway, as a first step Zope 2.5 provides full
 unicode
 support for the ZCatalog. I would like to see some volunteers that could
 help
 to set up a list of requirements (the list is almost there on the Eurozope
 site
 I think) and possible solutions that could be integrated into the Zope
core.
 Referring to the open letter to zope-dev I could also charge the
community
 for zero feedback. But this is not the place and time for flamewars.
Instead
 we should bundle the power of ZC and the community. The opening of the CVS
 is a good starting point but I would like to see more people contributing.

 Cheers,
 Andreas








___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] FileStorage index size optimizaion (Re: FileStorage patch)

2001-12-01 Thread Jim Fulton

Thanks Chris,

Important note:

To get the benefit of this, you have to remove your old index.
FileStorage uses an index object that it pickles to it's
index file when you save the index (normal shutdown or pack).
If FileStorage reads the old index from the index file, the index
will have the old type (aka type({}) ;). To get the FileStorage
to use the new BTree-based index implementation, you need to
get it to build a new index by starting without an index file
or packing.

Jim

Chris Withers wrote:
 
 emf wrote:
 
  As I currently run 30-60 storage servers on a machine, I would be very
  interested in testing out such a patch, if you'd be willing to send it
  along.
 
 It's in CVS, just check out the appropriate branch:
 
 Jim Fulton wrote:
 
  OK, I made a CVS branch, BTreeFSIndex-branch (made from the Zope-2_4-branch),
  for just the BTrees and ZODB directories.  If you update to that branch
  you should get my experimental changes.  The BTrees package has a new
  extension, _fsBTrees that has 2-char to 6-char BTree types.
 
  The ZODB fsIndex.py provides a FileStorage index based on this BTree.
  You should get a memory consumption of only a little more than 8 bytes
  per object. Note that the file size is limited to about 256 terabytes.
  Nothing is free. :)
 
 cheers,
 
 Chris
 
 PS: Still haven't managed to get the machine resurrected :-(

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (888) 344-4332http://www.python.org  
Zope Corporation http://www.zope.com   http://www.zope.org

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] Regarding translation of Zope

2001-12-01 Thread Lennart Regebro

I've been trying to get updated and maybe even involved in the efforts take
make Zope translatable, but failed. Are there such an effort going on
seriously or have it died? The ZIP list is totally dead at least...

I have some knowledge about the area since earlier work with creating easily
translatable software, and I need a swedish version of Zope, so I'd like to
help.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Open Letter to zope-dev

2001-12-01 Thread Clark O'Brien


If anyone has seen how open source works, there is
usually a strong core team - like the ZC folks- who
provide direction to the project. There are also
dozens if not hundreds of enthusiastic folks who are
less involved but contribute features, patches, bug
fixes, documentation ...

Despite the fact that Zope is one of the most
attractive open source project around today there is
no
mass appeal to the project. The ZC folks are now
struggling with issues that should be handled by folks
less knowledgeable. 

In my humble opinion if the open source process had 
been allowed to progress unfettered by corporate greed
Zope would even now have a state of maturity
that it is not likely to reach even in 10 years of
development at the current rate.



--- Joachim Werner [EMAIL PROTECTED] wrote:
 Hi!
 
  To be honest i would be happy for Zope 3 not to be
 backwards
  compatible.  Tidy it up, delete the unless code,
 dare i say it -
  refactor.  Yes so my products will break, well
 half a days refactoring
  myself and i have a tidier more understandable
 project anyway.
 
 YES, we need a new start. Building on what we have
 now, of course, but doing
 things better without having to think about all the
 legacy stuff. When I see
 long-time Zope users like Tom Schwaller (who is a
 Linux legend in Germany)
 move on to something new like Webware for Python,
 that makes me wonder if
 Zope is starting to loose some of its momentum.
 
 Zope is a great product. And it becomes easier to
 sell it every day. But it
 could be so much better and more easy to use with
 just a little effort. Just
 to mention a few points: What we really need is
 
  A true vision of what Zope 3.0 is going to be
 
 
 Zope 2.x, together with the CMF, was sold bei
 DC/ZC as a content
 management product, which it isn't really. It is a
 good start for building
 one, but so many things that are mandatory for a CMS
 are missing in the
 out-of-the-box installation.
 
 Zope is a nearly perfect document storage, except
 for its server
 implementations for FTP (and partly also
 HTTP/Web-DAV) will not be too
 useful with major system load.
 
 Zope + Python are a dream team for web-based
 applications.
 
 I think that a single product can't be good at all
 these things. But I also
 think that Zope could emerge into a suite of
 near-perfect products for
 web-based internet and extranet solutions.
 
 I think Zope should be split up into components as
 soon as possible:
 
 - a database layer that includes alternatives to the
 ZODB (using products
 like DBObjects or the new stuff from 7x
 
 - a document management frontend to the database
 layer that can be used to
 manage all kinds of docs. Together with add-on
 products like the document
 library, Zope already does much of this, but it is
 not optimized for high
 loads yet, and products like Microsoft's Sharepoint
 Server are really coming
 close now. I wonder why people in the open source
 community seem to ignore
 what Microsoft is doing. I don't ask you to USE
 their software, but we
 should at least try to get inspired by the good
 ideas they have (or have
 collected from others who had them first). What we
 need in that part of Zope
 is high-performance real-time cataloging and
 searching, interoperability
 with FTP, WebDAV, maybe even SAMBA and NFS,
 automatic document conversion
 from Word/PDF to HTML etc.
 
 - an application development framework. Here, we
 need some more work done
 towards a real IDE (for Python and Zope). A lot of
 work has been done
 already by people like Riaan (who maintains Boa
 Constructor). Most of DTML
 (if not all) should go, and Python as the main
 programming language for Zope
 should be in the focus of documentation and training
 efforts. I spent more
 than a year with getting good at DMTL, just to find
 out in the end that
 ZClasses/DTML are really limiting and that
 developing in Python is almost as
 fast and much more effective. We need full
 integration between ZODB-code and
 filesystem code for that. We need ways of doing
 ZClass-like things with real
 Python code, and we need CVS-compatibility or
 something better within Zope.
 XML-RPC/SOAP/Webservices could be a strong part of
 this.
 
 - a real, complete, out-of-the-box CMS, based on the
 other three components.
 I know that there are at least a dozen good CMS
 BASED on Zope, but this
 seems to me to be a waste of resources. We only need
 one good system that
 can be maintained by many people. It needs a
 high-level plug-in
 architecture, so that people can contribute modules
 that can interact with
 each other. Currently, most Zope products other than
 the database adapters
 and user folder implementations are standalone
 products. Let's take
 Squishdot as an example. It is cool, yes. But it is
 not compatible with
 anything but itself. The CMF was a first try to
 build a standard Zope CMS,
 but it still far from being a good solution. It
 solves problems you don't
 have and takes away solutions plain Zope can offer,

[Zope-dev] Re: [Zip] Regarding translation of Zope

2001-12-01 Thread Dirk Datzert

Hello Lennart,

there are currently 2 prjects for zip: localizer and ZBabel.

I prefer ZBabel for I18N . Currently a ZBabelMaster-Tower is being build with
all necessary phrases of Zope, CMF and a lot of products.

Regards
Dirk

Lennart Regebro schrieb:

 I've been trying to get updated and maybe even involved in the efforts take
 make Zope translatable, but failed. Are there such an effort going on
 seriously or have it died? The ZIP list is totally dead at least...

 I have some knowledge about the area since earlier work with creating easily
 translatable software, and I need a swedish version of Zope, so I'd like to
 help.

 ___
 Zip mailing list
 [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zip


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Open Letter to zope-dev

2001-12-01 Thread Robert Rottermann

Clark,
where is the problem??
Yes ZC ties to make money out of Zope. And I hope they are successful.
Don't you know that only those that have can give?
If ZC does not make the money to cover their cost how can they give us
Zope??

Open source is not only for fun. Also to make money!

Robert

- Original Message -
From: Clark O'Brien [EMAIL PROTECTED]
To: Joachim Werner [EMAIL PROTECTED]; Andy Dawkins [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Saturday, December 01, 2001 6:47 PM
Subject: Re: [Zope-dev] Open Letter to zope-dev



 If anyone has seen how open source works, there is
 usually a strong core team - like the ZC folks- who
 provide direction to the project. There are also
 dozens if not hundreds of enthusiastic folks who are
 less involved but contribute features, patches, bug
 fixes, documentation ...

 Despite the fact that Zope is one of the most
 attractive open source project around today there is
 no
 mass appeal to the project. The ZC folks are now
 struggling with issues that should be handled by folks
 less knowledgeable.

 In my humble opinion if the open source process had
 been allowed to progress unfettered by corporate greed
 Zope would even now have a state of maturity
 that it is not likely to reach even in 10 years of
 development at the current rate.



 --- Joachim Werner [EMAIL PROTECTED] wrote:
  Hi!
 
   To be honest i would be happy for Zope 3 not to be
  backwards
   compatible.  Tidy it up, delete the unless code,
  dare i say it -
   refactor.  Yes so my products will break, well
  half a days refactoring
   myself and i have a tidier more understandable
  project anyway.
 
  YES, we need a new start. Building on what we have
  now, of course, but doing
  things better without having to think about all the
  legacy stuff. When I see
  long-time Zope users like Tom Schwaller (who is a
  Linux legend in Germany)
  move on to something new like Webware for Python,
  that makes me wonder if
  Zope is starting to loose some of its momentum.
 
  Zope is a great product. And it becomes easier to
  sell it every day. But it
  could be so much better and more easy to use with
  just a little effort. Just
  to mention a few points: What we really need is
 
   A true vision of what Zope 3.0 is going to be
  
 
  Zope 2.x, together with the CMF, was sold bei
  DC/ZC as a content
  management product, which it isn't really. It is a
  good start for building
  one, but so many things that are mandatory for a CMS
  are missing in the
  out-of-the-box installation.
 
  Zope is a nearly perfect document storage, except
  for its server
  implementations for FTP (and partly also
  HTTP/Web-DAV) will not be too
  useful with major system load.
 
  Zope + Python are a dream team for web-based
  applications.
 
  I think that a single product can't be good at all
  these things. But I also
  think that Zope could emerge into a suite of
  near-perfect products for
  web-based internet and extranet solutions.
 
  I think Zope should be split up into components as
  soon as possible:
 
  - a database layer that includes alternatives to the
  ZODB (using products
  like DBObjects or the new stuff from 7x
 
  - a document management frontend to the database
  layer that can be used to
  manage all kinds of docs. Together with add-on
  products like the document
  library, Zope already does much of this, but it is
  not optimized for high
  loads yet, and products like Microsoft's Sharepoint
  Server are really coming
  close now. I wonder why people in the open source
  community seem to ignore
  what Microsoft is doing. I don't ask you to USE
  their software, but we
  should at least try to get inspired by the good
  ideas they have (or have
  collected from others who had them first). What we
  need in that part of Zope
  is high-performance real-time cataloging and
  searching, interoperability
  with FTP, WebDAV, maybe even SAMBA and NFS,
  automatic document conversion
  from Word/PDF to HTML etc.
 
  - an application development framework. Here, we
  need some more work done
  towards a real IDE (for Python and Zope). A lot of
  work has been done
  already by people like Riaan (who maintains Boa
  Constructor). Most of DTML
  (if not all) should go, and Python as the main
  programming language for Zope
  should be in the focus of documentation and training
  efforts. I spent more
  than a year with getting good at DMTL, just to find
  out in the end that
  ZClasses/DTML are really limiting and that
  developing in Python is almost as
  fast and much more effective. We need full
  integration between ZODB-code and
  filesystem code for that. We need ways of doing
  ZClass-like things with real
  Python code, and we need CVS-compatibility or
  something better within Zope.
  XML-RPC/SOAP/Webservices could be a strong part of
  this.
 
  - a real, complete, out-of-the-box CMS, based on the
  other three components.
  I know that there are at least a dozen good CMS
  BASED on Zope, 

[Zope-dev] Scrollbar off the page in manage_workspace

2001-12-01 Thread Walter Miller

Both in 2.4.3 and 2.5.0 b1, the scrollbar seems to be off the end of the
page and the Wider and Narrower buttons don't work.  For example, in
2.5.0 b1, editing http://localhost/index_html in the browser seems to work
fine but the http://localhost/standard_template.pt doesn't.

I'm using IE 6.0 but I believe I had this same problem with IE 5.5.

Netscape 4.08 seems to work.

Mozilla 0.9.5 kind of works meaning that at least the scrollbar is not off
the page but the Wider and Narrower buttons don't work.

Opera 6.0 works as well as Netscape 4.08 except I did notice it doesn't like
it when you change the default preferences, i.e. no CSS, no top bar.

Walter




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Open Letter to zope-dev

2001-12-01 Thread Bill Anderson

On Sat, 2001-12-01 at 06:02, Joachim Werner wrote:
 Hi!
 
   This is a totally different business model than the one Zope Corp. is
 using
   right now, but it might help refinancing the overhead a good community
 needs
   to have ...
 
 
  Would it have to be done by ZC?
 
 No, of course not.
 
 And there could be more than one of course (though we'd need a Zope
 Standards Base like the LSB then ;-))


See, that is where I'd see ZC's role in a Zope Distribution world.
Theirs could be the standard base, with input from the community of
course. Naturally, it would not prevent ZC from offering
more-than-standard distributions.

Bill



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Open Letter to zope-dev

2001-12-01 Thread Chris Withers

Clark O'Brien wrote:
 
 In my humble opinion if the open source process had
 been allowed to progress unfettered by corporate greed
 Zope would even now have a state of maturity
 that it is not likely to reach even in 10 years of
 development at the current rate.

Oh go back to your troll hole would ya?

Chris

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] Open letters, hijacking and the like

2001-12-01 Thread Danny William Adair

Hi!

Wow, this is the first time I have more zope-dev mails in my inbox than from 
the main list (and I'm very happy that all this stays on one list).

What I have seen from ZC up til now seems like they disclose practically 
everything but their client base, ok and maybe plans for a commercial Zope 
product (I count two now that have been dropped, this does not include Zope 
itself). Efforts have been made to separate the geeks from the 
tie-fighters (.org/.com), but I can't see any negative side-effects for the 
development of Zope itself. Maybe not yet, but, and this goes out to Mr 
O'Brien: It needs two to tango. Fair enough. ZC knows that, and especially 
Paul Everitt has pointed out more than once the dedication that ZC has 
towards the community.

I want to thank Zope Corporation for everything that's been done up til now. 
This is the kind of track I will stay on. I see this working.

Whatever parts of Zope don't work as expected, I don't know in how far I 
could ever put blame about that on ZC. These guys are more open to new ideas, 
efforts from the community and mutual benefits than anyone else I have met 
(in my short life, ok granted). Akm's worries and complaints are legitimate 
(and he has already corrected his language), and I see people reacting 
_immediately_. What more can you expect? In my opinion it was just a 
contretemps that priorities in the User API were set differently than 
expected from someone who dedicates a hell of a lot of time to that field of 
development. My personal opinion is that ZC should give akm a CVS account and 
let him put some elaborate changes to the user api for 2.5, apparently he 
knows exactly what he's doing.

Dude: Do it better and _then_ complain. ZC's not yo mama, feeding you 
software with a spoon. It looks like you're spilling it all, anyway.

Take a look at the ZPL, take a look at the Public CVS, the Wikis, the 
fishbowls, the open-sourced literature, and then think again. Closure of 
code / internals is not an arguable point when it comes to Zope, that's just 
being paranoid.

You are welcome to take from the community, you are welcome to contribute to 
the community, you are welcome to make money with Zope. It's all there. 
Closure of code is not what will separate the wheat from the chaff, 
business-wise.

Couldn't-resisting-ly yours,
Danny


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] Zope expansion to 10x

2001-12-01 Thread Richard Volpato


It's ambitious as it is sensible -- to have Zope use expand tenfold.  But a
10x zope base needs to be clearly defined.  It impacts on markets,
architecture and community.   Talk about moving from a cathedral to a bazaar
is confusing (despite Raymond pitching it).

A Tenfold (10x) expansion can happen in three distinct ways -
via quantity (10x  more downloads  deployments),
via architecture (10x more functions), or
via commitment (10x more active in community).
The trick is to set in place initiatives that
harmonize and reinforce these three directions.

Zope is too big and complex to be sold by advertising (even informal) alone.
Ease-of-use is the critical success factor here. Relevance to specific
application domains is another.  The CMF (and skins), Zope Page Templates,
and an eventual 'zope-in-a-box' will drive the download/deployment rate.

A tenfold increase is also possible if all the zope instances currently
operating expanded in functionality.  Imagine a world with 4000, rather 400
Zope products.  Here the critical success factor is a Zope Product Manager.
Secondarily, there is a pressing need for a better taxonomy of products.
Currently the taxonomy used at Zope.org is refers to Zope rather more than
its applications.

A third dimension is one wherein the interaction between zope services and
components was 10 times better. Here is the land of 'new religion',
components and frameworks, of Transwarp etc.  The sooner components and
generic services arrive the better.

So far, so obvious.  The difficulty lies in not pushing on one of these
dimensions and thus undermines another.  For instance, a zope-in-a-box can
undermine 'commitment' (and community numbers) by expanding the user base
and yet contracting the questions they pose.  Similarly, more components
need to be prioritised to extend functionality (and thus breed more
community) rather than re-factor what is already there (and provoke arcane
debates on the list about architectural issues that are beyond most of the
community).

To get the balance, more opinion needs harvesting from the mass of people
that *use* Zope to solve specific problems.  I, for one, have been working
on finding application domains that enable 'mega-products' to be built:

ZAPPP - Zope Activated Participative Planning Platform, that enables local
government planning regulations to be transparently changed and kept
consistent with state-wide planning imperatives,

ZELBA - Zope Enabled Location Based Assistance - that enables local
communities to mobilise tiny fractions of 'spare time' (of locals) to
massively increase the opportunities for volunteer responses, or

ZEAR - Zope Enabled Authoring of Research - templated systems for students
to write and publish 'articles' while learning research skills.

ZOCCO - Zope Orchestrated Client-Centered Offices - by which dispersed care
professionals can operate bookings, follow-ups and counselling work in the
'human services' sector. etc etc

These kinds of possibilities still use the web - but they are some distance
from simply 'dynamic web publishing'.  I expect a 10x growth surge will move
down these application 'furrows' as much as the wide plains of web-serving.

This much is clear: it isn't a matter of cathedral vs bazaar, it is a matter
of having *both* - suitably located around a piazza of application
discussion.  So we need:
A)  Zope_Series-in-a-box
(focussed on application domains and easy to deploy for that reason)
B)  Zope Product Manager with the options to focus products around
   'mega-product' lines (again that's easier)
C)  A component architecture wherein generic services can be marshaled to
meet specific domains of challenges that relate to some real problem
in the world

The main missing piece here is a dedicated zope list about 'applications'
(under which all kinds of Zapplications might be discussed thus giving
direction to developers and users alike).

Oopps, this has got 10x bigger than I had expected. Hope length of argument
is matched by breadth of relevance and height of possibilities :)

Richard Volpato




 


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] Fully Zope-based Mailman Version

2001-12-01 Thread Stephan Richter

Hello everyone,

I just had a look into Mailman again. The API seems to be very clear, even 
though I could not find any UML diagrams anywhere. However I found out that 
porting Mailman to Zope (as a Python Product) might be a very simple task. 
Due to the nature of the project, the implementation phase could be setup 
in a couple of independent steps:

1. Convert the HTML screens to Zope DTML and connect the functionality to 
Mailman.
2. Move storage of list and user info to the ZODB
3. Move archives to the ZODB.
4. Create a nice installer that can bind the latest Mailman release with Zope.

I think a first alpha release could be produced in about 40-60 hours and 
the full-fledged Mailman Distribution beta in about 1.5 man-month (270 hours).

In fact most of the API would not even need to change, since we just need 
to insert our modified API at specific places, such as database 
connectivity and saving processes.

Later we could even provide a Mailman UserFolder and search functionality 
for the archive. For people that do not think that the ZODB is up to 
handling large archives, DBObjects could be used for transparent R2O 
mapping from PostGreSQL (or any other RDB).

The reason I write is, because I wanted to know whether someone would be 
interested in helping with this project, that would start after 
mid-December... Help can be offered in terms of programming or financial 
support of course.

Regards,
Stephan

--
Stephan Richter
CBU - Physics and Chemistry Student
Web2k - Web Design/Development  Technical Project Management


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )