cherrypy-devel — For the development of CherryPy

[Cherrypy-devel] xmlrpc modifications

[Steven N. <ste...@th...>]

A. The config file parsing is pretty straightforward. Here's what I make
of it.

1. Set default for _xmlRpc to 1
2. Create a _http variable and set its default to 1
3. Add parsing of typeOfRequests in the [server] block to modify these
values.


B. Next, comes parsing the type argument. I found this line in
cherrypy.py:
 if functionDef.rstrip()[-7:]=="hidden:":

So, this looks like a good place to check for the type.

1. Can we say that 'hidden' and 'xmlrpc' never occur together? It makes
sense to me that something can't be both. Or, in other words, anything
that's hidden defaults to HTML. Fair?

2. Can we say that if no type is declared, then HTML is the default?



C. If I follow the way you like to do things...does this make sense?

For each supported typeOfRequest, we assign a list of methods, so we
wind up with:
 {'xmlRpc':['methodA','methodB'], 'http':['methodC', 'methodD']}

Then, in httpTools._parsePostData(), where you currently have:

  if _xmlRpc and request.path=="RPC2":
    ...
  else:
    ...

we put

  if _xmlRpc and [this method is in the list above keyed on xmlRPC]:
    ...
  elif _http and [this method is in the list above keyed on http]:
    ...
  else:
    [error]

Make sense so far?


D. If we've gotten through so far, then we're down to this:

1. What's the approved method for transporting the dictionary around? 

2. For populating the ['methodA', 'methodB'] lists and doing our
conditional tests, I'm thinking we just use request.path values. Does
that sound reasonable? 

3. What would you like to happen in the [error] case? I think there's a
"no method for this path" type error already. Any tips on how to point
to that?


Okay, that's the proposal (with questions). Fire away.

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

[Steven N. <ste...@th...>]

I think 10 days may be too far out for me. I'm willing to take this on,
if you'll continue to answer questions. In my head, it's just a few
hours worth of work--I hope I'm not fooling myself.

I just registered on sourceforge. Username: steveatwaypath.

How best to implement? I'll look through the code and come up with
specific questions about what happens where. 

On Mon, 2003-03-10 at 09:07, Remi Delon wrote:
> > 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?
> 
> Yep
> 
> > Now, would you like me to do any of it? If so, we can discuss how to
> > best get it done.
> 
> Well, it depends how soon you want it. I won't be able to work on it in the
> next 10 days. On the other hand, if you want to go for it, you'll have to
> really get into the code and understand how it works. It's up to you ...
> 
> If you want to work on it, just register on sourceforge (if you aren't
> registered yet), tell me your username and I'll add you to the project as a
> developer. After that, you'll be able to use the CVS repository, run
> "update", "commit", etc ...
> 
> Remi.
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Cherrypy-devel mailing list
> Che...@li...
> https://lists.sourceforge.net/lists/listinfo/cherrypy-devel
> 

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

[Remi D. <re...@ch...>]

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

Yep

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

Well, it depends how soon you want it. I won't be able to work on it in the
next 10 days. On the other hand, if you want to go for it, you'll have to
really get into the code and understand how it works. It's up to you ...

If you want to work on it, just register on sourceforge (if you aren't
registered yet), tell me your username and I'll add you to the project as a
developer. After that, you'll be able to use the CVS repository, run
"update", "commit", etc ...

Remi.

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

[Steven N. <ste...@th...>]

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

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

[Remi D. <re...@ch...>]

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

[Cherrypy-devel] CherryPy-0.8 released

[Remi D. <re...@ch...>]

Good day everyone,

I'm pleased to announce the release of CherryPy-0.8
This release includes all the improvements from the 0.8-beta release (mostly
a new HTTP server) and it fixes a few bugs in it.
It also adds a new way to control where the logs are sent (there is a new
HowTo in the documentation about it).

Regards.

Remi.

Re: [Cherrypy-devel] RE: Some (initial) patches against 0.8 beta

[Brian M. <bri...@co...>]

Remi wrote:
> Okay. We can add a new CherryPy special function called "logMessages"
whose
> default behavior is to log messages to screen and/or to file (according to
> the config file) and that can be overwritten by the user (just like the
> "onError" special function)
...
> Well, the logging problem can be solved with the solution I propose above.
> As for the configuration problem: what kind of configuration information
is
> available in the database ? socketPort ? If not, then you can just use the
> "initServer" special function to get your own options from wherever you
> want.

Sounds fine.  Thanks.

Regards,
-Brian.

[Cherrypy-devel] RE: Some (initial) patches against 0.8 beta

[Remi D. <re...@ch...>]

> > - About logging: that's something I had on my mind. I think we
> should give
> > the user the option to log messages to screen and/or to file (or no
> messages
> > at all). I'm thinking about 2 new options in the config file:
> > logsToScreen=0|1 and logFile=/tmp/myLogFile
>
> I have no objection to this, but I'd like to be in a position to override
> the CherryPy supplied code if it does not fit my needs.  For
> example, in an
> embedded device one might have a custom API for a circular log
> that sits in
> NVRAM, or under Windows * one might want to put certain messages into the
> Windows event log.

Okay. We can add a new CherryPy special function called "logMessages" whose
default behavior is to log messages to screen and/or to file (according to
the config file) and that can be overwritten by the user (just like the
"onError" special function)

> > - As you may have noticed, I removed the -S option from the command line
> (it
> > was used to specify which service (http) and which mode (threading,
> forking)
> > to use). The reason is that I wanted users to be able to
> specify these at
> > execution time, and not compile time (in other words, you don't have to
> > recompile the server in order to change from threading to forking).
> >
> > - About wrapperPrefixStart.py: Maybe you could tell me what kind of code
> you
> > put in it so I understand the need for it. But anyway, I don't think it
> > should be called "httpStart.py", because it has nothing to do with the
> HTTP
> > service (and it is not related to httpEnd.py).
> >
> > - About wrapperPrefixEnd.py: I understand that the code could
> be different
> > for another service. But in that case, I'd like to take the "no need to
> > recompile" approach. In other words, the service would be
> specified in the
> > config file.
> >
> > - Overall, I have to admit the I don't really like the idea of
> letting the
> > user include arbitrary ".py" files that he writes. If we want to make
> > CherryPy more customizable, we could use the "special
> functions" approach,
> > and let the user define other special functions in the source files
> (".cpy"
> > files).
> >
> > But then again, if you tell me examples of what you need to do
> then maybe
> > I'll realize that what you're proposing is the best solution.
>
> Well perhaps I can achieve my goals by being able to replace the logging
> mechanism, and the parameter passing module (which you've already
> seperated
> out).  Basically, I want to be able to run a CherryPy server in various
> 'embedded' situations where I may have strange logging constraints, or the
> configuration information available in a custom database.

Well, the logging problem can be solved with the solution I propose above.
As for the configuration problem: what kind of configuration information is
available in the database ? socketPort ? If not, then you can just use the
"initServer" special function to get your own options from wherever you
want.

> Once I dust the cobwebs off it, I may also want to run a ThreadedPool
> version of CherryPy, as opposed to the thread-per-request support that the
> ThreadedMixIn provides.  (I was planning to submit this to you anyway).

Okay. This shouldn't be too hard to write. CherryPy already has a
"fixedNumberOfProcesses" option, which is the process equivalent of a
ThreadedPool.

Thanks.

Remi

[Cherrypy-devel] New cherrypy-devel mailing list

[Remi D. <re...@ch...>]

Hi folks,

since several people are now contributing to the CherryPy source code, I've
set up a new mailing list called cherrypy-devel.
All discussion about the development of CherryPy itself should take place on
that list.

Information about the list is available from the CherryPy website.

Regards.

Remi

[Cherrypy-devel] Re: Some (initial) patches against 0.8 beta

[Brian M. <bri...@co...>]

Hi Remi,

You wrote:
> - First of all, I created a new mailing list cherrypy-devel and I think we
> should talk on that list.

Great!  I signed up today. :-)

> - About logging: that's something I had on my mind. I think we should give
> the user the option to log messages to screen and/or to file (or no
messages
> at all). I'm thinking about 2 new options in the config file:
> logsToScreen=0|1 and logFile=/tmp/myLogFile

I have no objection to this, but I'd like to be in a position to override
the CherryPy supplied code if it does not fit my needs.  For example, in an
embedded device one might have a custom API for a circular log that sits in
NVRAM, or under Windows * one might want to put certain messages into the
Windows event log.

> - As you may have noticed, I removed the -S option from the command line
(it
> was used to specify which service (http) and which mode (threading,
forking)
> to use). The reason is that I wanted users to be able to specify these at
> execution time, and not compile time (in other words, you don't have to
> recompile the server in order to change from threading to forking).
>
> - About wrapperPrefixStart.py: Maybe you could tell me what kind of code
you
> put in it so I understand the need for it. But anyway, I don't think it
> should be called "httpStart.py", because it has nothing to do with the
HTTP
> service (and it is not related to httpEnd.py).
>
> - About wrapperPrefixEnd.py: I understand that the code could be different
> for another service. But in that case, I'd like to take the "no need to
> recompile" approach. In other words, the service would be specified in the
> config file.
>
> - Overall, I have to admit the I don't really like the idea of letting the
> user include arbitrary ".py" files that he writes. If we want to make
> CherryPy more customizable, we could use the "special functions" approach,
> and let the user define other special functions in the source files
(".cpy"
> files).
>
> But then again, if you tell me examples of what you need to do then maybe
> I'll realize that what you're proposing is the best solution.

Well perhaps I can achieve my goals by being able to replace the logging
mechanism, and the parameter passing module (which you've already seperated
out).  Basically, I want to be able to run a CherryPy server in various
'embedded' situations where I may have strange logging constraints, or the
configuration information available in a custom database.

Once I dust the cobwebs off it, I may also want to run a ThreadedPool
version of CherryPy, as opposed to the thread-per-request support that the
ThreadedMixIn provides.  (I was planning to submit this to you anyway).

> > BTW, the files in lib/*.py have a GPL license in them.  Since the code
in
> these files actually gets included in the
> > resultant xxxServer.py, I believe this may cause some people
difficulties.
> Would it be possible to put these files under a
> > more friendly license, while keeping cherrypy.py etc GPL.
>
> You're right. I'll just remove the license from these files. That's what I
> did with the "src/*.py" files, because someone complained about it, but I
> didn't realize that "lib/*.py" files where in the same case :-)

Thanks.

Regards,
-Brian.

[Cherrypy-devel] RE: Some (initial) patches against 0.8 beta

[Remi D. <re...@ch...>]

Hello Brian,

> First, I want to be able to use my own startup code when 'embedding'
CherryPy, so I've split the hardcoded values out of
> cherrypy.py & allowed them to be loaded from a file called
wrapperPrefixStart.py.  I also split the code out from the end
> of httpServer & it will now be loaded from wrapperPrefixEnd.py.  A new
command line option allows the user to change
> wrapperPrefix from its default value of "http".  These changes are include
in the copies of the files in beta-patch1.tar.gz
> Furthermore, I want to be able to ensure that no "print"s are called by
CherryPy, for those cases where I want to run
> CherryPy in a Windows NT/2000 service.  To this end, I updated
httpStart.py to include a log function & changed all
> (relevant) occurances of print in CherryPy code to use this log function.
Default behaviour is the same as the 0.8 beta,
> but I can now change log behaviour from a central (customizable) location.
beta-patch2.tar.gz includes this & the previous
> patches.

Let me try to take one thing after the other:

- First of all, I created a new mailing list cherrypy-devel and I think we
should talk on that list.

- About logging: that's something I had on my mind. I think we should give
the user the option to log messages to screen and/or to file (or no messages
at all). I'm thinking about 2 new options in the config file:
logsToScreen=0|1 and logFile=/tmp/myLogFile

- As you may have noticed, I removed the -S option from the command line (it
was used to specify which service (http) and which mode (threading, forking)
to use). The reason is that I wanted users to be able to specify these at
execution time, and not compile time (in other words, you don't have to
recompile the server in order to change from threading to forking).

- About wrapperPrefixStart.py: Maybe you could tell me what kind of code you
put in it so I understand the need for it. But anyway, I don't think it
should be called "httpStart.py", because it has nothing to do with the HTTP
service (and it is not related to httpEnd.py).

- About wrapperPrefixEnd.py: I understand that the code could be different
for another service. But in that case, I'd like to take the "no need to
recompile" approach. In other words, the service would be specified in the
config file.

- Overall, I have to admit the I don't really like the idea of letting the
user include arbitrary ".py" files that he writes. If we want to make
CherryPy more customizable, we could use the "special functions" approach,
and let the user define other special functions in the source files (".cpy"
files).

But then again, if you tell me examples of what you need to do then maybe
I'll realize that what you're proposing is the best solution.

> BTW, the files in lib/*.py have a GPL license in them.  Since the code in
these files actually gets included in the
> resultant xxxServer.py, I believe this may cause some people difficulties.
Would it be possible to put these files under a
> more friendly license, while keeping cherrypy.py etc GPL.

You're right. I'll just remove the license from these files. That's what I
did with the "src/*.py" files, because someone complained about it, but I
didn't realize that "lib/*.py" files where in the same case :-)

Regards.

Remi.