pycs-devel Mailing List for Python Community Server (Page 19)
Status: Alpha
Brought to you by:
myelin
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(3) |
Oct
(1) |
Nov
(70) |
Dec
(41) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(20) |
Feb
(9) |
Mar
(36) |
Apr
(11) |
May
(3) |
Jun
(6) |
Jul
(3) |
Aug
(13) |
Sep
(2) |
Oct
(32) |
Nov
(4) |
Dec
(7) |
| 2004 |
Jan
(14) |
Feb
(16) |
Mar
(3) |
Apr
(12) |
May
(1) |
Jun
(4) |
Jul
(13) |
Aug
(1) |
Sep
(2) |
Oct
(1) |
Nov
(2) |
Dec
(3) |
| 2005 |
Jan
(7) |
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
(2) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(7) |
Nov
(18) |
Dec
(22) |
| 2007 |
Jan
(10) |
Feb
(11) |
Mar
(1) |
Apr
(6) |
May
(5) |
Jun
(5) |
Jul
(14) |
Aug
(28) |
Sep
(4) |
Oct
(6) |
Nov
(9) |
Dec
(8) |
| 2008 |
Jan
(10) |
Feb
(19) |
Mar
(38) |
Apr
(17) |
May
(13) |
Jun
(7) |
Jul
(36) |
Aug
(15) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
|
From: Georg B. <gb...@mu...> - 2002-12-13 12:04:54
|
Hi! > How about using it to make whatever you're planning at the moment (admin > pages?) but leaving the existing pages as they are for the moment? That > way we can see what it's like to use, and (if necessary) back out / > switch to another system. The problem is, my first idea is to template the existing pages in the system modules to become able to switch everything to a real layout from the rather crude stuff I use now :-) Admin pages are something that needs to be done, but they are even more something I have to think about first, to get them right. bye, Georg |
|
From: Phillip P. <ph...@my...> - 2002-12-13 11:46:13
|
Georg: > Does the non-existence of replies say you all don't care, you all object > or you all agree? :-) > > I really would like to get some feedback, because using Cheetah would add > to the prerequisites of PyCS. So even if you don't care, please just say > that you don't care, so I know about it. I had a look, and it seems fine to me. Sorry; I thought I'd already replied :-) How about using it to make whatever you're planning at the moment (admin pages?) but leaving the existing pages as they are for the moment? That way we can see what it's like to use, and (if necessary) back out / switch to another system. What were you thinking of doing first? Cheers, Phil |
|
From: Georg B. <gb...@mu...> - 2002-12-13 10:30:31
|
Hi! > I again looked at templating systems for python and stumbled across > Cheetah, the templatingsystem behind webware. This can easily be used ... > http://www.cheetahtemplate.org/ Does the non-existence of replies say you all don't care, you all object or you all agree? :-) I really would like to get some feedback, because using Cheetah would add to the prerequisites of PyCS. So even if you don't care, please just say that you don't care, so I know about it. bye, Georg |
|
From: Phillip P. <ph...@my...> - 2002-12-11 09:39:42
|
> 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 :) |
|
From: Phillip P. <ph...@my...> - 2002-12-11 09:28:09
|
> 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 |
|
From: Georg B. <gb...@mu...> - 2002-12-11 08:40:56
|
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 |
|
From: Georg B. <gb...@mu...> - 2002-12-11 05:15:47
|
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 |
|
From: Georg B. <gb...@mu...> - 2002-12-10 22:29:09
|
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 |
|
From: Phillip P. <pp...@my...> - 2002-12-10 22:10:35
|
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 :) |
|
From: Phillip P. <pp...@my...> - 2002-12-10 21:46:11
|
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: Georg B. <gb...@mu...> - 2002-12-10 20:37:00
|
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 |
|
From: Georg B. <gb...@mu...> - 2002-12-10 18:15:05
|
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 |
|
From: Georg B. <gb...@mu...> - 2002-12-10 12:15:50
|
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:ano...@cv...:/cvsroot/cheetahtemplate login # this is one line cvs -d:pserver:ano...@cv...:/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 |
|
From: Georg B. <gb...@mu...> - 2002-12-09 22:08:25
|
Hi! > Hmm ... now to write the web interface ;-) Not before we have a decent templating system ;-) bye, Georg |
|
From: Phillip P. <pp...@my...> - 2002-12-09 20:52:42
|
On Mon, Dec 09, 2002 at 12:52:17PM +0100, Georg Bauer wrote: > I just checked in the ability to add aliases to user records in the > database and to automatically generate corresponding rewrite rules. > Added are some commands to pycsadm as follows: > [...] > > This is in preparation for web-based configuration interfaces and maybe > someday user-defined aliasing. Most of the actual code is in > pycs_settings.py. pycsAdmin.py and pycs.py just use the code that's in > pycs_settings.py. A little change was needed for pycs_rewrite_handler.py > to enable reloading the rewrite rules after changing something in the > database without the need to reload the whole config. Great job! Hmm ... now to write the web interface ;-) Cheers, Phil |
|
From: Georg B. <gb...@mu...> - 2002-12-09 12:01:42
|
Hi! Just to answer a question that might come up: why not drop the pycs.conf and rewrite.conf based aliases? Simple: the in-database aliases can only work with a standard name scheme, either http://server.doma.in/alias or http://alias.server.doma.in - but if you for example want to set up user-owned domains, you have to add pycs.conf based aliases, as those can't be deduced from the database (and since user-owned domains will always require several actions by admins, it's of no use to pull them into the database, too). So with pycs.conf and rewrite.conf you can set up for example http://xgwskba.de/ to point to http://muensterland.org/users/0000004, with just one entry in pycs.conf and one (or two) rewrite rules in rewrite.conf. bye, Georg |
|
From: Phillip P. <ph...@my...> - 2002-12-09 11:57:01
|
> I just saw that somebody (Phil I assume) added some more attributes to
> the community stuff in xmlStorageSystem. But shouldn't the
> "discussionGroupUrl" and the "mailListUrl" point to pycs related groups
> and lists? They now point to Radio Userland. Hmm.
>
> And could we make the community name a configuration option - or must
> that be the product name of the community server? I don't know how those
> attributes are used outside, that's why I ask.
Ah, yes. I put those in as placeholders after finding out that Radio was
failing miserably when pinging the community server when the 'community'
struct was set in the xmlStorageSystem.ping() response but various
attributes ('title', etc) weren't.
The community name shouldn't be 'Python Community Server', and it would be
fine to point the discussion and mailing list URLs over here. Feel free to
change them (put them in pycs.conf).
Cheers,
Phil :)
|
|
From: Georg B. <gb...@mu...> - 2002-12-09 11:56:35
|
Hi! I just checked in the ability to add aliases to user records in the database and to automatically generate corresponding rewrite rules. Added are some commands to pycsadm as follows: pycsadm.py alias simple 0000004 xgwskba - this sets a new alias in the http://muensterland.org/xgwskba format pycsadm.py alias manila 0000004 xgwskba - this sets a new alias in the http://xgwskba.muensterland.org format The corresponding rewrite rules (both the redirect when entering the old usernumber format and the rewrite from the alias to the usernumber format) are generated automatically. What is not generated is the manila style rewrite, as that is only one rule in the rewrite.conf (the other two rules are generated for every alias). pycsadm.py alias del 0000004 - this deletes the alias and the corresponding rewrite rules pycsadm.py list aliases - this lists all in-database aliases (not aliases from the pycs.conf!) pycsadm.py list rewrites - this lists all defined rewrite rules (only the descriptional string, both in-database and pycs.conf!) Both pycs.conf/rewrite.conf and in-database aliases continue to work together - actually my muensterland.org currently has two .conf-aliases and one in-database alias. So if you don't use the feature, as always, nothing changes for you (hopefully). This is in preparation for web-based configuration interfaces and maybe someday user-defined aliasing. Most of the actual code is in pycs_settings.py. pycsAdmin.py and pycs.py just use the code that's in pycs_settings.py. A little change was needed for pycs_rewrite_handler.py to enable reloading the rewrite rules after changing something in the database without the need to reload the whole config. bye, Georg |
|
From: Georg B. <gb...@mu...> - 2002-12-09 09:12:47
|
Hi! Another question: the flHasSearch and urlSearch currently are set to false and ''. What would be needed to implement it - I think a module in system, setting up the URL, but what should be searched? All users, or only the user where the search is called? An "all users search" can be done with google, with a link restriction to the domain of the community server. So maybe we actually don't need to implement anything but just point over to google? bye, Georg |
|
From: Georg B. <gb...@mu...> - 2002-12-09 09:09:59
|
Hi! I just saw that somebody (Phil I assume) added some more attributes to the community stuff in xmlStorageSystem. But shouldn't the "discussionGroupUrl" and the "mailListUrl" point to pycs related groups and lists? They now point to Radio Userland. Hmm. And could we make the community name a configuration option - or must that be the product name of the community server? I don't know how those attributes are used outside, that's why I ask. bye, Georg |
|
From: Dean G. <goo...@ya...> - 2002-11-28 05:02:11
|
Thanks for the details, the blog will appreciate it. I've used the comment management. Very nice. > The new extension lets a sysop do the same thing for > all blogs ... In specific, I was trying to point +1 the feature. Feel free, as Sysop of PyCS, to bit-bucket any comments you see on my site that are as I described. The whole google locale issues was absense of rtfs (and other things ;O) on my part. - Dean __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Phillip P. <pp...@my...> - 2002-11-27 21:27:36
|
> Good point. > > Personally, I like the thought of a Sysop blasting > rogue comments on my blog: Spam, Double click dual > posts, horrendously innapropriate, etc. BTW, you can do that too. It's not documented, but if you visit the following url: http://www.pycs.net/system/login.py ... and log in with the e-mail address and password you gave Radio when you created the blog, then go back to a comment page on your blog, you should see a 'Delete' button under each comment. The new extension lets a sysop do the same thing for all blogs ... > p.s. All of the Google referrer links on pycs.net > point to google.de ;-) At first I thought I was > actually getting hits from Germany searches, but later > remembered the implementation context. Phil, would > you mind switching PyCS over to google.com ? Might > need to check with Martin Gerber, though...I can live > with it if it's handy to him. Killer feature, btw. > Next week I'll post some referrers for AllTheWeb.com > and Vivisimo.com for analysis. Martin's already answered this one, but I think you really are getting search hits from Germans ;-) The search tracking page just looks for referrers with 'google' (and various other things) in them. Check out pycs.net/sqr/referrers.html for a really detailed analysis of your hits. Cheers, Phil :) |
|
From: Georg B. <gb...@mu...> - 2002-11-27 16:34:52
|
Hi! > Oh, I just checked in a little patch to searches.py so that it now > recognizes altavista searches. I actually didn't get any up to now, but > Phil does, and so I thought it would be nice if they showed up in the > list, too :-) And MSN, too (as I got some from there). bye, Georg |
|
From: Georg B. <gb...@mu...> - 2002-11-27 16:11:04
|
Hi! > p.s. All of the Google referrer links on pycs.net > point to google.de ;-) At first I thought I was > actually getting hits from Germany searches, but later > remembered the implementation context. Phil, would Hmm? I don't think we have something in there that points explicitly to google.de - it just takes the referrer from the http headers, that's all. I just did a grep -r -i google.de on the source-tree and didn't find any hardcoded google.de stuff (it might have happend, as I usually would insert google.de automatically if I was to hardcode something like that, just out of habit). I would say that you actually _do_ get hits by german (or german IP range) searches :-) Google does a bit of trickery: when your IP falls into some ranges, it forcebly switches you over to google.de because of the censorship stuff they implemented there (yes, we in germany get censored with google search results!), so maybe you are bitten by this, as google seems to switch a bit more IPs than is actually needed. Or it just happens that I searched a _lot_ of stuff lately and that I often stumbled over pycs.net and so it's just me ... Oh, I just checked in a little patch to searches.py so that it now recognizes altavista searches. I actually didn't get any up to now, but Phil does, and so I thought it would be nice if they showed up in the list, too :-) bye, Georg |
|
From: Dean G. <goo...@ya...> - 2002-11-27 14:58:04
|
> Actually that would go nicely with my "BBS" theme, > as we used to have > several "sysops" to run the system. More finegrained > control often isn't > really needed - I see that every time with Zope, you > very seldom use the > full power of the authencation and rights mechanism, > usually the > "user <-> manager" type of distinction is more than > enough. > Good point. Personally, I like the thought of a Sysop blasting rogue comments on my blog: Spam, Double click dual posts, horrendously innapropriate, etc. - Dean p.s. All of the Google referrer links on pycs.net point to google.de ;-) At first I thought I was actually getting hits from Germany searches, but later remembered the implementation context. Phil, would you mind switching PyCS over to google.com ? Might need to check with Martin Gerber, though...I can live with it if it's handy to him. Killer feature, btw. Next week I'll post some referrers for AllTheWeb.com and Vivisimo.com for analysis. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |