I have set up a URL with a SMS-sending company. Basically, we set up so that http://ourhost:port/Folder/SMS/Receive should get the XML when someone sends an SMS to a particular number. How do I in Zope, or rather, in this External Method accept the XML? Once I get the XML-Schema in as a string I'll know what to do with it, but I'm not there yet. [NB: Invoking the URL manually in the browser works and even though it's just very basic debugging, it returns something without errors] If I try to standalone manually send an XML request using httplib as I think they'll send it to us I get this error in response: <strong>Error Type: ResponseError</strong><br> <strong>Error Value: <xmlrpclib.ResponseError instance at 0x92b7ba4></strong><br> Traceback (innermost last): File /local/home/peterbe/Zope-2.5.1-src/lib/python/ZPublisher/Publish.py, line 150, in publish_module File /local/home/peterbe/Zope-2.5.1-src/lib/python/ZPublisher/Publish.py, line 114, in publish File /local/home/peterbe/Zope-2.5.1-src/lib/python/Zope/__init__.py, line 159, in zpublisher_exception_hook (Object: Zope) File /local/home/peterbe/Zope-2.5.1-src/lib/python/ZPublisher/Publish.py, line 63, in publish File /local/home/peterbe/Zope-2.5.1-src/lib/python/ZPublisher/HTTPRequest.py, line 357, in processInputs File /local/home/peterbe/Zope-2.5.1-src/lib/python/ZPublisher/xmlrpc.py, line 47, in parse_input File /local/home/peterbe/Zope-2.5.1-src/lib/python/xmlrpclib.py, line 532, in loads File /local/home/peterbe/Zope-2.5.1-src/lib/python/xmlrpclib.py, line 369, in close ResponseError: (see above) Why xmlrpclib? Basically, how do I get the XML-Schema in as a string to work with from the XML request? Peter
Peter Bengtsson wrote:
I have set up a URL with a SMS-sending company. Basically, we set up so that http://ourhost:port/Folder/SMS/Receive should get the XML when someone sends an SMS to a particular number.
How do I in Zope, or rather, in this External Method accept the XML? Once I get the XML-Schema in as a string I'll know what to do with it, but I'm not there yet.
[NB: Invoking the URL manually in the browser works and even though it's just very basic debugging, it returns something without errors] If I try to standalone manually send an XML request using httplib as I think they'll send it to us I get this error in response:
<strong>Error Type: ResponseError</strong><br> <strong>Error Value: <xmlrpclib.ResponseError instance at 0x92b7ba4></strong><br>
Traceback (innermost last): File /local/home/peterbe/Zope-2.5.1-src/lib/python/ZPublisher/Publish.py, line 150, in publish_module File /local/home/peterbe/Zope-2.5.1-src/lib/python/ZPublisher/Publish.py, line 114, in publish File /local/home/peterbe/Zope-2.5.1-src/lib/python/Zope/__init__.py, line 159, in zpublisher_exception_hook (Object: Zope) File /local/home/peterbe/Zope-2.5.1-src/lib/python/ZPublisher/Publish.py, line 63, in publish File /local/home/peterbe/Zope-2.5.1-src/lib/python/ZPublisher/HTTPRequest.py, line 357, in processInputs File /local/home/peterbe/Zope-2.5.1-src/lib/python/ZPublisher/xmlrpc.py, line 47, in parse_input File /local/home/peterbe/Zope-2.5.1-src/lib/python/xmlrpclib.py, line 532, in loads File /local/home/peterbe/Zope-2.5.1-src/lib/python/xmlrpclib.py, line 369, in close ResponseError: (see above)
Why xmlrpclib?
Read the source, Luke ;) In HTTPRequest.py: 351 if (fs.headers.has_key('content-type') and 352 fs.headers['content-type'] == 'text/xml' and 353 method == 'POST'): 354 # Ye haaa, XML-RPC! 355 global xmlrpc 356 if xmlrpc is None: import xmlrpc 357 meth, self.args = xmlrpc.parse_input(fs.value) Zope thinks you want to do xmlrpc, which you don't - I think you just want to get a string, which contains XML. That's not xml-rpc.
Basically, how do I get the XML-Schema in as a string to work with from the XML request?
I'd expect the request to come in as a normal HTTP-POST, encoded like a form (i.e. "application/x-www-form-urlencoded" or "multipart/form-data"), so that you can get to the encoded string using the standard methods. HTH, oliver
A few days ago I mentioned a problem I was having with MySQLDA assuming that datetime data types are stored in the time zone used by Zope (rather than GMT) and asked if there was a good solution to this problem. Unfortunately, no one seems to have dealt with this before, so I am muddling through to a solution myself. The next quick fix would seem to be changing the time zone that Zope thinks it is running in to GMT. Is there a way to configure this or do I have to change the machine's time zone? TIA, Sincerely, Richard Wesley Co-President, Electric Fish, Inc. <http://www.electricfish.com/> (v) +1-206-493-1690x210 (f) +1-206-493-1697
I don't know what OS you're using, but there's probably three things going on here. On typical UNIX systems-- and this includes Linux-- there's (1) a hardware clock, (2) a system clock, and then (3) whatever time the database may think it is-- (3) should be the same as (2). The default install on UNIX systems I know about set the hardware clock to GMT (changed by an international standards group to "UTC"). Part of the system configuration is setting the timezone. Different Unices do this configuration differently. MS OSs again different. I'd recommend setting the hardware clock to UTC, then set the correct timezone so that system time tells the correct local time. Then see what time the database thinks it is. Doing the quick fix you're contemplating below will come back to bite you. E.g., what are you going to do in the DST flips? No one wants the wrong time attached to their data, but, at the same time, I'm sure you don't want to sit there at 2am twice a year to change the time. I've been using Linux for ten years and for ten years it's handled the switch to/from DST perfectly. This is really the way you want to go. While you're there, look into rdate. This won't get you out of the UTC/localtime configuration; rdate fetches the correct time from time a server (my systems do this once a day) and so keeps the time on your system accurate. All of this really should be required for an enterprise system. hth, ken Richard Wesley at 09:34 (UTC-0800) on Wed, 11 Dec 2002 said: = A few days ago I mentioned a problem I was having with MySQLDA = assuming that datetime data types are stored in the time zone used by = Zope (rather than GMT) and asked if there was a good solution to this = problem. Unfortunately, no one seems to have dealt with this before, = so I am muddling through to a solution myself. = = The next quick fix would seem to be changing the time zone that Zope = thinks it is running in to GMT. Is there a way to configure this or = do I have to change the machine's time zone? = = TIA, = Sincerely, = = Richard Wesley = Co-President, Electric Fish, Inc. = <http://www.electricfish.com/> = (v) +1-206-493-1690x210 = (f) +1-206-493-1697 = = _______________________________________________ = Zope maillist - Zope@zope.org = http://lists.zope.org/mailman/listinfo/zope = ** No cross posts or HTML encoding! ** = (Related lists - = http://lists.zope.org/mailman/listinfo/zope-announce = http://lists.zope.org/mailman/listinfo/zope-dev ) =
At 7:54 PM -0500 12/11/02, ken wrote:
I don't know what OS you're using, but there's probably three things going on here. On typical UNIX systems-- and this includes Linux-- there's (1) a hardware clock, (2) a system clock, and then (3) whatever time the database may think it is-- (3) should be the same as (2).
Linux, set to PST.
I'd recommend setting the hardware clock to UTC, then set the correct timezone so that system time tells the correct local time.
That is the current situation.
Then see what time the database thinks it is.
That is an interesting suggestion. MySQL has a Now() function. The problem is that MySQL's date appears to have no Time Zone information attached to it, so the convention is to store times as GMT (thus avoiding DST issues). But a quick check of the main server indicates that the database thinks it is in PST as well.
Doing the quick fix you're contemplating below will come back to bite you. E.g., what are you going to do in the DST flips?
That is why we want to use GMT.
No one wants the wrong time attached to their data, but, at the same time, I'm sure you don't want to sit there at 2am twice a year to change the time. I've been using Linux for ten years and for ten years it's handled the switch to/from DST perfectly. This is really the way you want to go.
As I mentioned, we are using Linux, and this is not a problem.
While you're there, look into rdate. This won't get you out of the UTC/localtime configuration; rdate fetches the correct time from time a server (my systems do this once a day) and so keeps the time on your system accurate.
We have this on all our systems.
All of this really should be required for an enterprise system.
Agreed, and we are doing the basics (rdate daemon). But the central issue remains: How do I convince MySQL to store dates as GMT, not local time? Judging from the Now() test I just did, the only solution is to change the system time to GMT. Sincerely, Richard Wesley Co-President, Electric Fish, Inc. <http://www.electricfish.com/> (v) +1-206-493-1690x210 (f) +1-206-493-1697
Hi, --On Donnerstag, 12. Dezember 2002 08:09 -0800 Richard Wesley <hawkfish@electricfish.com> wrote: ... *snip*...
While you're there, look into rdate. This won't get you out of the UTC/localtime configuration; rdate fetches the correct time from time a server (my systems do this once a day) and so keeps the time on your system accurate.
I'd suggest dropping rdate in favour of ntpdate, since this is much more advanced and gives better results even over slow lines. Regards Tino
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Agreed, and we are doing the basics (rdate daemon). But the central issue remains: How do I convince MySQL to store dates as GMT, not local time? Judging from the Now() test I just did, the only solution is to change the system time to GMT. So you're using Linux. Couldn't you write a trigger that gets the hwclock() time?
Why are you having MySQL keep up with the time? Why not just deal with ZopeTime, then subtract the appropriate amount of time based on whether it's DST or not? After all, how does your computer know when to change its clock (to DST or back)? Is that an overhead problem that you're trying to avoid? Sorry these are simple solutions, but maybe that's what's needed? Russell - -- Linux -- the OS for the Renaissance Man -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9+MZNAqKGrvVshJQRAmNLAKCEYM6KBjQMeWE8NDeuNgdx+TIM9ACffETj VFU/Jer6rmIqozi1vPUg9kg= =Zvt5 -----END PGP SIGNATURE-----
At 12:24 PM -0500 12/12/02, Russell Hires wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Agreed, and we are doing the basics (rdate daemon). But the central issue remains: How do I convince MySQL to store dates as GMT, not local time? Judging from the Now() test I just did, the only solution is to change the system time to GMT. So you're using Linux. Couldn't you write a trigger that gets the hwclock() time?
Why are you having MySQL keep up with the time? Why not just deal with ZopeTime, then subtract the appropriate amount of time based on whether it's DST or not?
The database should store times as GMT - this is a good idea simply because it gets rid of representation issues and silly problems like DST. Time zones then become simply a display issue and times in the database are well behaved and absolute.
After all, how does your computer know when to change its clock (to DST or back)?
My computer (at least on Linux) does not change its clock at all - all it does is change the string that is displayed. That string depends upon the system time zone. The problem is that while Zope's DateTime class is smart and understands absolute time and how to represent it in a particular time zone, MySQL does _not_ understand absolute time and makes assumptions that are not very robust, e.g. what happens to stored dates if you move the machine to another time zone? So, the question remains: Does anyone have a goo way to get MySQL and/or its Zope DB adapter to handle dates in GMT rather than local time? TIA, Sincerely, Richard Wesley Co-President, Electric Fish, Inc. <http://www.electricfish.com/> (v) +1-206-493-1690x210 (f) +1-206-493-1697
Richard, I'm not following the rational for wanting your database to think it's GMT, but that's okay. Whatever time you want MySQL to think it is can be set at the command line with the --timezone option, like --timezone=UTC If you're curious, this is processed by /usr/bin/safe_mysqld. Also check to see if there's something in /etc/my.conf like TZ=PST8PDT export TZ Again, change the value to your desired timezone. hth, ken Richard Wesley at 08:09 (UTC-0800) on Thu, 12 Dec 2002 said: = At 7:54 PM -0500 12/11/02, ken wrote: = >I don't know what OS you're using, but there's probably three things = >going on here. On typical UNIX systems-- and this includes Linux-- = >there's (1) a hardware clock, (2) a system clock, and then (3) whatever = >time the database may think it is-- (3) should be the same as (2). = = Linux, set to PST. = = >I'd recommend setting the hardware clock to UTC, then set the correct = >timezone so that system time tells the correct local time. = = That is the current situation. = = >Then see = >what time the database thinks it is. = = That is an interesting suggestion. MySQL has a Now() function. = = The problem is that MySQL's date appears to have no Time Zone = information attached to it, so the convention is to store times as = GMT (thus avoiding DST issues). But a quick check of the main server = indicates that the database thinks it is in PST as well. = = >Doing the quick fix you're = >contemplating below will come back to bite you. E.g., what are you = >going to do in the DST flips? = = That is why we want to use GMT. = = >No one wants the wrong time attached to = >their data, but, at the same time, I'm sure you don't want to sit there = >at 2am twice a year to change the time. I've been using Linux for ten = >years and for ten years it's handled the switch to/from DST perfectly. = >This is really the way you want to go. = = As I mentioned, we are using Linux, and this is not a problem. = = >While you're there, look into rdate. This won't get you out of the = >UTC/localtime configuration; rdate fetches the correct time from time a = >server (my systems do this once a day) and so keeps the time on your = >system accurate. = = We have this on all our systems. = = >All of this really should be required for an enterprise system. = = Agreed, and we are doing the basics (rdate daemon). But the central = issue remains: How do I convince MySQL to store dates as GMT, not = local time? Judging from the Now() test I just did, the only = solution is to change the system time to GMT. = Sincerely, = = Richard Wesley = Co-President, Electric Fish, Inc. = <http://www.electricfish.com/> = (v) +1-206-493-1690x210 = (f) +1-206-493-1697 = = _______________________________________________ = Zope maillist - Zope@zope.org = http://lists.zope.org/mailman/listinfo/zope = ** No cross posts or HTML encoding! ** = (Related lists - = http://lists.zope.org/mailman/listinfo/zope-announce = http://lists.zope.org/mailman/listinfo/zope-dev ) =
Ken - At 3:16 PM -0500 12/12/02, ken wrote:
Richard,
I'm not following the rationale for wanting your database to think it's GMT, but that's okay.
We have to pick a representation for the database because it does not appear to support one natively. The choices are either UTC or or local time. If we decide to share a database among several servers distributed around the world, they all need to agree on a single time representation, at which point "local time" becomes meaningless. Hence our use of UTC.
Whatever time you want MySQL to think it is can be set at the command line with the --timezone option, like
--timezone=UTC
If you're curious, this is processed by /usr/bin/safe_mysqld.
Fabulous. Thanks for the info.
Also check to see if there's something in /etc/my.conf like
TZ=PST8PDT export TZ
Again, change the value to your desired timezone.
I will check these out. There is still the problem, though, of how to make Zope send GMT through the ZMySQLDA module. I can hack up the adapter, but I was sort of hoping that there was some sort of configuration for it. Sincerely, Richard Wesley Co-President, Electric Fish, Inc. <http://www.electricfish.com/> (v) +1-206-493-1690x210 (f) +1-206-493-1697
participants (6)
-
ken -
Oliver Bleutgen -
Peter Bengtsson -
Richard Wesley -
Russell Hires -
Tino Wildenhain