[Zope-dev] using php on zope

2001-06-08 Thread Stian Jenssen

 Hi there!
 
 I wan't to use php with zope, does anybody know how the header syntax
 shall look like?
 Tried diffrent syntaxes but i get wierd outputs, not as expected. 
 

___
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] ANN: ReplacingDateTime proposal

2001-06-08 Thread Erik Enge

On Thu, 7 Jun 2001, Andreas Jung wrote:

 Feel free to review and comment the propsal to replace
 the current DateTime module of Zope by the mxDateTime module:

From the proposal:


License issues

mxDateTime stands under the EGENIX Public License that is considered to be
an Open Source license. It should be compatible to GPL except there is
discussion about the choice of the law clause between R. Stallmann and
M-A. Lemburg


Shouldn't it be focused on compatability with the ZPL instead of the
GPL?  From what I hear, there still are issues with, for example,
distributing Python Products as GPL with Zope.

Anyone with better knowledge about this care to enlighten me?


___
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] ANN: ReplacingDateTime proposal

2001-06-08 Thread Stephan Richter


Shouldn't it be focused on compatability with the ZPL instead of the
GPL?  From what I hear, there still are issues with, for example,
distributing Python Products as GPL with Zope.

Anyone with better knowledge about this care to enlighten me?

See an earlier post on a different thread. Chris wrote that the license is 
BSDish and is therefore compatible with ZPL. This means that mxDateTime 
could be distributed with Zope.

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 )



Re: [Zope-dev] Bug in Zope VersionControl

2001-06-08 Thread Martijn Pieters

On Thu, Jun 07, 2001 at 08:30:26PM +0200, Christian Theune wrote:
 Okay ... I admit using opera and enjoying it.
 
 Problem is, that opera is sooo standardsconform.
 
 See Zope/lib/python/Products/OFSP/Version.py:175
 in function enter()
 
 Somebody thats the path for the cookie as SCRIPT_NAME.
 This seems that the scope of the versions should be
 limited to the subtree where the version object was 
 instanciated. Nice idea.
 
 But this doesn't work.
 
 First:
 
 Internet Explorer and Netscape ignore the path of the cookie
 and assume '/'.
 
 Second:
 
 Opera is conform to the rfc of http 1.1, and this means, that 
 the cookie is only valid for the version itself, and is not
 used in any place out of http://myzope:8080/blaah/myVersion
 
 Proposed solution:
 
  Change the path to '/'. And have the same behaviour on all
  browsers.
 
 Or:
 
  Change the path to REQUEST[URL1] (is this the parent folder?)
  and have the intended mechanism working at least on opera.
 
  The last is my personal favorite, because you can have different
  versions concurrently open on different projects @ one server.
 
 Proposed patch for both solutions comes as attachement.

REQUEST['SCRIPT_NAME'] is the root of the Zope server. In a pure ZServer
environment, this is '/'. In a situation where the Zope server is running
behind another webserver, and is not at the root of that server,
SCRIPT_NAME represents the path to the Zope server.

For instance, if your Zope server is presented to the outside world as
'http://a.server.com/a/path/to/zope/' then SCRIPT_NAME will be
'/a/path/to/zope/', whereever you are in the Zope object hierarchy.

Thus, a version cookie is bound to the root of the Zope server. In your
case, it seems that Opera is ignoring the cookie path altogether, and
instead falls back on the default, which is the path of the Version object
itself.

-- 
Martijn Pieters
| Software Engineer  mailto:[EMAIL PROTECTED]
| Digital Creations  http://www.digicool.com/
| Creators of Zope   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] How to return downloadable content from Python Method

2001-06-08 Thread Blandford, Simon [BSS Audio UK]



I am compressing 
files which need to be uncompressed inline before download. The DTML 
href="..." calles a python method in the product which returns the 
uncompressed file data. Say this file is an MSWord document, how do I return 
this as a file to download? Presently, the browser just tries to display the 
binary file and makes a mess of it.

Regards,
Simon 
B.


[Zope-dev] AW: Zope-Dev digest, Vol 1 #1148 - 12 msgs

2001-06-08 Thread Jana Mahlke

unsubscribe!!!

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im Auftrag
von [EMAIL PROTECTED]
Gesendet: Freitag, 8. Juni 2001 12:08
An: [EMAIL PROTECTED]
Betreff: Zope-Dev digest, Vol 1 #1148 - 12 msgs


Send Zope-Dev mailing list submissions to
[EMAIL PROTECTED]

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.zope.org/mailman/listinfo/zope-dev
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]

You can reach the person managing the list at
[EMAIL PROTECTED]

When replying, please edit your Subject line so it is more specific
than Re: Contents of Zope-Dev digest...


Today's Topics:

   1. Re: Property Storage (Phillip J. Eby)
   2. Re: Bulletproof ZCatalog proposal (Shane Hathaway)
   3. Re: [Announce] API Documentation Fishbowl Project (R. David Murray )
   4. Re: Bulletproof ZCatalog proposal (Shane Hathaway)
   5. Re: Bulletproof ZCatalog proposal (Phillip J. Eby)
   6. DCOracle2 Beta 2 (Matt Kromer)
   7. RE: A simple dtml-if question... (Jeff Nielsen / UgoFast)
   8. using php on zope (Stian Jenssen)
   9. Re: ANN: ReplacingDateTime proposal (Erik Enge)
  10. Re: ANN: ReplacingDateTime proposal (Stephan Richter)
  11. Re: Bug in Zope VersionControl (Martijn Pieters)
  12. How to return downloadable content from Python Method (Blandford,
Simon [BSS Audio UK])

--__--__--

Message: 1
Date: Thu, 07 Jun 2001 15:46:42 -0500
To: Chris Withers [EMAIL PROTECTED],[EMAIL PROTECTED]
From: Phillip J. Eby [EMAIL PROTECTED]
Subject: Re: [Zope-dev] Property Storage

At 09:29 PM 6/7/01 +0100, Chris Withers wrote:

If I change one property on, say, a DTML Document, does that store a whole
new copy of the document in the ZODB?

It updates the object in the ZODB.  Whether that causes a copy to be made,
depends on the underlying storage.  FileStorage makes copies,
BerkeleyStorage (at least Ty's first implementation thereof) does not.


Is so, then how about storing properties in their own mini-class that just
subclassed Persistent, so each property got its own pickle jar?

There are a lot of things you'd have to tinker with to get that behavior.
You would probably be better off just using a storage that doesn't make
copies, or using ZPatterns to store selected attributes in such a storage
(such as a differently-backed ZODB, the filesystem, or an SQL or LDAP
database).



--__--__--

Message: 2
Date: Thu, 7 Jun 2001 17:13:06 -0400 (EDT)
From: Shane Hathaway [EMAIL PROTECTED]
To: Phillip J. Eby [EMAIL PROTECTED]
Cc: Erik Enge [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [Zope-dev] Bulletproof ZCatalog proposal

On Thu, 7 Jun 2001, Phillip J. Eby wrote:

 I was thinking that certain types of objects would be committed by the
 transaction manager before all others.  In this case, the catalog (or a
 special object in the catalog) would be committed first.  It would
 resolve all conflicts in the contained indices before they occur by
 replaying the changes in the persisted queues from the transaction
 history, then setting the _p_serial attributes to convince the storage
 that the conflicts have already been resolved.

 Hm.  Sounds to me like what you actually want is for the transaction
 manager to do this *after* everything else, rather than before.  Thus, you
 would catch any changes which occur *during* transaction commit - such as
 commit-phase cataloging (as some folks do with ZPatterns currently).

Maybe I didn't explain this clearly enough.  Let me write some quick
pseudocode:


class Catalog (Persistent):
  finished_changes = None   # Mapping: {path - (object, adding)}
  unfinished_changes = None # Same as above
  tid = None# Transaction ID

  def catalogObject(self, ob, path):
unf = self.unfinished_changes
if unf is None: self.unfinished_changes = unf = {}
unf[path] = (ob, 1)

  def uncatalogObject(self, path):
unf = self.unfinished_changes
if unf is None: self.unfinished_changes = unf = {}
unf[path] = (ob, 0)

  def searchResults(self, ...):
self.finishChanges()
# ... Perform search ...
return results

  def finishChanges(self):
unf = self.unfinished_changes
if unf is not None:
  fin = self.finished_changes
  if fin is None or self._p_serial != self.tid:
# Create finished_changes if not yet created
# and clear it if we're in a different transaction
# from the last time finished_changes was changed.
self.finished_changes = fin = {}
self.tid = self._p_serial
  for path, (ob, adding) in unf.items():
if adding: self.addToIndexes(ob, path)
else: self.removeFromIndexes(path)
fin[path] = (ob, adding)
  self.unfinished_changes = None

  def __getstate__(self):
# Called during transaction commit.
self.finishChanges()
return Persistent.__getstate__(self)

  def _p_priority(self):
# Causes this object to be added to the *top*
# of the list of 

Re: [Zope-dev] ANN: ReplacingDateTime proposal

2001-06-08 Thread Erik Enge

On Fri, 8 Jun 2001, Stephan Richter wrote:

 See an earlier post on a different thread. Chris wrote that the
 license is BSDish and is therefore compatible with ZPL. This means
 that mxDateTime could be distributed with Zope.

Yes, but in the proposal Andreas mentions the GPL, not the ZPL, and that
is what throws me off.


___
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: Fwd: [Zope-dev] How to return downloadable content from Python Method

2001-06-08 Thread Gregor Heine

 I am compressing  files which need to be uncompressed inline 
 before download. The DTML  href=... calles a python method 
 in the product which returns the  uncompressed file data. Say 
 this file is an MSWord document, how do I return  this as a file 
 to download? Presently, the browser just tries to display the 
 binary file and makes a mess of it.
 
 Regards,
 Simon  B. 

Hi Simon,

First off, please don't send HTML mail to the list.

You will have to set the Content-Type HTTP header to do that:
REQUEST.RESPONSE.setHeader('Content-Type', content_type)
where content_type is the right MIME type of the file you return, e.g.
something like 'application/msword' in your case.
Hope  that helps.

Cheers,

Gregor.


-- 
Machen Sie Ihr Hobby zu Geld bei unserem Partner 11!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a

--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net


___
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: Fwd: [Zope-dev] How to return downloadable content from Python Method

2001-06-08 Thread Blandford, Simon [BSS Audio UK]

Hi Gregor,

 First off, please don't send HTML mail to the list.

Ouch! Sorry! Easy mistake to make.

 
 You will have to set the Content-Type HTTP header to do that:
 REQUEST.RESPONSE.setHeader('Content-Type', content_type)
 where content_type is the right MIME type of the file you return, e.g.
 something like 'application/msword' in your case.
 Hope  that helps.

Yes it works! Thankyou for your help.

Much appreciated,
Simon B.

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



[mj@digicool.com: Re: [Zope-dev] Bug in Zope VersionControl]

2001-06-08 Thread Martijn Pieters

(Could we please keep the list in the loop for both wider discussion and
archiving?)

On Fri, Jun 08, 2001 at 01:43:29PM +0200, Christian Theune wrote:
  REQUEST['SCRIPT_NAME'] is the root of the Zope server. In a pure ZServer
  environment, this is '/'. In a situation where the Zope server is running
  behind another webserver, and is not at the root of that server,
  SCRIPT_NAME represents the path to the Zope server.
  
  For instance, if your Zope server is presented to the outside world as
  'http://a.server.com/a/path/to/zope/' then SCRIPT_NAME will be
  '/a/path/to/zope/', whereever you are in the Zope object hierarchy.
  
  Thus, a version cookie is bound to the root of the Zope server. In your
  case, it seems that Opera is ignoring the cookie path altogether, and
  instead falls back on the default, which is the path of the Version object
  itself.
 
 Okay. I have something for you.
 
 The REQUEST['SCRIPT_NAME'] is '' on my server. Could it be that - if zope
 is on the root - it SHOULD be '/' but is ''?

You are correct, SCRIPT_NAME is indeed '' in ZServer situations. However,
see below.

 Then per RFC it should be the location of the request (in this case 
 http://localhost:8080/asdf, where asdf is the version).

The RFC is silent about this. Note that there are two specifications that
may apply. One is the original Netscape specification, the other is RFC
2109:

  http://www.netscape.com/newsref/std/cookie_spec.html
  http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2109.html

There is also a RFC2965 which defines a new 'Set-Cookie2' header with a
new syntax.

Neither RFC 2109 nor the Netscape spec specify what happens when a
'path=;' cookie is sent, they only specify what happens if the path
attribute is absent.

The fact that we set an empty path attribute is thus confusing and we
should avoid this.

 IE and Netscape poorely ignore the path, but Opera restricts the cookie
 to the location of the Version.

IE and Netscape have decided that in that case the server must have ment
to say 'path=/;', while Opera chooses to interpret it the same way as an
omitted path attribute.

 Probably you want to check:
 
 if REQUEST['SCRIPT_NAME']=='':
   REQUEST['SCRIPT_NAME']='/'
 
 wherever this variable is created ...
 ???

I think we want to use:

  RESPOSE.setCookie(
  path=(REQUEST['SCRIPT_NAME'] or '/'))

Could you file a bug in the Bug Collector at:

  http://classic.zope.org:8080/Collector

Thanks!

-- 
Martijn Pieters
| Software Engineer  mailto:[EMAIL PROTECTED]
| Digital Creations  http://www.digicool.com/
| Creators of Zope   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 )



Re: [Zope-dev] using php on zope

2001-06-08 Thread Erik Enge

On Fri, 8 Jun 2001, Stian Jenssen wrote:

 Hi there!

Hello :)
 
 I wan't to use php with zope, does anybody know how the header syntax
 shall look like? Tried diffrent syntaxes but i get wierd outputs, not
 as expected.

Try this one: URL:http://www.zope.org/Members/Mamey/PHP.


___
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] Bug in Zope VersionControl

2001-06-08 Thread Martijn Pieters

On Fri, Jun 08, 2001 at 02:17:06PM +0200, Christian Theune wrote:
 yes. we are right. Opera only sends the cookie in the version, but i couldn't
 figure out, what zope is sending (using the tcpwatch proxy). so i don't know
 what zope returns ...
 the should be a line 
 
 == Cookie: ...
 
 or something I think, but there isn't.

As soon as you press the 'join' button, Zope will send a 'Set-Cookie'
header.

-- 
Martijn Pieters
| Software Engineer  mailto:[EMAIL PROTECTED]
| Digital Creations  http://www.digicool.com/
| Creators of Zope   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 )



Re: [Zope-dev] Bug in Zope VersionControl

2001-06-08 Thread Evan Simpson

From: Martijn Pieters [EMAIL PROTECTED]
 REQUEST['SCRIPT_NAME'] is the root of the Zope server. In a pure ZServer
 environment, this is '/'. In a situation where the Zope server is running
 behind another webserver, and is not at the root of that server,
 SCRIPT_NAME represents the path to the Zope server.

SCRIPT_NAME is not reliable in the presence of virtual hosting.  Use
REQUEST['BASEPATH1'] instead.

Cheers,

Evan @ digicool


___
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] Bug in Zope VersionControl

2001-06-08 Thread Martijn Pieters

On Fri, Jun 08, 2001 at 09:36:53AM -0400, Evan Simpson wrote:
 From: Martijn Pieters [EMAIL PROTECTED]
  REQUEST['SCRIPT_NAME'] is the root of the Zope server. In a pure ZServer
  environment, this is '/'. In a situation where the Zope server is running
  behind another webserver, and is not at the root of that server,
  SCRIPT_NAME represents the path to the Zope server.
 
 SCRIPT_NAME is not reliable in the presence of virtual hosting.  Use
 REQUEST['BASEPATH1'] instead.

When we fix this problem, we indeed should use BASEPATH1. BASEPATH1 is
also empty when in a ZServer-only situation, so we should still use
path=(REQUEST['BASEPATH1'] or '/').

-- 
Martijn Pieters
| Software Engineer  mailto:[EMAIL PROTECTED]
| Digital Creations  http://www.digicool.com/
| Creators of Zope   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 )



Re: [Zope-dev] Bug in Zope VersionControl

2001-06-08 Thread Andreas Jung


- Original Message -
From: Martijn Pieters [EMAIL PROTECTED]
To: Evan Simpson [EMAIL PROTECTED]
Cc: Christian Theune [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, June 08, 2001 9:31 AM
Subject: Re: [Zope-dev] Bug in Zope VersionControl


 On Fri, Jun 08, 2001 at 09:36:53AM -0400, Evan Simpson wrote:
  From: Martijn Pieters [EMAIL PROTECTED]
   REQUEST['SCRIPT_NAME'] is the root of the Zope server. In a pure
ZServer
   environment, this is '/'. In a situation where the Zope server is
running
   behind another webserver, and is not at the root of that server,
   SCRIPT_NAME represents the path to the Zope server.
 
  SCRIPT_NAME is not reliable in the presence of virtual hosting.  Use
  REQUEST['BASEPATH1'] instead.

 When we fix this problem, we indeed should use BASEPATH1. BASEPATH1 is
 also empty when in a ZServer-only situation, so we should still use
 path=(REQUEST['BASEPATH1'] or '/')

The fix is now in the 2.4 trunk.

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] Bug in Zope VersionControl

2001-06-08 Thread Martijn Pieters

On Fri, Jun 08, 2001 at 09:42:00AM -0400, Andreas Jung wrote:
  On Fri, Jun 08, 2001 at 09:36:53AM -0400, Evan Simpson wrote:
   From: Martijn Pieters [EMAIL PROTECTED]
REQUEST['SCRIPT_NAME'] is the root of the Zope server. In a pure
 ZServer
environment, this is '/'. In a situation where the Zope server is
 running
behind another webserver, and is not at the root of that server,
SCRIPT_NAME represents the path to the Zope server.
  
   SCRIPT_NAME is not reliable in the presence of virtual hosting.  Use
   REQUEST['BASEPATH1'] instead.
 
  When we fix this problem, we indeed should use BASEPATH1. BASEPATH1 is
  also empty when in a ZServer-only situation, so we should still use
  path=(REQUEST['BASEPATH1'] or '/')
 
 The fix is now in the 2.4 trunk.

Note that there are 3 bugs open on this, 2291 (which you set to
Forgotten'?), 2225 and 2234.

Also, you'll have to hunt out all usage of path=REQUEST['SCRIPT_NAME'],
not just the one that you fixed. There is at least one other in
Version.py, and there may be more. I think you should search for
setCookie.

And last, this should also go in the 2.3 branch I think. It is a small
enough bugfix, and some people will be reluctant to switch to 2.4.x just
yet.

-- 
Martijn Pieters
| Software Engineer  mailto:[EMAIL PROTECTED]
| Digital Creations  http://www.digicool.com/
| Creators of Zope   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 )



Re: [Zope-dev] Bug in Zope VersionControl

2001-06-08 Thread Dieter Maurer

Christian Theune writes:
  Internet Explorer and Netscape ignore the path of the cookie
  and assume '/'.
Who told you that?

We use code explicitly setting the cookie path and
it appears both IE and Netscape handle this correctly.

  Second:
  
  Opera is conform to the rfc of http 1.1, and this means, that 
  the cookie is only valid for the version itself, and is not
  used in any place out of http://myzope:8080/blaah/myVersion
That's the default cookie path.

Maybe, setting the cookie path explicitly removes the problem.



Dieter

___
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] Bulletproof ZCatalog proposal

2001-06-08 Thread Phillip J. Eby

At 04:58 PM 6/8/01 -0400, Shane Hathaway wrote:
On Thursday 07 June 2001 21:28, Phillip J. Eby wrote:
  Upon being told to perform a transaction or subtransaction commit,
  the transaction would notify all the ruleAgents, and then all the
  indexingAgents.  Objects could still subscribe to either queue while
  this notifying is taking place.  (So that triggered actions could
  cause indexish objects to register as indexingAgents, not to mention
  causing updated objects to fire additional triggers.)
 
  Once all agents in a queue are notified, that queue should be cleared
  so that notifications are on a per-subtransaction basis.  Once both
  queues are cleared, normal transaction behavior goes forward.

Would you say this would occur before tpc_begin() messages or just
after?

Before.  I'm saying this would take place immediately at the start of the 
existing Transaction.commit() method.


  Hm.  That's simpler than I thought it was going to be.  Shoot, I can
  even see how to implement it as a runtime patch, that would've been
  simpler than all the shenanigans ZPatterns goes through to fake out
  the transaction machinery...  and it's a better
  implementation.  Ah well.  At the time I wanted to avoid trying to
  convince Jim to add machinery to transactions just for ZPatterns,
  given that ZPatterns wasn't a particularly established product at the
  time.
 
  Let me know if you guys put something like this in, though, and I'll
  definitely look at reworking ZPatterns to use the mechanism.  It
  could potentially cut a lot of code out and improve the robustness at
  the same time.

I don't foresee us adding this capability right away since we need to
understand it better and it only applies to one working product and a
hypothetical product.  I'd suggest you go ahead with the runtime patch.

I think I'll wait until ZPatterns works with Zope 2.4, unless it becomes 
necessary otherwise.  Replacing what I've got now is a pretty significant 
undertaking, and risk-prone to boot, so I don't want to delay the finishing 
of ZPatterns' support for Zope 2.3.x.

Basically, the runtime patch would be to replace 
ZODB.Transaction.Transaction with a subclass that implemented the 
notification queues in the commit() method.  There'd be a few other little 
extensions needed, like clearing the queues on any abort operation, and 
adding registerIndex() and registerRule() or some such methods.


___
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] ] [Announce] API Documentation Fishbowl Project

2001-06-08 Thread jimbo

--On Wednesday, June 06, 2001 11:50:43 AM -0700 jimbo 
[EMAIL PROTECTED] wrote:

 I hope this helps. I wanted to add my feelings on the whole documentation
 issue.  It seems to me that the whole process caters around developers
 too much.

I have to disagree with you **in the context of this thread** for two 
reasons:

Why disagree **in the context of this thread** at all?
Alot of things change quickly in this field, so flexibility is a must to me.


 1. DC has done a lot to improve the documentation for non-developers  in the 
 last year.  The Zope Book(s) should have a major impact when they start to 
 appear on shelves in the next month or so.  

My point

Developer documentation has lagged behind.  

There still is alot of progress being made in that direction



 This thread is about a proposal to improve developer 
documentation.  It says nothing at all about the other *existing* efforts 
by DC and others to improve other types of Zope documentation.

I think you have a misunderstanding of freedom and opensource all in one topic.  I'm 
don't follow you here since I know it helps to get feeback from users of a product. 
I'm talking about improving the API documentation.

  I seriously wonder how good that API is going to do me if I can't use it in the 
workplace today or next week.
Everyday I see post like this
http://lists.zope.org/pipermail/zope-cmf/2001-June/007427.html

excerpt
I'm having trouble using the Guard expression in DCWorkflow 0.2.
Everything else works fine; it's a great product.

I think the call to expr() in the ..
I do not really know what I'm doing there... but it works :)




   My point is Python is/was suppose to be this language so easy and simple that it 
should be the first language to teach a person.  Where does that simplicity get lost 
with Zope I wonder?
  Don't even answer because it does'nt matter to me or the other it departments that 
are going with other solutions.

  So go on while the confusion is there. Go ahead and justify it now by saying 
polishing the API will do it for the masses. When you look at the big picture the 
developer is the smallest user group of any software product.( you have the end-user, 
testers, admins,etc)
That's why it's even more important to make sure the API docs make it easy to 
implement something and not wow this is so cool and has so many features without the 
benefits.

I also think a pretty good example is what Ty and Phillip did with ZPatterns.  They 
had plenty of how-to implement in the API Documentation. It did take alittle while 
though, but thanks many times over for the learning experience it was fun.

In other words half scientific facts(This is)/ half hocus pocus(Do This).



2. One of the main points DC made at this years Python conference was that 
they have tried to focus the Zope core on too many audiences at once.  
Yes a problem.


They 
had to have a clearer focus and chose developers as that focus.  

Of course they did.  We're talking about Core services here.  Like I said before 
once again I think it's the impletation part I'm stuck on.



Of course 
I like this choice because I am a developer, but the more important point 
is that this tighter focus has the potential to make life easier for all of 
us.

No just developers.  You can call it what you want, but it is a tool that developers 
can use to get a job done.  Content mangers and other network admin types about the 
API anyway.  I imagine most if not all of zope users are progammers in some sense.

Incremental restructuring of the Zope core and improved Zope developer 
documentation makes it much easier and more practical for DC and others to 
create layered Zope products that address other communities.  


Seems to be my point also.  Perhaps I stepped in some fishpoo and need to learn how to 
get involved with the Fishbowl process.


Thanks,
Jimbo


___
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] [Announce] API Documentation Fishbowl Project

2001-06-08 Thread jimbo

Or how about this person?
http://lists.zope.org/pipermail/zope-cmf/2001-June/007435.html


oh oh a storm gotta go
-jimbo

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