[Zope3-dev] Re: skin support for xmlrpc

[Christian Zagrodnick]

On 2007-08-24 07:55:08 +0200, Jodok Batlogg <jodok at lovelysystems.com> said:

> 
> hi christian,
> 
> it seems like your recent changes to support skins in xmlrpc views =20
> introduced some troubles.
> we spent several hours to debug not working xmlrpc views and finally =20
> found that nailing the zope.traversing egg to 3.4.x resolved the =20
> troubles.
> 
> while looking at your changes we were wondering why you want to =20
> support skins in xmlrpc views? for me, a xmlrpc call is a remote =20
> procedure call and has to do nothing with skins. it's not yellow, =20
> pink or orange and has no templates associated. can you explain your =20
> use-case for this?

Oh, thanks for the reminder, I completely forgot writing about that.

Though I wonder what the problems were.



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


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.



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.



As you can see, there is no usecase which can't be solved differently. 
But still we think that using the same system as skins for browser 
views is the right way to do that. We might want to talk about the 
naming though and call it api or alike.

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.

Now shoot :)

Regards
-- 
Christian Zagrodnick

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