Re: [Zope-dev] CompressedStorage

2001-05-31 Thread Ty Sarna

Erik Enge  [EMAIL PROTECTED] wrote:
 has anyone given this a good run?  I'm a bit confused as to how to make it
 work.  Do I just subclass it in FileStorage?

No, you wrap it around an underlying storage (such as FileStorage).

When Zope starts up, it looks for the module to figure
out what storage to use.  Zope basically uses whatever object
custom_zodb.Storage is as the storage. If there isn't a,
Zope acts as if there was one that said [*]:

import Globals, ZODB.FileStorage


What you want to do is create a FileStorage, and wrap it with a
CompressedStorage and use that. Your would look like:

import Globals, ZODB.FileStorage, ZODB.CompressedStorage

Storage=ZODB.CompressedStorage.CompressedStorage(Storage, 2048)

2048 is the compression threshhold. Anything smaller than that
CompressedStorage won't bother trying to compress. Adjust that number as
you see fit. 1024 might be a better defaul. Note that if it tries to
compress data and it doesn't come out any smaller, it will store it
uncompressed. The threshold decides how big data has to be before it's
worth even trying to make it smaller.

BTW, you should be able to wrap a CompressedStorage around just about
anything, not just a FileStorage. You can have a compressed
BerkeleyStorage or whatever.

[*] this is simplified for ease of explanation... it doesn't really work
this way.

 Will it work with existing
 Data.fs or do I need to start anew, so to speak?

See the comments at the start of You should be
able to layer it over an existing storage (such as an existing
FileStorage Data.fs). Only newly-written objects will be compressed (if
they're big enough). Of course, once you have compressed objects in the
Data.fs, you have to keep using CompressedStorage. So yes, you can
switch, but you can't switch back :-)

BTW, DC people... you should feel free to include CompressedStoage in

Also, I'm sure it would be appreciated if anyone (DC or not) took the
time to write a HowTo on (hopefully more detailed and
accurate than above)

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

[Zope-dev] Announcing ZPatterns TransWarp list and CVS

2001-05-28 Thread Ty Sarna

I'm pleased to announce that I've finished the last task in setting up a
bunch of new services for ZPatterns and TransWarp users: writing this
announcement. :-)

First, we now have mailing lists: [EMAIL PROTECTED] and
[EMAIL PROTECTED] To subscribe, visit:

Second, we've made our CVS repository more accessible.  Major packages
of interest are ZPatterns, PlugIns, and LoginManager under the ZProducts
directory, and TW (TransWarp) under the pylib directory.  There's other
stuff there as well, but most of it is currently in flux and lacking
documentation, and you should ask before deciding to base any code
on it.

You may browse the cvs tree with ViewCVS at:

Or access it via anoncvs using the CVSROOT:

:pserver:[EMAIL PROTECTED]:/cvsroot

You will need to login with the password anoncvs before you
will be able to access file. Sample session:

For sh-type shells:
$ export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvsroot

For csh-type shells:
$ setenv CVSROOT :pserver:[EMAIL PROTECTED]:/cvsroot

Now, log in:
$ cvs login
(Logging in to [EMAIL PROTECTED])
CVS password: anoncvs

Now you can cvs co ZProducts/ZPatterns, or whatever.

There is an additional mailing list, [EMAIL PROTECTED], that
carries cvs commit messages.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

[Zope-dev] Re: Find broken in 2.2.2?

2001-01-24 Thread Ty Sarna

Ty Sarna [EMAIL PROTECTED] wrote:
 Is there something wrong with the Find mechanism in 2.2.2? "containing"
 searches never find anything. I've looked at the changelogs for

I've narrowed this down further... the issue seems to be that items
inside zclass definitions aren't found.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

[Zope-dev] Find broken in 2.2.2?

2001-01-18 Thread Ty Sarna

Is there something wrong with the Find mechanism in 2.2.2? "containing"
searches never find anything. I've looked at the changelogs for
post-2.2.2 versions and didn't see anything about this being fixed, so
either it was fixed but not documented, it's still broken, or it's
something peculiar to my setup.

This is a real problem for managing complex applications...  Oh, for the
good old days of grep. 

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] New UI for 2.3

2001-01-12 Thread Ty Sarna

Brian Lloyd [EMAIL PROTECTED] wrote:
 Are you guys working on 486's with 13in. monitors at 640x480 or 
 something? :^)

At home I run 21" @ 1600x1280.  And there's a reason I shelled out for
that: I want to get lots of information on the screen.  I didn't buy
extra space just so you could go wasting it :^) Netscape already wastes
a lot of space at the top of the window...

I tend to run multiple browser windows all at the same time: one for the
user's view of the application, and at least one for development.
Sometimes more than one, perhaps one in the Product area for editing the
zclasses and one in the mail tree for editing the app, because it's a
pain to navigate back and forth between the two.

Also, the laptop issue that was raised was valid.

 concerned with function over form. But is it really so bad to 
 make a 32 pixel-high concession to a small pittance of branding? 


 I know that "branding" isn't important for those who are already 
 believers, but Zope has grown enough that its reasonable to put 
 some effort into "first impression factor". It doesn't help the 

To me, this would result in a less positive first impression.
Also, I really much prefered the blue tabs to the black. The black ones
look much flatter.

Don't get me wrong, I like what's been done with the lower part of the
screen. But I hate everything above the "objecttype at path" line.

And what ever happened to the Fishbowl? The only way to see way what
this looks like is to download and build the alpha.  That seriously
limits the visibility.  Also, the current fishbowl project on this is
effectively negative visibility, since it contains screenshots that
don't have anything to do with the actual look and feel.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] [ZPatterns] DataSkin object ownership

2000-12-14 Thread Ty Sarna

Phillip J. Eby [EMAIL PROTECTED] wrote:
 At 08:04 PM 12/12/00 -0500, BS wrote:
 Do DataSkins have ownership? I want to give multiple users the ability to
 add objects to a rack and only allow the 'owner' to view/edit the object.
 DataSkins stored in Racks do not participate in the Zope ownership
 mechanism, nor the creation of the 'Owner' role.  This is because they are

To clarify: if you just want Owner roles, as opposed to Ownership[1][2][3],
you can do that with totally-non-ZODB objects.  I have a couple
different applications where totally SQL- or LDAP- are given local roles
(Owner and others) to implement security as you describe. 

The way we do it requires LoginManager to be in use, or to have patched
Zope with improvents to the local roles support (LM effectively hotfixes
these in for its own users). Then our DataSkins-based ZClasses also
mix in AppTabs[4], which has a get_local_roles_for_user() which tries
a LocalRolesForUser() method if it exists, otherwise falls back to older
means. Finally, you can define LocalRolesForUser to compute local roles
for the accessing user by whatever rules it wants.

[1] People may complain about ZPatterns terminology, but at least we
have the sense not to use the same word for two entirely different
concepts! :-)

[2] And I don't know why you'd care about Ownership for your objects in
this example...  it doesn't seem meaningful for these sorts of non-code

[3] Actually, maybe you could write SkinScript to provide the _owner
attribute. But see [2]...

[4] Unreleased product, still in some flux.  It mainly provides fancier,
more flexible version of Zope's management tabs, suitable for use in an
application (that is, suitable for exposing to users, not just
developers). It also has some local roles hooks as mentioned.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] BerkeleyStorage (was: Re: OracleStorage, and possibly others)

2000-11-29 Thread Ty Sarna

In article 01ba01c05a42$edabbb10$1f48a4d8@kurtz,
Chris McDonough [EMAIL PROTECTED] wrote:
 I actually need to get a BerkeleyStorage against BSDDB3 going for a customer
 fairly soon.  Jim has done a lot of work on it, and it's looking like I'll
 probably end up finishing it.  Robin Dunn has a Python extension module

Ah, cool!

 against the bsddb3 libraries that we're using.  It may actually be released
 as several storages (undoing and nonundoing).

Once upon a time, I had planned to do (and had some code towards):

no-versions, no-undo
versions, undo
versions, undo only within versions

with a "table" structure such that you could migrate from one to

The last option is possibly useful for sites with objects that change a
lot (so you don't want undo), but where you want to use versions for
code development (which requires undo...  note the lack of a "versions,
no-undo" combo.  That one won't work usefully, because you can trivially
get stuck.  You get something locked in the version, and there's no way
to recover short of committing the entire version. "no-versions, undo" is
possible, but doesn't seem to really buy anything)

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] License issues

2000-11-15 Thread Ty Sarna

Jimmie Houchin  [EMAIL PROTECTED] wrote:
 The GPL would protect DC from predatory competitors. It would also allow
 for Zope's adoption in certain environments. I also believe some people

And prevent it in others.

 would relicense their products to the GPL if it were Zope's native

While other products would suddently become license-incompatible.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Using LoginManager with users stored in several Specialists

2000-10-24 Thread Ty Sarna

In article a05001900b61b0b6ac87c@[],
Itai Tavor  [EMAIL PROTECTED] wrote:
 - I'm not sure how to customize a UserSource to access the 
 propertysheets on the Customer and Reseller classes. The easiest way 
 seems to be to define userExists, userRoles and userAuthenticate 
 methods in a GenericUserSource, but I don't think it's a good idea - 
 I still wouldn't know how to make changes to the propertysheet from 
 the LoginManager (for example, changePassword should be a method of 
 acl_users, not of the user classes, because it does the same thing 
 for all user types), and there is no caching. Should I write my own 
 UserSource? Or can I do it with Data Plug-ins? I'd like to keep the 
 solution simple, but I do want it to be efficient (fast and cached).

Generic User Source is basically for people who are familar with GUF and
want some degree of backward compatability. There was also a time where
it was the only choice :-)

Now there is "User Source", which is to LoginManager what Rack is to
Specialist. It's completely general, defaulting to storing things
persistently, but overrideable with SkinScript and the "load from
existence of attribute blah" to do anything you want. It's much more
Generic than Generic User Source, actually :)

Have a look at the SkinScript reference for the "Object Remapping"
example (last one under WITH ...  COMPUTE ...) of how to make a Rack
that retrieves proxyies for objects from a different Specialist. You
can direcly apply this same technique to have a User Source provide
users based on objects in other Specialists.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] FYI: preliminary Zope 2.3 plan online...

2000-09-21 Thread Ty Sarna

Brian Lloyd [EMAIL PROTECTED] wrote:
 Hi all - 
 For those interested, I've finally gotten the current plan for 
 the next planned Zope feature release online on

The discussion pages for at least two of the wikis are broken. This is
especially troubling considering that it looks like you're planning on
moving forward with a proposal with serious unaddressed issues in a (now
inaccessible) discussion!

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Wiki Pain

2000-09-14 Thread Ty Sarna

Toby Dickenson  [EMAIL PROTECTED] wrote:
 10. There are too many empty pages, because someone has clicked on a ?
 next to word that happened to be a WikiName. Useful pages lie hidden
 behind a sea of links to empty pages.

IMHO, ZWiki is broken in this respect. Clicking on a '?' shouldn't
create a page and take you to the edit form -- it should take you to an
edit form, which creates the page on save. I think this would
subtantially reduce the number of empty pages created.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] OFS.objectManager checking object Ids

2000-08-11 Thread Ty Sarna

Jim Fulton  [EMAIL PROTECTED] wrote:
  bad_id=ts_regex.compile('[^a-zA-Z0-9-_~\,\. ]').search #TS

 I think that it's a bad idea to allow '?'s in ids
 and am sorry if it was allowed. In general, I don't
 like to see characters in ids that need to be quoted.
 I'm not happy that ' ' was added, although 
 I understand why.

Could '=' be added to the allowed characters, please? It works fine that
way, AFAICT, and it's handy if you want to reflect LDAP-like namespaces
in a Zope application. And ZLDAPConnection support '=' in path
components, so it seems kind of silly for Zope itself not to.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Comments on ZPatterns

2000-07-03 Thread Ty Sarna

Chris Withers  [EMAIL PROTECTED] wrote:
 1. Too much jargon... by far... Lots of complicated words that are
 meanlingless to the layman and don't help to convey the concepts. This

Can you point out some examples of which ones you think are especially bad?

 is compounded by the standard Zope problem of minimal documentation
 aimed at the advanced developer. Can someone who understadns this all
 take the time to write a ZPatterns guide to compliment the Wiki and
 maybe simplify or explain in great detail all the terms (especially the
 new ones that have popped up in the last few weeks)?

Naming has been a struggle.  It's hard to come up with descriptive names
for these things.  Part of the confusion is that some things have been
renamed in an effort to make the meanings clearer in the long term.  But
short term, it's confusing and it seems like there are lots of new
concepts, when in fact there are just several names for the same concept
(Implementor - Specialist, Rack-mountable - DataSkin, etc).  I'll also
admit that Rack-mountable was a clearer name, but it was no longer
accurate.  We tend to err on the side of a name that doesn't clearly
describe something instead of a name that clearly describes something,
but describes it *wrong* so that you think you understand something and
really don't.  ("Well, at least the name tells you that you don't know
what it is!", as I've said :-)

 2. Feature runaway. It seems every day something new (and more
 confusing) has been added to ZPatterns. I think ZPatterns will only work
 if it is kept as simple and functional as possible. My view (bearing in

You mention in another post that you feel lots of unnecessary features
have been added -- can you give some examples of which ones you feel are
extraneous? There has been only one major feature added in ZPatterns
0.4.0, which is the ability to have Rack-mountable-like things that
don't live in racks.  This is important for PTK-like applications where
you don't want to lump everything into one container, but would instead
like to have it distributed between member's folders, for example.  I
think it was worth it. 

Part of the percieved feature runnaway I think is due to the renaming
issue described above.  Also, a lot of what looks like adding of
features is actually reorganization and simplification of features that
were already there.  There's no need now for SQL Racks vs.  LDAP Racks
vs.  ZODB Racks, for example.  New features were added, but mainly to
avoid the need for other features to even exist.  In a lot of ways, the
code keeps getting simpler and shrinking (as an example, look at the
early LoginManager releases vs what's there now -- the code shrank
considerably and got much clearer!)

Future versions will follow this trend.  For example, we're probably
going to introduce a simple language to replace Generic Attribute
Providers, Generic Triggers, and such.  This actually will end up
eliminating stuff from ZPatterns and making it clearer, as there will be
less types of objects. It should also help the "I have to visit 4
different menus to set up one simple thing" problem. It will keep more
of the configuration together so you can see exactly what is going on.
I think it will be easier to explain and document as well.

 mind my limited understanding ;-) would be to concentrate on Containers,
 Container Groups and Plugins on the one front and Racks, Specialists and
 the various providers and agents on the other.

The PlugIns stuff is indeed separate, and is not really a part of
ZPatterns as much as it's stuff that we wrote to make ZPatterns and
other Zope products easier to write. You can pretty much ignore it if
you won't be writing python products or working in ZPatterns internals.

 PS: The main reason I'm writing this is because I think ZPatterns are
 very very cool but may well get ignored because no-one understands them
 and they're too buggy and complicated to get working :/

0.3.0 is pretty stable, I think. 0.4.0 alphas have been buggy. But they
*are* alphas, after all. You were warned :^)

From the unattributed mail you posted from someone else:
  P.S. ABout ZPatterns: everyone I spoke to was thought the basic idea
  behind  ZPattern was good and sound and nice and so on. But _everyone_
  complained about it being too pretentious (with all the computer science
  claims and theory behind it) 

