Advertising

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.