Barry Warsaw wrote:
On Mon, 2004-04-26 at 15:23, Jim Fulton wrote:
2. Convert the mainline history, but leave off the branches.
Would this mean we'd lose the log messages too?
Yes, you'd lose the branch log messages.
If so -1 because often
merge messages aren't very helpful. merged foo-bar
Jim Fulton wrote:
Barry Warsaw wrote:
On Mon, 2004-04-26 at 15:23, Jim Fulton wrote:
2. Convert the mainline history, but leave off the branches.
Would this mean we'd lose the log messages too?
Yes, you'd lose the branch log messages.
If so -1 because often
merge messages aren't very
Barry Warsaw wrote:
On Mon, 2004-04-26 at 15:42, Jim Fulton wrote:
The reason that I hate merge messages like this is that I find it
very difficult to find the branch checkin messages in thye log. It's
possible, but so difficult that I generally would rather not
bother.
I agree, but history
Chris Withers wrote:
Jim Fulton wrote:
FYI, there's a similar zip file now containing the same kind of thing
for a
current Zope3 checkout (s/Zope2/Zope3/ in the URL).
If this is good enough for people trying to work from CVS on Windows,
let me
know and I'll update them from time to time
on irc.freenode.net #zope-dev...
I don't mind being the official announcer and hassler if people are
happy for me to have that role :-)
+1
Doesn't really need to be official though, does it?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714
.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Zope-Dev maillist - [EMAIL PROTECTED
in:
http://svnbook.red-bean.com/svnbook/ch07s04.html
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
I'd like to plan to convert the repository heads to subversion this Wednesday.
I'll confirm this on Tuesday. It will be best of no one does any work on
the head on Wednesday.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714
selectively.
Initially, we'll convert only parts needed for Zope 2, Zope 3 and ZODB.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
/trunk Zope3
for public checkouts.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Zope-Dev
Fred Drake wrote:
On Sunday 25 April 2004 12:29 pm, Jim Fulton wrote:
cvs co svn+ssh://svn.zope.org/repos/Zope3/trunk Zope3
That should be:
svn co svn+ssh://svn.zope.org/repos/Zope3/trunk Zope3
cvs co http://svn.zope.org/repos/Zope3/trunk Zope3
and this would be:
svn co http
Jim Fulton wrote:
Martijn Faassen wrote:
Hey there,
I understand from:
http://dev.zope.org/Wikis/DevSite/Projects/Zope2.8/MilestonePlan
Zope 2.8 is now planned for june.
This is, of course, a function of people's availability to help.
I still need to fix ZClasses, and I need to get through
that we have succeeded.
This exactly the sort of feedback we need.
Thanks.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Philipp von Weitershausen wrote:
Jim Fulton wrote:
Philipp von Weitershausen wrote:
Why would they switch to Zope 2.8 if not for the component architecture?
To stay current? To get MVCC? To get new-style extension classes, and
thus access to many modern Python features. Later releases
Philipp von Weitershausen wrote:
Jim Fulton wrote:
2. Especially Andreas expressed his worries about the current release
policy in Zope 2 and its future regarding maintainance and support. I
have to say that I share some of his skepticism regarding Zope 2. I
personally have never fully
on Zope 2 stopped?
No. ZC still puts more work into Zope 2 than into Zope 3.
I expect that to continue for some time.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http
approach is that, having built what we've
built, we'll be able to take advantage of that code in the current platform.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com
specific about your concerns?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Zope-Dev
are building production apps with it now,
even though there isn't a production release. That's why we're working
very hard to make a production-quality release of what we have now, even
though it doesn't do everything that it needs to do in the long term.
Jim
--
Jim Fulton mailto:[EMAIL
are a way for people to find out when somethings
coming.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
.
Since I am the one who asked Mike to speak up I would feel bad if it
created any bad feelings.
Bad feeling don't last long with me. I couldn't be an open-source
developer if they did. :/
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361
Martijn Faassen wrote:
Jim Fulton wrote:
I'm surprised to read this. Could you be more specific about your
concerns?
Did you read Andreas Jung's mail? He was pretty specific, but I had to
hunt around as in my mailreader his reply had broken the thread.
I was responding to Philipp, not Andreas
? As soon as we found out about them,
we mobilized the whole company to work on them. This was a big deal that we
put a lot of effort into over a fairly short time. How is this evidence that
we were a bottleneck?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO
would be responsible for
planning and executing the release, including bug-fix releases
for that base release. That team could establish the policy for
changes to that release, possibly including vetting fixes.
It would be great if someone would volunteer to update the process doc.
Jim
--
Jim
this after we do the svn conversion.
I *hope* to do that next week.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Chris Withers wrote:
Jim Fulton wrote:
Lennart Regebro wrote:
From: Jim Fulton [EMAIL PROTECTED]
Initially, I propose to move just the repository heads. Maintenamce
branches (e.g. Zope 2.6 and Zope 2.7) will remain in CVS.
What is the rationale behind not moving it all?
- Reduce risk
Jim Fulton wrote:
Based on recent discussions, I've created a proposal:
http://dev.zope.org/Zope3/RenameTheZopePackage
to rename the zope package to z. Unless there are strong
objections, we'll do this after we move the Zope repository head to
subversion at the end of the month.
I've gotten
to the proposal that the scope includes the sort of
scenario you described.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
to Zope 2 and other ZODB
applications.
Comments are welcome.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Based on recent discussions, I've created a proposal:
http://dev.zope.org/Zope3/RenameTheZopePackage
to rename the zope package to z. Unless there are strong
objections, we'll do this after we move the Zope repository head to
subversion at the end of the month.
Jim
--
Jim Fulton
into packages, so that
'zope' doesn't get excessively broad.
I think the depth vs breadth balence we have now is about right.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http
Sidnei da Silva wrote:
On Thu, Apr 15, 2004 at 08:59:44AM -0400, Jim Fulton wrote:
| So, what about this:
|
| zope.component
| zope.interfaces (?)
| zope.configuration
| zope.testing
| zope.schema (soon-to-be-dead?)
|
| - All move to 'ca.*'
|
| Most of this has nothing to do with the component
the component architecture is called z
No, the component architecture is z.component.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Barry Warsaw wrote:
On Thu, 2004-04-15 at 09:25, Jim Fulton wrote:
From the zope package README.txt:
Zope Project Packages
The zope package is a pure namespace package holding packages developed as
part of the Zope 3 project.
Generally, the immediate subpackages of the zope package
Jim Fulton wrote:
Zope 2 has a package named Zope. Zope 3 has a package named zope.
Starting with Zope 2.8, parts of Zope 3 will be included in Zope 2.
As things stand, this will require having both Zope and zope packages.
Python can handle this fine, however, it will require putting the packages
Kapil Thangavelu wrote:
On Wed, 2004-04-14 at 09:00, Jim Fulton wrote:
The first question is:
Is it a problem to have two packages with names differing only in case?
snip
Perhaps we can get more input on whether there's a problem.
A response with a positive sign (e.g. +1, +0, +2
Philipp von Weitershausen wrote:
Jim Fulton wrote:
The first question is:
Is it a problem to have two packages with names differing only in case?
I don't see a problem at all; IIRC, we agreed that the backports from
Zope3 would live in a 'src' directory, while Zope 2 stuff continues to
live
Jim Fulton wrote:
Jim Fulton wrote:
...
I should have been clearer.
The first question is:
Is it a problem to have two packages with names differing only in case?
I haven't gotten as many responses on this as I expected. I'll try to
summarize
Wrong. People don't find the question useful
Jim Fulton wrote:
...
Give the responses. I need to recast my question as a selection
among alternatives. But, before I do that, we will need to consider
alternatives a bit more.
OK, here's another.
What about renaming the Zope 3 zope package to z.
- It fits with the expansion of Zope:
Z
with Zope 3.
I would hate to have imports like z3.app.foo or even z3.i18n.
Why?
What about z.app.foo or z.i18n?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com
embarrassing) to document, should the two codebases merge in some unholy
fashion at some point as is on the 2.9 roadmap.
Actually, the Zope 2.8 roadmap. :) Zope 2.8 will have Zope 3 interfaces.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361
Stephan Richter wrote:
On Wednesday 14 April 2004 11:08, Jim Fulton wrote:
...
What about z.app.foo or z.i18n?
The shortness of this example is very attractive, but it is still a compromise
in my opinion.
Again, I think educating is easier than anything else. People understand
Marius Gedminas wrote:
On Wed, Apr 14, 2004 at 11:06:37AM -0400, Jim Fulton wrote:
What about renaming the Zope 3 zope package to z.
Examples (from the buddydemo example):
import z.interface
from z.app import zapi
from z.app.event import publish
from z.app.event.objectevent import
Jim Fulton wrote:
Jim Fulton wrote:
...
Give the responses. I need to recast my question as a selection
among alternatives. But, before I do that, we will need to consider
alternatives a bit more.
OK, here's another.
What about renaming the Zope 3 zope package to z.
- It fits
differing only in case is a
bit ugly.
Do we want to consider renaming one or both of these packages
to avoid the conflict?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http
Jamie Heilman wrote:
Jim Fulton wrote:
I propose to move from CVS to subversion for the Zope and ZODB projects;
http://dev.zope.org/Zope3/MovingSCMToSubversion
No complaints from me. I do wonder though... one thing I've noticed
about ZC's CVS usage in the past is that you folks never export
propose to make this
a topic of discussion at the upcoming Zope commnity IRC chat:
http://mail.zope.org/pipermail/zope-announce/2004-April/001409.html
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
it with the Object scema field type. :)
Should I be contributing code directly to Zope X3's
interface instead of subclassing it?
Absolutely!
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation
This would be a good time for people interested and knowledgeable
about packaging systems and who want to influence the direction we
take with Zope 3 to get involved. :)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http
Dieter Maurer wrote:
Jim Fulton wrote at 2004-1-15 17:23 -0500:
...
None should never be passed for attribute accesses. If it is,
then there is a bug. The case of dictionary mapping names to
whatever is for attribute access. We are talking about item/key
access. I haven't seen a use case
Jim Fulton wrote:
Stuart Bishop wrote:
...
It was never intended that the ability to control unprotected sub-objects
by name would apply to items. It was sloppy coding on my part that item
indexes
(yes, indexes, like, say, 1) and keys were passed as names. I can
certainly
understand why
Dieter Maurer wrote:
Jim Fulton wrote at 2004-1-15 17:23 -0500:
BTW, telling me that an algorithm has changed doesn't constitute
a use case. :) I know that algorithm has changed. I assert that
we don't need the feature that the change broke. I am open
to evidence to the contrary.
Do you have
reasonable use case
for heterogenous access.
Right. The name attribute was intended for attribute-based access.
IMO, it makes no sense to consider key values when doing security
checks.
I will let Jim comment on your use case.
What use case? I missed it. Where is it?
Jim
--
Jim Fulton
Tres Seaver wrote:
Jim Fulton wrote:
Tres Seaver wrote:
I will let Jim comment on your use case.
What use case? I missed it. Where is it?
Here is Stuart's original post:
This has the side effect of not passing the name attribute to
my security assertion methods registered via
Dieter Maurer wrote:
Jim Fulton wrote at 2004-1-15 10:03 -0500:
...
Right. The name attribute was intended for attribute-based access.
IMO, it makes no sense to consider key values when doing security
checks.
I will let Jim comment on your use case.
What use case? I missed it. Where
in Zope 2
and Zope 3, most notably zope and Zope, with names differing only in
case.
I will also replace the existing Interfaces package with a facade package
that uses zope.interfaces.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714
.
I also had to check in a %$#@ travesty because Data.fs.in still has
references to BoboPOS.
With these changes, I can create a database with 2.6 and open it with the
head.
Thanks Chris for helping us figure out that this was easier than we
thought. :)
Jim
--
Jim Fulton mailto:[EMAIL
? I'd just
never thought of using __of__ or inheritedAttribute or any of the other
EC-specific stuff on a PersistentMapping.
shrug Who knows. I'd rather be safe. It's not that hard.
In any case, we would have needed the fix to handle old pickles
correctly.
Jim
--
Jim Fulton mailto:[EMAIL
PersistentMapping
is ExtensionClass is installed.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
. The hard part is walking the object tree. You will need a function that,
|given an object, will return the oids of the objects it references.
|Perhaps Jeremy can help you with that.
I hope so *wink*.
Me too. He's pretty busy. If he can't, I'll try to help.
Jim
--
Jim Fulton
if that
decision stuck or if the script was ever written.
Jeremy
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
the conversion has been run, the database should be usable with
the head.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Steve Alexander and I will be hosting a sprint in Fredericksburg
January 12-14, 2004:
http://dev.zope.org/Zope3/SteveVisitingFredericksburgSprint
A possible topic is Zope 2 to Zope 3 transition and working on
Zope 2.9.
Please let me know if you are interested in participating.
Jim
--
Jim
Yuppie wrote:
Jim Fulton wrote:
Done!
Hi Jim!
Here some feedback regarding your checkin.
Thanks!
I tested CMF with Zope HEAD.
These are the issues I ran into:
1.) from ZODB import Persistent, PersistentMapping doesn't work anymore
Maybe Zope 2.7 should have a deprecation warning?
Hm
compatability. The algorithm is described in detail
in the docstring for the test_mro test in
lib/python/ExtensionClass/tests.py.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http
Jim Fulton wrote:
Zope 2.8 will not include the old BTree or intSet objects. I plan to
arrange for this not to be a problem for old databases. Somehow, Zope 2.8
will convert these automatically. I haven't done this yet though.
I'd like to merge the new-style ExtensionClass and ZODB 3.3 work soon
to come up with a mechanism for converting
ancient BTrees and intSets. Unfortunately, until a change I checked into
the Zope 2.7 branch on Wednesday, Zope was continuing to use the old
depricated BTrees for a key data structure.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered
Chris McDonough wrote:
On Fri, 2003-11-28 at 09:59, Jim Fulton wrote:
Hi,
I'm just about to start writing the checkin logs for the merge of new-style
ExtensionClass and ZODB 3.3 into the Zope 3 head. I expect the merge to be done
within the next hour or two.
You mean the Zope 2 HEAD, correct
Jim Fulton wrote:
Hi,
I'm just about to start writing the checkin logs for the merge of new-style
ExtensionClass and ZODB 3.3 into the Zope 2 head. I expect the merge to
be done within the next hour or two.
Done!
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO
ZODB based objects like Image and
I imagine making similar small changes to Archetypes won't be hard.
Tres.
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com
not to wait for the old-style BTree and intSet compatability
work.
This would mean that old databases would not be useable with the CVS head
in the near term. Would this cause anyone any problems?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361
Dieter Maurer wrote:
Jim Fulton wrote at 2003-11-22 12:14 -0500:
...
Also note that I had to get rid of the validateValue call. It's important
that we always pass the name and container to code that needs to get roles.
We need name and container only for objects that do not have
their own
place where this
special computation needs to be done.
Also note that I had to get rid of the validateValue call. It's important
that we always pass the name and container to code that needs to get roles.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO
Jim Fulton wrote:
...
Currently, on the zodb33-devel-branch, Zope 2 runs and the great
majority of it's tests pass with NSEC and ZODB 3.3. It you'd like to
see this in action, feel free to check Zope out on the branch and
play with it.
Jeremy pointed out that this wasn't true. I had forgotten
Dieter Maurer wrote:
Jim Fulton wrote at 2003-11-13 15:22 -0500:
...
We need to refactor the way security assertions (permission
settings) are stored and accessed. We need to store required
permissions (__permissions__) on objects. When we need to figure
out roles, we need
time will be spent writing
tests. I really need to focus on Zope 3 for a while, so I may not
be able to get back to this soon. I think that this is an area
where some volunteers could make a big difference. I'd be happy to
work with some folks on this.
Jim
--
Jim Fulton mailto:[EMAIL
and ZODB 3.3 provide more than enough of a change for
one release. :)
This is something I would really love to see in zope2.
Me too. We need to get 2.7 and 2.8 out the door as soon as we
can so we can get working on 2.9.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO
ought to use the new algorithm (option 2)?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
and has clearer
code. It also uses new-style classes and, thus, uses the new algorithm.
I personally don't like the new algorithm, but I don't really care
in the long run. One should avoid inheritence complex enough to show
a difference.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED
Jim Fulton wrote:
...
An initial analysis showed that for more than half of the classes in
Zope 2, it was impossible to compute a method-resolution order using
the new algorithm. After about a day of analysis (and development of
a tool to aid in the analysis) I've been able to adjust the Zope
)
their products to be ExtensionClass-less and Zope3-ish. If they
make their products Zope 3-ish, the lookup algorithm won't matter much.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http
Sidnei da Silva wrote:
On Fri, Oct 31, 2003 at 12:14:27PM -0500, Jim Fulton wrote:
| Thoughts?
|
| I am worried enough about breaking products that I'm inclined to go
| with option 3.
|
| Does anybody think we ought to use the new algorithm (option 2)?
I'm for option 2. Given that a huge amount
Sidnei da Silva wrote:
On Fri, Oct 31, 2003 at 02:39:28PM -0500, Jim Fulton wrote:
| I've checked the results of my work into the mro-advanture-branch (waa,
| I wish I cud spell) branch.
|
| You might find it entertaining to check out Zope on this branch:
|
| cvs co -rmro-advanture-branch Zope
Martijn Faassen wrote:
Hey,
Belated response, but..
Jim Fulton wrote:
Speaking of Zope 2.8, Jeremy Hylton has suggested that, perhaps, Zope 2.8
should be a release that provides *only*:
- New-style ExtensionClass, and
- ZODB 3.3, featuring multi-version concurrency control,
plus any features
Martijn Faassen wrote:
Jim Fulton wrote:
See:
Packages3/Interface in CVS
If you put this ahead of the Zope 2 Interface package in
your Python path, then you can use Zope 3 interfaces with Zope 2.
That's great news!
Is it the intention that this will be the default Interface package
in Zope
...
Yes. :)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Zope-Dev maillist - [EMAIL
3.3, featuring multi-version concurrency control,
plus any features that have been added to the head since the Zope 2.7
branch was created.
This idea is pretty appealing to me. I wonder what others think of it.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO
be given a local role that lets them join/leave versions.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (703) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
and make it a separate distribution.
Would anyone object to these changes for Zope 2.7?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (888) 344-4332http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
.
I'd love to have more events like this in the future.
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (888) 344-4332http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
---BeginMessage---
PyCon DC 2003
or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (888) 344-4332http://www.python.org
Zope
Casey Duncan wrote:
On Thursday 15 August 2002 09:21 am, Jim Fulton wrote:
...
I'm not sure what you mean. The pipelining is defined and executed in the
lexicon.
My mistake.
I think that there is at least potential value in sharing lexicons.
Of course, a down side
Romain Slootmaekers wrote:
Jim Fulton wrote:
Romain Slootmaekers wrote:
...
the object in question is created once, and there is no code to delete
it since in that application, it is of no use.
The only thing that happens is that we add/moify/delete other object to
that rootnode
backup and the
server is back up and running. (breathing relieved)
What worries me is that we have no clue whatsoever on what happened,
besides the constatation that somehow, somewhere we lost a whole tree of
objects.
Was this in the backup? Or in the damaged data file?
Jim
--
Jim Fulton
will come out at around the same time as 2.6. See
http://dev.zope.org/Wikis/DevSite/Projects/SupportPython22/VisionStatement.
WRT to this change, now that I'm back from vacation, I want to talk to Brian
about it. ;)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO
Romain Slootmaekers wrote:
Jim Fulton wrote:
Romain Slootmaekers wrote:
Yo,
we had a nasty crash of our zope server that we use for a b2b web
application. The Data.fs ZODB lost a significant amount of data.
What sort of crash? Was this a hardware failure, or a software failure
maillist - [EMAIL PROTECTED]
| http://lists.zope.org/mailman/listinfo/zope-cmf
|
| See http://www.zope.org/Products/PTK/Tracker for bug reports and feature
| requests
--
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (888) 344-4332
ZPT implementation is too slow
(thanks to recent DTML speedups ;).
ZPT needs to be as fast as or faster than DTML. It would be
great if it was cleaner and more pluggable.
Jim
--
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (888) 344-4332
Sidnei da Silva wrote:
On Seg 01 Jul 2002 15:26, Jim Fulton wrote:
| I'll add that the current ZPT implementation is too slow
| (thanks to recent DTML speedups ;).
|
| ZPT needs to be as fast as or faster than DTML. It would be
| great if it was cleaner and more pluggable.
|
| Jim
I
in an object that are not meaningful
to the application.
I think that a much better approach, if modification time is important
to your application, is to store the application modification time in the
object as a data attribute.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered
901 - 1000 of 1043 matches
Mail list logo
