I understand the use cases and I see how using the "skin" concept for
XMLRPC is tempting. But couldn't you have done this is in an extra
package? This way, you wouldn't have had to touch at least three
different zope.* packages *and* risk breaking stuff for the others with
something as experimental as this is...
Christian Zagrodnick wrote:
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
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
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 :)
http://worldcookery.com -- Professional Zope documentation and training
Zope3-dev mailing list