Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Jan-Ole Esleben
It's not about the threads or processes being tied up and waiting,
it's about the transaction breaking: because the internal call (the
one from the second server back to the first) changes the object on
the first server, and thus when the first server checks wether the
object has changed after the transaction should close (during the last
return), it finds that indeed it has, and before it could write to it,
so it raises a conflict error invariably.

Ole


2005/12/17, Chris McDonough <[EMAIL PROTECTED]>:
> > The problem setup is this; I explained it above, but it this has
> > become a long thread:
> >
> > I write a ZOPE product. I want to make use of other software on the
> > internet and the services that software provides. So I use the methods
> > exposed by that software via SOAP, XML-RPC, whatever.
> >
> > One of those methods actually calls my product back, maybe because the
> > developer has learned that my product itself exposes some (or all) of
> > its functionality via XML-RPC. If this is all inside one call, which I
> > can't avoid explicitly as the developer of just my product, I have a
> > broken transaction on my hands that isn't easy to fix (and maybe
> > impossible). This holds true for the whole product, even if the method
> > called by the second server changed some completely unrelated data.
>
> I see what you're saying, but how is this specific to Zope?  If you
> write a Perl program and expose it via mod_perl on Apache, and the
> program calls out to a service that calls back in to the mod_perl
> program (no matter how broken of a pattern this was), wouldn't the
> Apache process that was waiting on data be tied up in the same way?
>
> - C
>
>
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Chris McDonough

The problem setup is this; I explained it above, but it this has
become a long thread:

I write a ZOPE product. I want to make use of other software on the
internet and the services that software provides. So I use the methods
exposed by that software via SOAP, XML-RPC, whatever.

One of those methods actually calls my product back, maybe because the
developer has learned that my product itself exposes some (or all) of
its functionality via XML-RPC. If this is all inside one call, which I
can't avoid explicitly as the developer of just my product, I have a
broken transaction on my hands that isn't easy to fix (and maybe
impossible). This holds true for the whole product, even if the method
called by the second server changed some completely unrelated data.


I see what you're saying, but how is this specific to Zope?  If you  
write a Perl program and expose it via mod_perl on Apache, and the  
program calls out to a service that calls back in to the mod_perl  
program (no matter how broken of a pattern this was), wouldn't the  
Apache process that was waiting on data be tied up in the same way?


- C

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Jan-Ole Esleben
> >> I don't understand the problem.  How is using XML-RPC incompatible
> >> with persistence?  What are you trying to exclude?
> > I'm sorry, but I don't understand _that_ question. What am I trying to
> > _exclude_?
> You said:
> """ it would most certainly be extremely hard to foresee the exact
> setup of such situations and impossible to exclude them """

That's probably an idiomatic error on my part, sorry. I meant "avoid"
(in German, it's the same word).

> AFAICT, people have told you to not use XML-RPC here and when you
> said it was not possible to avoid the use of XML-RPC, they provided
> suggestion about how to accomplish what you wanted anyway.  So I'm
> not sure what the exact problem is.

The problem is a different one now, and I was referring to the
_reasons_ people had for telling me not to use XML-RPC. Part of the
problem I have now is that no application on the web is isolated from
others, and that ZOPE specifically _comes_ with XML-RPC capabilities
on the server's part.

> > My point is: this doesn't happen _within_ single "programs", but
> > everywhere there is even the slightest bit of communication there is a
> > chance of it happening.
> The chance of what happening, sorry?  I'm still trying to understand
> the problem.  The only problem that was noted so far was a deadlock
> potential by Dieter which presumed you were doing XML-RPC requests to
> the same system which accepts them.  This is an unusual thing to do;
> it wouldn't happen under "normal" circumstances.

The problem setup is this; I explained it above, but it this has
become a long thread:

I write a ZOPE product. I want to make use of other software on the
internet and the services that software provides. So I use the methods
exposed by that software via SOAP, XML-RPC, whatever.

One of those methods actually calls my product back, maybe because the
developer has learned that my product itself exposes some (or all) of
its functionality via XML-RPC. If this is all inside one call, which I
can't avoid explicitly as the developer of just my product, I have a
broken transaction on my hands that isn't easy to fix (and maybe
impossible). This holds true for the whole product, even if the method
called by the second server changed some completely unrelated data.

I hope that clears it up a little.

Ole
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] hosting two site on one zope server

2005-12-16 Thread Tino Wildenhain
Am Freitag, den 16.12.2005, 17:28 -0800 schrieb Allen Huang:
> I'm trying to host two site on one zope server
>  
> I have two fix IP and I have two network card installed. 
> I changed my zope.conf to include two http server that listen on two
> different ports.
> But, I placed my site under different folder and I don't know how to
> redirect different IP to different folder sites by listening on the
> same port 80 (can change 8080 t0 80 on linux, don't know what server
> is already using this)

If you going to provide some server services you should definitively
read a bit on that matter. Its not all that plug & play there.
Its not so hard either but still you can do harm to you and to others
with misconfigured servers connected to the internet.

In your specific case, you find out which daemon binds which port by
running:

netstat -lntp

as root will show you the process-ids and names of the programs.

I suspect it will be apache and you should better use it
in front of zope for all the complex rewriting you seem
to want. Look up documentation on VirtualHostMonster
to see how this (zero-config on zope) works.

Btw, if its just about hosting 2 IPs, you dont need 2 
network cards. You can assign any number of addresses
to a single card.

HTH
Tino Wildenhain


___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


[Zope] hosting two site on one zope server

2005-12-16 Thread Allen Huang
I'm trying to host two site on one zope server     I have two fix IP and I have two network card installed.   I changed my zope.conf to include two http server that listen on two different ports.  But, I placed my site under different folder and I don't know how to redirect different IP to different folder sites by listening on the same port 80 (can change 8080 t0 80 on linux, don't know what server is already using this)     can someone help me?__Do You Yahoo!?Tired of spam?  Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Chris McDonough


On Dec 16, 2005, at 8:02 PM, Jan-Ole Esleben wrote:


I don't understand the problem.  How is using XML-RPC incompatible
with persistence?  What are you trying to exclude?


I'm sorry, but I don't understand _that_ question. What am I trying to
_exclude_?


You said:

""" it would most certainly be extremely hard to foresee the exact  
setup of such situations and impossible to exclude them """



XML-RPC and (the concept of) persistence aren't incompatible. XML-RPC
(on a ZOPE server) and ZOPE persistence are, to the extent described
by others in this thread, not by me. I just described a couple more
cases (and specifically one case) where it is bad that things are this
way (and cannot be solved by better design).


AFAICT, people have told you to not use XML-RPC here and when you  
said it was not possible to avoid the use of XML-RPC, they provided  
suggestion about how to accomplish what you wanted anyway.  So I'm  
not sure what the exact problem is.



My point is: this doesn't happen _within_ single "programs", but
everywhere there is even the slightest bit of communication there is a
chance of it happening.


The chance of what happening, sorry?  I'm still trying to understand  
the problem.  The only problem that was noted so far was a deadlock  
potential by Dieter which presumed you were doing XML-RPC requests to  
the same system which accepts them.  This is an unusual thing to do;  
it wouldn't happen under "normal" circumstances.


- C

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Jan-Ole Esleben
> I don't understand the problem.  How is using XML-RPC incompatible
> with persistence?  What are you trying to exclude?

I'm sorry, but I don't understand _that_ question. What am I trying to
_exclude_?

XML-RPC and (the concept of) persistence aren't incompatible. XML-RPC
(on a ZOPE server) and ZOPE persistence are, to the extent described
by others in this thread, not by me. I just described a couple more
cases (and specifically one case) where it is bad that things are this
way (and cannot be solved by better design).

My point is: this doesn't happen _within_ single "programs", but
everywhere there is even the slightest bit of communication there is a
chance of it happening.

Ole



>
> - C
>
>
> On Dec 16, 2005, at 6:40 AM, Jan-Ole Esleben wrote:
>
> > Thanks; this is a problem we are well aware of. Our solution is to
> > increase the amount of workers, obviously.
> >
> > However, I'm increasingly getting a feeling that for a rather big
> > range of unlikely situations that are nonetheless to be expected, Zope
> > doesn't work _at all_. In a WebServices setting, situations like the
> > one I described, with one server calling back to another server within
> > a call from that latter server and both not knowing anything about the
> > implementation of the other, it would most certainly be extremely hard
> > to foresee the exact setup of such situations and impossible to
> > exclude them for persistent objects that actually _do_ change state
> > (unlike mine). The solution is to not have state in your objects, and
> > thus lose instantly most of what Zope is.
> >
> > However, as I see it, the problem is that what Zope actually _is_
> > (i.e. mostly the ZODB) is an unhealthy way of coupling data and
> > implementation (which is _exactly_ why my implementation didn't work
> > immediately). This of course comes from its origins in TTW development
> > where there wouldn't actually have been many user made products.
> >
> > Please tell me if I'm wrong with my assumption above, and why. I'm not
> > trying to be inflamatory, this just has me really worried.
> >
> > Ole
> >
> >
> > 2005/12/15, Dieter Maurer <[EMAIL PROTECTED]>:
> >> Jan-Ole Esleben wrote at 2005-12-11 19:10 +0100:
> >>> Is it at all impossible to use XML-RPC _within_ a ZOPE architecture?
> >>
> >> In principle yes.
> >>
> >> Be careful however: it is easy to introduce deadlocks!
> >>
> >>   When during request processing you call back into the same
> >>   Zope via XML-RPC, the calling out request will not complete
> >>   until the XML-RPC returns a result (this always holds for
> >>   calls, XML-RPC or other, to an external or internal server).
> >>
> >>   Zope has a limited amount of workers (the default is 4) able
> >>   to execute requests. If there are no free workers, requests
> >>   have to wait for one.
> >>
> >>   Now imagine that as many requests arrive as there are workers
> >>   and each of them wants to perform an XML-RPC against the
> >>   same Zope. Then you have a deadlock: none of the XML-RPC requests
> >>   will finish, because there are no free workers. An no worker
> >>   will ever become free again, because each of them waits for
> >>   its XML-RPC to finish.
> >>
> >> Therefore, you should directly call internal resources (rather
> >> than use XML-RPC).
> >>
> >>
> >> --
> >> Dieter
> >>
> > ___
> > Zope maillist  -  Zope@zope.org
> > http://mail.zope.org/mailman/listinfo/zope
> > **   No cross posts or HTML encoding!  **
> > (Related lists -
> >  http://mail.zope.org/mailman/listinfo/zope-announce
> >  http://mail.zope.org/mailman/listinfo/zope-dev )
> >
>
>
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] batching help

2005-12-16 Thread Martijn Pieters
On 12/15/05, Nicolas Georgakopoulos <[EMAIL PROTECTED]> wrote:
> Hello all , I'm trying to display on the same page a table with (3
> columns) with content from a list . I'm trying to batch the results so
> that every 3 elements anothe row is created.
> Can anyone give me a clue how to do that ?

Use batches and the following recipe:

http://zopelabs.com/cookbook/998066576


--
Martijn Pieters
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] using tal macros in PloneArticle query

2005-12-16 Thread J Cameron Cooper

Stefan Kueppers wrote:

I am trying to use tal and metal inside of a PloneArticle instance and 
can not get it to work.

Should this not be possible?


Content is generally static, as part of the whole 
content/logic/presentation concept. I don't know about PloneArticle, but 
I doubt it's any different: the contents are not parsed by anything but 
delivered exactly as is.


If you want behavior, you need a page template. Though there is at least 
one product that provides a type that breaks the rules. DynamicContent 
or something like that.


--jcc
--
"Building Websites with Plone"
http://plonebook.packtpub.com
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Chris McDonough
I don't understand the problem.  How is using XML-RPC incompatible  
with persistence?  What are you trying to exclude?


- C


On Dec 16, 2005, at 6:40 AM, Jan-Ole Esleben wrote:


Thanks; this is a problem we are well aware of. Our solution is to
increase the amount of workers, obviously.

However, I'm increasingly getting a feeling that for a rather big
range of unlikely situations that are nonetheless to be expected, Zope
doesn't work _at all_. In a WebServices setting, situations like the
one I described, with one server calling back to another server within
a call from that latter server and both not knowing anything about the
implementation of the other, it would most certainly be extremely hard
to foresee the exact setup of such situations and impossible to
exclude them for persistent objects that actually _do_ change state
(unlike mine). The solution is to not have state in your objects, and
thus lose instantly most of what Zope is.

However, as I see it, the problem is that what Zope actually _is_
(i.e. mostly the ZODB) is an unhealthy way of coupling data and
implementation (which is _exactly_ why my implementation didn't work
immediately). This of course comes from its origins in TTW development
where there wouldn't actually have been many user made products.

Please tell me if I'm wrong with my assumption above, and why. I'm not
trying to be inflamatory, this just has me really worried.

Ole


2005/12/15, Dieter Maurer <[EMAIL PROTECTED]>:

Jan-Ole Esleben wrote at 2005-12-11 19:10 +0100:

Is it at all impossible to use XML-RPC _within_ a ZOPE architecture?


In principle yes.

Be careful however: it is easy to introduce deadlocks!

  When during request processing you call back into the same
  Zope via XML-RPC, the calling out request will not complete
  until the XML-RPC returns a result (this always holds for
  calls, XML-RPC or other, to an external or internal server).

  Zope has a limited amount of workers (the default is 4) able
  to execute requests. If there are no free workers, requests
  have to wait for one.

  Now imagine that as many requests arrive as there are workers
  and each of them wants to perform an XML-RPC against the
  same Zope. Then you have a deadlock: none of the XML-RPC requests
  will finish, because there are no free workers. An no worker
  will ever become free again, because each of them waits for
  its XML-RPC to finish.

Therefore, you should directly call internal resources (rather
than use XML-RPC).


--
Dieter


___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )



___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )


[Zope] using tal macros in PloneArticle query

2005-12-16 Thread Stefan Kueppers

Hi all,

I am trying to use tal and metal inside of a PloneArticle instance and 
can not get it to work.

Should this not be possible?

I am aware that kupu needs to be switched to not strip customg tags on 
edit and that there are settings which enable or disble content types in 
the article instance.


I did enable the text/python-source type in the PloneArticle settings, 
but this still seems to not work.


Anyone knows what I might be doing wrong?

Many Thanks!!
Stefan


Bartlett Web Systems
www.bartlett.ucl.ac.uk
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Jan-Ole Esleben
Thanks, I will definitely look into that for my immediate problems.

Ole

2005/12/16, Michael Haubenwallner <[EMAIL PROTECTED]>:
> Jan-Ole Esleben wrote:
>
> > Thanks; this is a problem we are well aware of. Our solution is to
> > increase the amount of workers, obviously.
> >
> > However, I'm increasingly getting a feeling that for a rather big
> > range of unlikely situations that are nonetheless to be expected, Zope
> > doesn't work _at all_. In a WebServices setting, situations like the
> > one I described, with one server calling back to another server within
> > a call from that latter server and both not knowing anything about the
> > implementation of the other, it would most certainly be extremely hard
> > to foresee the exact setup of such situations and impossible to
> > exclude them for persistent objects that actually _do_ change state
> > (unlike mine). The solution is to not have state in your objects, and
> > thus lose instantly most of what Zope is.
> >
> > However, as I see it, the problem is that what Zope actually _is_
> > (i.e. mostly the ZODB) is an unhealthy way of coupling data and
> > implementation (which is _exactly_ why my implementation didn't work
> > immediately). This of course comes from its origins in TTW development
> > where there wouldn't actually have been many user made products.
> >
> > Please tell me if I'm wrong with my assumption above, and why. I'm not
> > trying to be inflamatory, this just has me really worried.
> >
> > Ole
> >
>
> You could try XMLRPCMethod.
> It creates its own worker thread and has a configurable timeout.
>
> Michael
>
> [1] http://www.zope.org/Members/EIONET/XMLRPC
>
> --
> http://zope.org/Members/d2m
> http://planetzope.org
>
> ___
> Zope maillist  -  Zope@zope.org
> http://mail.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope-dev )
>
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


[Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Michael Haubenwallner

Jan-Ole Esleben wrote:


Thanks; this is a problem we are well aware of. Our solution is to
increase the amount of workers, obviously.

However, I'm increasingly getting a feeling that for a rather big
range of unlikely situations that are nonetheless to be expected, Zope
doesn't work _at all_. In a WebServices setting, situations like the
one I described, with one server calling back to another server within
a call from that latter server and both not knowing anything about the
implementation of the other, it would most certainly be extremely hard
to foresee the exact setup of such situations and impossible to
exclude them for persistent objects that actually _do_ change state
(unlike mine). The solution is to not have state in your objects, and
thus lose instantly most of what Zope is.

However, as I see it, the problem is that what Zope actually _is_
(i.e. mostly the ZODB) is an unhealthy way of coupling data and
implementation (which is _exactly_ why my implementation didn't work
immediately). This of course comes from its origins in TTW development
where there wouldn't actually have been many user made products.

Please tell me if I'm wrong with my assumption above, and why. I'm not
trying to be inflamatory, this just has me really worried.

Ole



You could try XMLRPCMethod.
It creates its own worker thread and has a configurable timeout.

Michael

[1] http://www.zope.org/Members/EIONET/XMLRPC

--
http://zope.org/Members/d2m
http://planetzope.org

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )


[Zope] Zope Persistence (was: XML-RPC within ZOPE)

2005-12-16 Thread Jan-Ole Esleben
Thanks; this is a problem we are well aware of. Our solution is to
increase the amount of workers, obviously.

However, I'm increasingly getting a feeling that for a rather big
range of unlikely situations that are nonetheless to be expected, Zope
doesn't work _at all_. In a WebServices setting, situations like the
one I described, with one server calling back to another server within
a call from that latter server and both not knowing anything about the
implementation of the other, it would most certainly be extremely hard
to foresee the exact setup of such situations and impossible to
exclude them for persistent objects that actually _do_ change state
(unlike mine). The solution is to not have state in your objects, and
thus lose instantly most of what Zope is.

However, as I see it, the problem is that what Zope actually _is_
(i.e. mostly the ZODB) is an unhealthy way of coupling data and
implementation (which is _exactly_ why my implementation didn't work
immediately). This of course comes from its origins in TTW development
where there wouldn't actually have been many user made products.

Please tell me if I'm wrong with my assumption above, and why. I'm not
trying to be inflamatory, this just has me really worried.

Ole


2005/12/15, Dieter Maurer <[EMAIL PROTECTED]>:
> Jan-Ole Esleben wrote at 2005-12-11 19:10 +0100:
> >Is it at all impossible to use XML-RPC _within_ a ZOPE architecture?
>
> In principle yes.
>
> Be careful however: it is easy to introduce deadlocks!
>
>   When during request processing you call back into the same
>   Zope via XML-RPC, the calling out request will not complete
>   until the XML-RPC returns a result (this always holds for
>   calls, XML-RPC or other, to an external or internal server).
>
>   Zope has a limited amount of workers (the default is 4) able
>   to execute requests. If there are no free workers, requests
>   have to wait for one.
>
>   Now imagine that as many requests arrive as there are workers
>   and each of them wants to perform an XML-RPC against the
>   same Zope. Then you have a deadlock: none of the XML-RPC requests
>   will finish, because there are no free workers. An no worker
>   will ever become free again, because each of them waits for
>   its XML-RPC to finish.
>
> Therefore, you should directly call internal resources (rather
> than use XML-RPC).
>
>
> --
> Dieter
>
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] à l'aide

2005-12-16 Thread Rakotomandimby Mihamina
On Thu, 2005-12-15 at 20:31 +0100, Tino Wildenhain wrote:
> Even on debian its recommended to install zope from source.

Debian/Ubuntu zope packages have interesting zope instances handlers.
It would be nice you try them out and see it is worth to use in some
case.

-- 
A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL).
Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better.
http://www.cps-project.org for downloads & documentation.
Free hosting of CPS groupware: http://www.objectis.org.

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] à l'aide

2005-12-16 Thread bruno desthuilliers
adeline nombre wrote:
> bonjour
> je suis un débutant. je veux installer zope sur la debian. mais j'ai
> remarqué un repertoire /usr/lib/zope. j'ai donc conclu que zope a été
> installé avec mon system debian. maintenant comment faire pour démarer
> zope. dois-je faire un start et où?
> merci

Hi.

First, please dont post in french here, this is an english-speaking list.

Havin zope libs installed is mandatory, but not enough - you now need to
create a zope instance (the actual server).

/usr/lib/zope holds zope's libs, as well as some utilities in the bin
subdirectory. One of these utilies is named mkzopeintance.py, and you
have to use it to create your Zope instance. mkzopeinstance will ask you
where you want to install the instance, and for an admin name and
password. Once done, you can start that instance with
/bin/zopectl/start, then point your browser
to localhost:8080/manage, log in, and enjoy !-)

HTH
-- 
bruno desthuilliers
développeur
[EMAIL PROTECTED]
http://www.modulix.com
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] à l'aide

2005-12-16 Thread Vlada Macek
[At 15.12.2005 20:31, Tino Wildenhain kindly sent the following quotation.]

> You need python2.3.5 or higher and also -dev libs of it. If you run
> "stable" your python might be too far back

Some day maybe, but AFAIK not yet: Debian Sarge (stable release) has
Python 2.3.5 (default, dependency package "python") and 2.4.1 (package
"python2.4") officially. Debian testing and unstable releases has python
2.4.2.

I'm happily using compiled Zope against debian "python" package on my
Sarge server.

-- 

\//\/\
(Sometimes credited as 1494 F8DD 6379 4CD7 E7E3 1FC9 D750 4243 1F05 9424.)

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] user account defined outside context of object being accessed

2005-12-16 Thread Kees de Brabander

- Original Message - 
From: "Dieter Maurer" <[EMAIL PROTECTED]>
To: "Kees de Brabander" <[EMAIL PROTECTED]>
Cc: 
Sent: Thursday, December 15, 2005 5:54 PM
Subject: Re: [Zope] user account defined outside context of object being
accessed


> Kees de Brabander wrote at 2005-12-13 22:40 +0100:
> > ...
> >  Module AccessControl.ImplPython, line 449, in validate
> >  Module AccessControl.ImplPython, line 774, in raiseVerbose
> >Unauthorized: Your user account is defined outside the context of the
object
> >being accessed.  Access to 'f1_index' of (Folder at /f1), acquired
through
> >(Folder at /f1/f11/f111), denied. Your user account, user1, exists at
> >/f1/f11/acl_users. Access requires one of the following roles:
> >['Authenticated', 'Manager', 'Owner', 'student'].
>
> A user defined in "/f1/f11/acl_users" tries to access the protected
> "/f1/f1_index". This is not allowed by Zope security system:
> a user defined in a user folder can only access protected objects
> "governed" by this user folder.
>
> In your case, all objects at or below "/f1/f11" is governed by
> your user folder ("/f1/f11/acl_users"). "/f1/f1_index" does not lie
> within this hierarchy and is therefore not governed.

I am painfully aware now that this is the case, at least starting from zope
2.7.8. I have not tested all versions of zope, but at least up to 2.7.3 zope
had no problem with such a set up.

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )