[Cherrypy-devel] RE: [Cherrypy-users] xmlrpc paths

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

> CherryPy actually does allow virtual hosting, because you can parse
> request.base and send things to different paths. So, I could redirect
> test1.server.com/ to Test1_root, and let www.server.com go to Root.
>
> I'm looking for that level of functionality here, too, and I'm
> comfortable taking the simplest approach to get there. I'm also hoping
> you'll see the value in adding it to CherryPy, because once I branch
> off, it'll be a huge pain to move to the next release.
>
> I'm comfortable with the option of adding method to the path, resulting
> in calls like xmlrpc_test1_system.listMethods(). However, that still
> leaves the issue of CherryPy knowing which methods or classes are
> XML-RPC and which are HTML. I think we've come up with three approaches
> for that so far:
>  - a config param of xmlrpc?, where the ? is methods or classes or
> something.
>  - a class attribute of self.isXMLRPC, or something like that
>  - a modifier to the declaration of a method or class stating that it's
> XML-RPC (e.g. def listMethods(self) xmlrpc:)

Well, the third solution is the one I like best.
This means that we can keep the function/mask/view paradigm for XML-RPC: for
instance, if one wants to write an XML-RPC method with a mask, they can do
it.

So one could write something like this:

CherryClass BookApp:
function:
    def updateBook(self, bookName):
        # ... actually update the book name
view:
    def updateBookXmlRpc(self, bookName) xmlrpc:
        self.updateBook(bookName)
        return "OK"
mask:
    def updateBookWeb(self, bookName):
        <py-eval="self.updateBook(bookName)">
        <html><body>OK</body></html>

I think this is an elegant solution ...

Now, if we go with this solution, we can ask ourselves if we still need the
xmlRpc option in the config file (because seeing "xmlrpc" in the source file
means that the server should handle XML-RPC requests).

I think we should keep the config variable, and even improve it ... We
should give the user the choice to turn on/off both web requests and/or
XML-RPC requests at deployment time. So I propose to remove the xmlRpc
variable and add a new variable called "typeOfRequests" for instance, whose
value is "web,xmlrpc" by default

> What about something like this as a long-term solution? We (You?) add an
> attribute to all CherryClasses like self.mimeType, or maybe something
> less suggestive, like self.pageType. The default would be HTML, of
> course, but XMLRPC could be an option. This leaves the door open for
> future protocols, like SOAP or, I don't know, something else.

I don't really like the idea of an instance attribute. First of all, this
attribute should somehow be at the method level, not the class level. The
problem is that if this attribute is set within the method, we won't know it
ahead of time (like we need to know for XML-RPC calls).
By the way, the current situation is that if you want to return something
other than HTML, you set the Content-Type in the response header.

If we want to add SOAP support, we can just add the new "soap" keyword, just
like the "xmlrpc" keyword.

Remi.