> Maybe we should switch to store all userinfo data and put that into it's
> own table? Key the username and the userinfo key? So that we don't need
> to implement this for every change Userland might do in the future?
IMHO we shouldn't move *everything* over to a scheme like this, but it does
sound sensible to make a storage space for unrecognised data. It depends
how it's going to be sent back ... if there's a point where we just send
back a struct containing exactly what we've been given, this sort of storage
makes sense. If we have to scatter everything through three different
calls, we might as well just add a column to the user table every time
something changes ...
Cheers,
Phil :)
> Thought about that a little bit and I think there is still something
> unclear: how does the value reach the client? If Radio sends the data in
> with a ping, it gets stored in the user record. Ok. We can return the
> value with the user data in the ping response. Ok. But when you set up a
> Radio instance, it fetches the values via getServerCapabilities. This
> always returns our own commentsPage. Should this be changed, too? So that
> it returns the commentsPageUrl of the user, if he has stored one?
Well, seeing as getServerCapabilities doesn't take a usernum, I can't see
how it's possible to return the stored value ;-)
I plan on looking at how RCS does it [by looking at what rcs.salon.com sends
bzero when I'm posting to Second p0st] and doing it exactly the same way.
It doesn't make any sense to be different, if we're trying to be compatible
with Radio.
Cheers,
Phil
Hi!
>> "system.verbs.builtins.radio.thread.agents.pingCloud changed on Mon,
>> 09 Dec 2002 22:40:46 GMT: Save weblogData.prefs.commentsPageUrl in
>> the cloud. Used when setting up a new Radio installation for an
>> existing user."
>>
>> Should/must we implement that, so that new Radio installations will
>> behave the same with pycs as with rcs?
>
> Oh, yeah, definitely implement that. Presumably Radio now sends
> another value in the 'userData' struct on ping()?
Thought about that a little bit and I think there is still something
unclear: how does the value reach the client? If Radio sends the data in
with a ping, it gets stored in the user record. Ok. We can return the
value with the user data in the ping response. Ok. But when you set up a
Radio instance, it fetches the values via getServerCapabilities. This
always returns our own commentsPage. Should this be changed, too? So that
it returns the commentsPageUrl of the user, if he has stored one?
bye, Georg
Hi!
>>> Oh, yeah, definitely implement that. Presumably Radio now sends
>>> another value in the 'userData' struct on ping()?
>>
>> Don't know, I did not check into it yet, I just read the changelog
>> entry.
>
> It should show up in etc.log ...
Maybe we should switch to store all userinfo data and put that into it's
own table? Key the username and the userinfo key? So that we don't need
to implement this for every change Userland might do in the future?
bye, Georg
Hi!
> Oh, yeah, definitely implement that. Presumably Radio now sends
> another value in the 'userData' struct on ping()?
Don't know, I did not check into it yet, I just read the changelog entry.
> ... encoding="iso-8859-1"?> should be fine. I wonder if we can
> compile MetaKit to use unicode ... hmm.
This would at least solve the backend problem. Still there are the
problems of Radio not supporting it (not our problem ;-) ) and Browsers
not supporting it in some reproduceable way - for example some browsers
send Text in forms in unicode sometimes. Weird stuff happens out
there ...
bye, Georg
Hey,
It looks like MetaKit does indeed support unicode:
http://www.equi4.com/metakit/format.html
Maybe the lack of support we're seeing is just an issue with Mk4py -
which is *much* easier to solve than if we had to hack unicode support
into MetaKit from scratch ...
Cheers,
Phil :)
On Tue, Dec 10, 2002 at 09:32:39PM +0100, Georg Bauer wrote:
> From the updates to radio.root:
>
> "system.verbs.builtins.radio.thread.agents.pingCloud changed on Mon, 09
> Dec 2002 22:40:46 GMT: Save weblogData.prefs.commentsPageUrl in the
> cloud. Used when setting up a new Radio installation for an existing
> user."
>
> Should/must we implement that, so that new Radio installations will
> behave the same with pycs as with rcs?
Oh, yeah, definitely implement that. Presumably Radio now sends
another value in the 'userData' struct on ping()?
As for the UTF-8 / ISO-8859-1 stuff: very cool. XML-RPC officially
defaults to using ISO-8859-1 (it calls it 'US ASCII', I think), so
hacking up the XML parser to change the <?xml...?> tag into <?xml
... encoding="iso-8859-1"?> should be fine. I wonder if we can
compile MetaKit to use unicode ... hmm.
Cheers,
Phil :)
From the updates to radio.root:
"system.verbs.builtins.radio.thread.agents.pingCloud changed on Mon, 09
Dec 2002 22:40:46 GMT: Save weblogData.prefs.commentsPageUrl in the
cloud. Used when setting up a new Radio installation for an existing
user."
Should/must we implement that, so that new Radio installations will
behave the same with pycs as with rcs?
bye, Georg
Hi!
I fiddled around with some umlaut problems in pycs and found (and
implemented) a solution. Now I feel dirty.
The story:
A user has an umlaut (char with high bit set) in his name. He can't
register nor ping nor do anything where his name or a title for his weblog
is transferred when it includes Umlauts. Reason: Radio doesn't give the
right encoding.
So the first stage was to hack something into pycs to replace the xml
header with one with the encoding paramter given. Now it should work, as
the request gives a nice and cozy encoding, right? Wrong.
The second stage was that pycs bars on all parts when unicode strings are
passed in, because parts of it don't work well with unicode. And strings
with umlauts are converted to unicode strings, where normal strings are
converted to normal strings. That's done by the parser transparently. As
soon as you have umlauts, you will get unicode strings. And for example
metakit doesn't like them.
So I had to add another hack. Even worse hack.
Want to know what hacks? Ok, here they come:
- added a defaultencoding option to pycs.conf - only if this setting is
uncommented and set, the hacks are activated. So everything should work as
before without setting this. Nothing should break.
- added a shim for continue_request in pycs_xmlhandler.py to fetch the XML
request and replace the standard XML header without encoding (and _only_
the one without encoding - if there is one with encoding given, nothing
will happen here! - with one with the encoding="defaultencoding"
- added code to this shim to do everything manually. The original
continue_request has exception handling, I copied it. The original used
xmlrpclib.loads, I replaced that with the innards of this function from
xmlrpclib
- added a Class Unmarshaller in pycs_xmlhandler.py to override the
end_string method with one that changes unicode strings to iso-8859-1
encoded normal strings
- patched the xmlrpclib.Unmarshaller, call getparser, unpatch
xmlrpclib.Unmarshaller, work with the new patched unmarshaller. Yes, this
is dirty, but it works because of the non-threadedness of Medusa - there
is no parallel thread that might stumble over the patched version of
Unmarshaller
The rest is normal hacking, copying and pasting. Weird, bad, ugly. But it
has one good value: it works. Now pycs and Radio work happily together and
accept umlauts in the iso-8859-1 encoding.
This is a problem because there are others out there using other
encodings? Right. But there are already several problems in pycs and the
python environment, so we don't make it worse:
- metakit doesn't support unicode, but only standard 8bit encodings
- the xml parsers available only support a limited range of encodings,
most notably unicode, utf-8 and iso-8859-1 - so if you use different
chars, you are already lost, as your XML in that encoding won't be parsed
- radio doesn't give a flying fart on encodings and just delivers a
standard xml header, that is meant to be "take what I send, just store it"
but is in reality by the XML standard defined as UTF-8. You can actually
be happy when Radio delivers iso-8859-1 chars in it's XML and not actual
Macintosh codes :-/
So if somebody is willing to fully support all encodings available in
unicode, he would have to do the following:
- get the client applications to send XML in UTF-8
- rip out metakit and plug in something that understands UTF-8
To repeat: the hack is bad, but it is the only (at least to me) currently
known way to get 8bit chars working for pycs. This is not only a problem
with regard to Radio, but with regard to Metakit, too.
Comments?
bye, Georg
Hi!
I again looked at templating systems for python and stumbled across
Cheetah, the templatingsystem behind webware. This can easily be used
without webware, is a simple setup.py install and quite simple to use. And
it goes IMO nicely with the other toolkits we use, PyCS goes more for the
simple and small than for the big and bloated (we do use Metakit and not
some big database).
The homepage:
http://www.cheetahtemplate.org/
A quite good summary on cheetah and comparisons with other templating
systems (especially a reasoning why not ZPT):
http://www.cheetahtemplate.org/Py10.html
The users guide for using cheetah:
http://www.cheetahtemplate.org/docs/users_guide_html/
If somebody want's to install it into the pycs python:
# this is one line, press enter for the password
cd $HOME/src/cvs
-d:pserver:anonymous@cvs.cheetahtemplate.sourceforge.net:/cvsroot/cheetahtemplate
login
# this is one line
cvs
-d:pserver:anonymous@cvs.cheetahtemplate.sourceforge.net:/cvsroot/cheetahtemplate
co Cheetah
cd $HOME/src/Cheetah
$HOME/pycs/bin/python setup.py build
$HOME/pycs/bin/python setup.py install
I think it is quite nice, templates have useable template language with
the usual language constructs, although it doesn't follow the "everything
tags and attributes" line like ZPT or DTML or PSP. The benefit is, you can
use cheetah for every fileformat you want, even if it isn't some tagbased
format.
The usage of templates is quite simple (transliterated from the doc):
from Cheetah.Template import Template
templateDef = ("<html><head><title>$title</title></head>" +
"<body><h1>$title</h1>$body</body></html>")
class myTemplate(Template):
title = "test"
body = "test"
templ = myTemplate(templateDef)
print templ
templ.title = "test"
templ.body = "Another test"
print templ
This makes quite nice python code, and the template language isn't too
bad. So I would say "go for it", if there are no objections to this
package.
Comments?
bye, Georg
