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

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

I think that's a great solution. To recap:

a. we add an xmlrpc modifier to declarations of masks and views
b. we drop the xmlrpc= config param
c. we add a typeOfRequests= config param that takes [web | xmlrpc |
web,xmlrpc] for now, with the option to expand it later...much later.

Is that right?

Now, would you like me to do any of it? If so, we can discuss how to
best get it done.

Best,
Steve

On Mon, 2003-03-10 at 00:29, Remi Delon wrote:
> > 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.
> 
> 
> 
> 