Re: [Zope3-dev] Re: skin support for xmlrpc

2007-09-18 Thread Dieter Maurer
Christian Zagrodnick wrote at 2007-9-18 08:35 +0200:
On 2007-09-16 09:03:47 +0200, Dieter Maurer [EMAIL PROTECTED] said:
 Ok, then I suggest:
 
 * Provide an IRequestType interface in zope.publisher
 
 Does this name sound wrong?
 
It suggests the the interface has to do with request types,
maybe browser, xmlrpc, ...
 
It that what we want?

IAPIType?
IApi?
IHTTPApiType?

/me is confused again. :/

Me, too.

Terms are very important for me -- and I could not understand
RequestType. What should it mean that zope.publisher provides
an IRequestType. What types are these? Do you mean types
in the sense of browser requests, xml-rpc requests, ftp requests, ...
or something else?



-- 
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: skin support for xmlrpc

2007-09-16 Thread Dieter Maurer
Christian Zagrodnick wrote at 2007-9-15 12:34 +0200:
 ...
Ok, then I suggest:

* Provide an IRequestType interface in zope.publisher

Does this name sound wrong?

   It suggests the the interface has to do with request types,
   maybe browser, xmlrpc, ...

   It that what we want?



-- 
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: skin support for xmlrpc

2007-09-14 Thread Christian Zagrodnick


On 13.09.2007, at 18:07, Roger Ineichen wrote:


Hi


Betreff: [Zope3-dev] Re: skin support for xmlrpc


On 13.09.2007, at 17:28, Philipp von Weitershausen wrote:


Christian Theune wrote:

Let me propose a change:
1. We revert the change.


Any news on this?


Yes. Over the last few days I pondered about how to do it
without xmlrpc layers. But there doesn't seem to be a way
nice and easy  way.
So I will need to implement the layer support in a different
package.
The revert will be done till monday, maybe already tomorrow.
Sorry for the delay.

Anyway, could somebody who had an error with that tell me
what the problem was? I just heard we had a problem.


Why revert? We need layers in every kind of context, request
adapter registration because it's the concept which permission
get registered in different projects on a single server sharing
packages.

The problem is simple, XML-RPC has used the IBrowserRequest
and now it uses the IXMLRPCRequest. This is why the XML-RPC
views in different projects don't work anymore. This means
the XML-RPC uses a browser request which is bad because it
enables the views everywhere.


No no. XML-RPC did use IXMLRPCRequest before. All I added was the  
IXMLRPCSkinType which did not exist.


What I also changed is the ++skin++ traverser which was registered  
for * instead of IBrowserRequest. But I consider the old behaviour  
a bug since skins were only valid with IBrowserRequest.





The solution is to provide the request interface which was the
default before the changes.

But don't take the option way to use other request interface then
the default for registration.

I'll need it. Because I'll take care on security and don't like
to register everything on whatever.


Before I'll revert the layer-support will be there in a third party  
package, probably using ++api++.



--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891




PGP.sig
Description: This is a digitally signed message part
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: skin support for xmlrpc

2007-09-14 Thread Christian Theune
Am Freitag, den 14.09.2007, 02:49 -0400 schrieb Fred Drake:
 On 9/14/07, Christian Zagrodnick [EMAIL PROTECTED] wrote:
  Before I'll revert the layer-support will be there in a third party
  package, probably using ++api++.
 
 Better to be specific than general when it's for a specific type of
 request; why not ++xmlrpc++?
 
 Unless ++api++ is for more than XML-RPC support; perhaps it should be
 for IHTTPRequest?
 
 I'd actually rather avoid a proliferation of ++namespace++ usages
 myself, and prefer ++api++ for IHTTPRequest.

+1

-- 
gocept gmbh  co. kg - forsterstrasse 29 - 06112 halle/saale - germany
www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: skin support for xmlrpc

2007-09-14 Thread Christian Zagrodnick


On 14.09.2007, at 08:49, Fred Drake wrote:


On 9/14/07, Christian Zagrodnick [EMAIL PROTECTED] wrote:

Before I'll revert the layer-support will be there in a third party
package, probably using ++api++.


Better to be specific than general when it's for a specific type of
request; why not ++xmlrpc++?

Unless ++api++ is for more than XML-RPC support; perhaps it should be
for IHTTPRequest?

I'd actually rather avoid a proliferation of ++namespace++ usages
myself, and prefer ++api++ for IHTTPRequest.


So you're suggesting using ++api++ to choose the request type for all  
IHTTPRequests. That's fine for me. I just wonder why I should remove  
the skin support for XML-RPC since that is just choosing the  
request type...


/me is confused.

--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891




PGP.sig
Description: This is a digitally signed message part
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: skin support for xmlrpc

2007-08-27 Thread Jodok Batlogg

hi christian,

On 24.08.2007, at 15:12, Stephan Richter wrote:


On Friday 24 August 2007 02:37, Christian Zagrodnick wrote:

The term skin is probably missleading but was taken to keep it
simple. It's more an api-set.


Then don't use it! Misusing a concept can lead to a lot of confusion.


it's misleading for me as well :)


Usecase: Different API on the same server

We have a lot XML-RPC methods defined for ISite which get all their
data in. This is quite unlike one would register XML-RPC mehtods
normally, but the clients using the interface are not sophisticated
enough.

Now there are different systems talking with Zope. The systems have
some things in common, some not. One systems calls a method, say
list_foo anonymous, while another needs to authenticate for list_foo.

The idea is now to register list_foo for different
layers/skins/api-sets. This could also be achieved by creating dummy
model-objects and/or traversers, but would be much less  
understandable.


What essentially happens is that the views are registered for  
different

request types.


You can solve this issue easily using pluggable traversers. There is
absolutely no need to use skins here. For example, a traverser  
plugin can
simply mark the request with a directly provided interface and  
return the
same object. This would work very much like a skin without mis- 
using the

concept.


for me xmlrpc is remote procedure call. a rpc has a signature and  
always the same result. and as stephan said - traversers should help  
here.





Usecase: Authenticate Users depending on the skin

As i said before there are different systems which need to
authenticate. The systems have disjunctive sets of users with
potentially the same login names. There needs to be a way to
authenticate without guessing which set of users we're talking about.

This could also be achieved by a custom traverser or namespace.


Then use a custom traverser, please!? :-)


+1


It probably would not be much of a problem to remove the skin things
again and put it directly to the project or another third-party
component. But it doesn't feel right.


Please revert the skin support again. This is a pretty major change  
and I gave
a -1 on the original discussion already. There was never a full  
proposal

either.


-1 from here as well.

jodok



Regards,
Stephan
--
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 
40lovelysystems.com




--
In the face of ambiguity, refuse the temptation to guess.
  -- The Zen of Python, by Tim Peters

Jodok Batlogg, Lovely Systems
Schmelzhütterstraße 26a, 6850 Dornbirn, Austria
phone: +43 5572 908060, fax: +43 5572 908060-77




smime.p7s
Description: S/MIME cryptographic signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com