[Zope3-dev] Re: skin support for xmlrpc

[Philipp von Weitershausen]

Christian,

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:
>> 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


-- 
http://worldcookery.com -- Professional Zope documentation and training