What, you want something that's *not* based on any theory, just random
ideas? :^)

  and introducing too many unnecessary new
  concepts (racks, specialist and what have you). All this is very

Racks and Specialists are key concepts.  Saying that they're unecessary
and should be eliminated is like saying OO programming would be simpler
if they got rid of all the extra ideas like classes and objects.  Probably
so, but what would be left???

ZPatterns is new, and it can be confusing, and there is not enough good
documentation (or working examples -- I'm surpised this is one thing

Re: [Zope-dev] Racks and Specialists Simplified

2000-07-03 Thread Ty Sarna

Steve Alexander  [EMAIL PROTECTED] wrote:
 If it isn't there (hiding somewhere), perhaps I can add it from Shane's
 original email?

If it isn't there already, by all means, please add it!

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope] 2.2b3 and INSTANCE_HOME problem

2000-07-01 Thread Ty Sarna

In article 003901bfe321$e744b990$c7da5e3f@mozart,
Evan Simpson [EMAIL PROTECTED] wrote:
 It's a bug.  I've been tracking down and squishing a few in corners where
 INSTANCE_HOME wasn't properly taken into account, but I hadn't gotten to
 XMLDocument yet.  This should be fixed in CVS shortly (and the next release
 of Zope).

You may have already gotten to this, but ISTR that manage_readme on
products has this problems. You might also want to verify that the new
help system works with INSTANCE_HOME too (I forget).

Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope] Urgent problem: Database and large clock skew

2000-06-28 Thread Ty Sarna

In article 116492527.962189166@[],
Jim Flanagan  [EMAIL PROTECTED] wrote:
 In trying to fix a problem with Zope httpd server sockets getting wedged in 
 TIME_WAIT state, I set my system clock ahead by a year, then set it back. 

Can't help you with the database problem, but thought I'd point out that
changing the system real time clock won't help you to time out
connections.  Network statcks use monotonic clocks or timers that are
immune to "time warps". 

Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope] ZODB performance: reads to writes

2000-06-27 Thread Ty Sarna

In article 000d01bfddfb$4546f070$[EMAIL PROTECTED],
Evan Simpson [EMAIL PROTECTED] wrote:
 - Original Message -
 From: Jimmie Houchin [EMAIL PROTECTED]
  Will an app as described above still suffer from problems with high
 Possibly, but only if there are hidden hotspots.  For example, in your
 2. Implement the application-level conflict handling you read about, so that
 Folders and Catalogs can decide that two writes don't conflict after all,
 and merge them into a single update.

Unfortunately, this doesn't deal with cases where the conflicting state
is contained in many objects (see note by PJE in the ZODB Wiki).

Also, there is a whole other area of difficulty for high-write-volume
ZODBs, which is the ammount of IO that needs to be done.  First, by
nature ZODB can't rewrite a single attribute of an object, it has to
rewrite the entire thing.

Indexing is also a bear from an IO perspective.  First, BTrees currently
keep a count at each level, so every change to a btree changes a node at
each level of the BTree.  For a ZCatalog, there are a lot of btrees
(something like 2n+4 for n indexes, I think -- don't quote me on that,
it's been a while), and each one changes (last I looked, every index was
updated even if the value indexed in a particular one hadn't changed. 
This may have been improved since).  Not only is this bad from a hotspot
point of view (always a conflict on the root node of the tree), but you
end up doing a *lot* of IO.  During my experiments that led to
BerkeleyStorage, I was watching the Data.fs grow by 47K per transaction
for adding indexed objects of ~1K in size.  Watching this with
tranalyzer, this turns out to be 1K of object, and 46K of updated btree
pages :).  Note that BerkeleyStorage only prevents the file from growing
that much -- it still has to do all that IO (in fact, it has to do ~2-3
times that much IO, due to the nature of BerkeleyDB.  A relational
storage would have similar issues.  For ammount of IO done, FileStorage
is about as efficient as you can possibly be -- it's just that it trades
that off against space reclamation). 

Also, with any kind of Berkeley or Relational storage, there is a second
hidden IO and storage penalty: you're storing a btree inside a btree. In
other words, the lower-level DB uses btrees to store your objects,
including interior nodes of the higher-level ZODB btree. Every interior
node of the ZODB Btree needs a leaf node (and supporting interior nodes)
in the DB's btrees. so you get taxed twice, on both I/O and storage
space used.

Not to discourage anyone from using ZODB, necessarily.  There are a lot
of things it's fantastic for, and without a doubt ZODB is getting better
at handling higher write ratios. Over time there will be more and
more applications that previously would have required an external SQL or
other kind of database that can be done in ZODB instead.  However, there
will also IMHO always be applications that ZODB just isn't as suitable
for. You have to thing long and hard before committing to one or ther
other. And then there's the worry of what happens if you chose wrong.

We were faced with exactly these issues, and the extremes of them, to
boot.  We have a *large*, *very* high write ratio, lots of indexes type
of application based on ZPublisher/DTML that we'd like to port
to/replace with something Zope based.  Yet we might need to make another
instance of this same type of application used by only a few people with
a small ammount of data -- it would really suck to have to have to have
another instance of the same expensive database system to support a
miniscule ammount of data, because everything was coded only with SQL in

This is what led ultimately to ZPatterns -- you can write applications
and not have to decide up front on ZODB or SQL.  And you can change your
mind later (Seen that TV commercial? suddenly your online store is
selling a zillion items per month instead of the 1000 you planned for. 
oops!).  You can even decide on an instance by instance basis.  You
configure with ZODB for a small department or client, and Oracle or
Sybase for a huge one -- and the small guy doesn't have to pay for the
DB license and DBA!). Since then, we've discovered a number of other
benefits to the model.

Hmmm... I didn't intend to write a ZPatterns advertisement when I
started, honest! But this seems to have turned into one nonetheless :^)

Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Re: Problem importing Membership alpha

2000-06-14 Thread Ty Sarna

In article 001301bfd606$ad3a7320$7b5addc7@laptop,
Kevin Dangoor [EMAIL PROTECTED] wrote:
 I created it using the CVS version of Zope... I didn't *think* there was
 anything 2.2 specific going on, but apparently there is.
 I just took a look around. It appears that the current version of
 LoginManager uses the Owned module to import "UnownableOwner". I guess
 that's so it can create the default methods.
 It looks like the current LoginManager is 2.2 only then.

?? It does:

# Support Zope-2.2a1 onwership foo
from AccessControl.Owned import UnownableOwner
except ImportError:

Specifically to be compatible with both, and we're using it on 2.1.6!

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] is broken?

2000-06-06 Thread Ty Sarna

nw_moriarty   [EMAIL PROTECTED] wrote:
 There are many admonitions to use if you don't
 require versions in a database.  However, I have tried without success
 to get it to work with TCS.bsddb.db and BerkeleyDB 2.7.7 in a stand
 alone application. 
 How ANYBODY got it to work?  

Sorry for not replying earlier...

What sort of problems are you having? It would help if you could
describe in detail what problems you are seeing. 

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Proposed change in the authentication

2000-05-25 Thread Ty Sarna

Jim Fulton  [EMAIL PROTECTED] wrote:

 I propose to change the order which a vacation in URL traversal or

Good idea, we could all use a vacation :-)

 performed.  See and comment at:

To clarify, do you mean that authentication will be done at *every* user
folder found along the way, or at the first one found, or attempted at
each one until one succeeds, so long as anonymous still has permission
to continue walking down, or what? 

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Tranalyzer - the next step

2000-05-25 Thread Ty Sarna

Morten W. Petersen [EMAIL PROTECTED] wrote:
 I was wondering if there are any spinoffs of tranalyzer, that can parse
 all the objects in the database and alter the contents of them.

Modify them for what purpose?

It seems like it would be easier to just do whatever it is through Zope,
or through a Python program that talks directly to the Storage, perhaps.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )