> >[Georg just posted this to me, but I think it was probably meant for
> >the list.]
>
> Yeah. It's too late, brain disfunctioning ...
If I can find the list admin password, I'll go and set it so the
Reply-To header points to the list. Anyone here not like that?
> >some hackery might be necessary to get around that (we might need to
> >pickle unicode strings and put the results into the db rather than
> >just using normal strings, for example).
>
> Hmm. Or we just put them in as binary objects and make sure that every
> string we store is in unicode form? But both have the problem that the
> database isn't as easy accessible any more. Maybe just convert to latin1
> and store as latin1? This would break for people using languages outside
> latin1, though (and that's always a bad thing).
If we're going to convert everything to one format, I'd be happier
with unicode than latin-1. I'm thinking that I might need to post
Japanese text one day, and I don't think it encodes well in latin-1 :-)
> >I wonder if the XML generating code in Radio is in UserTalk ... in
>
> Isn't that the betty stuff?
That could be it. I haven't looked.
Cheers,
Phil :)
Hi!
> [Georg just posted this to me, but I think it was probably meant for
> the list.]
Yeah. It's too late, brain disfunctioning ...
> BTW, I think MetaKit stores everything as local ASCII, not unicode, so
> some hackery might be necessary to get around that (we might need to
> pickle unicode strings and put the results into the db rather than
> just using normal strings, for example).
Hmm. Or we just put them in as binary objects and make sure that every
string we store is in unicode form? But both have the problem that the
database isn't as easy accessible any more. Maybe just convert to latin1
and store as latin1? This would break for people using languages outside
latin1, though (and that's always a bad thing).
> You might find that Radio gets confused and puts unencoded high-ascii
> chars in the XML, which will probably piss off the XML parser in PyCS.
I know, that's exactly the discussion I have with Jake currently, Radio
doesn't give an encoding header in XML-RPC calls. :-/
> I wonder if the XML generating code in Radio is in UserTalk ... in
Isn't that the betty stuff?
bye, Georg
[Georg just posted this to me, but I think it was probably meant for
the list.]
Georg Bauer wrote:
> >For that matter, it might be a good idea to go through the code and
> >check out the use of unicode and local ascii. I haven't thought about
> >i18n when writing stuff, so I'm sure there are encoding problems all
> >over the place.
>
> Yes, there were some problems with POST data to modules (comment.py) - I
> have to investigate a bit more, but it looked like someone posted UTF-8
> data and that wasn't converted and shown directly. But I will see what
> comes out of that, because with german users this is bound to happen :-)
BTW, I think MetaKit stores everything as local ASCII, not unicode, so
some hackery might be necessary to get around that (we might need to
pickle unicode strings and put the results into the db rather than
just using normal strings, for example).
> >If you create a category with German chars in the name, will it
> >upstream and show up on the weblogUpdates page, btw? I seem to recall
>
> Hmm. I never tried, but I might try it sometime.
You might find that Radio gets confused and puts unencoded high-ascii
chars in the XML, which will probably piss off the XML parser in PyCS.
I wonder if the XML generating code in Radio is in UserTalk ... in
that case we could change <?xml version="1.0"?> to <?xml version="1.0"
encoding="iso-8859-1"?> [or whatever the local encoding is] and then
everything should work.
> >Sounds good. Note that I've already done this for comment *threads*,
> >but not for *users*. (i.e. there is an RSS feed for the comments on
> >post 100 for user 123, but there isn't an RSS feed to show you the
> >last 10 comments for user 123).
>
> Yep, that's what I talked about. Would be a nice bite sized task. Didn't
> I hear someone asking for that? ;-)
I seem to remember hearing that, yes ;-)
Cheers,
Phil
Georg:
> Places I like to see XML output (opml format would be nice, as one can
> handle that in Frontier) from:
>
> userdata
> directory structure (directory.opml as a starting point would be good)
... and once that second one is done, implementing
xmlStorageSystem.getMyDirectory will be trivial.
> >Next, something to go through and verify each of the dynamic pages
> >would be
> >cool. Post a comment, check that it shows up, then log in as the user
> >and
> >delete it, etc.
>
> I think those parts can be addressed when we have XML output. So we can
> easily compare output with expected output. And since it goes through
> the same output channel internally, one can test just the XML output and
> only check XHTML output on some parts, not on all (XHTML output is
> tedious to validate against expected results, as it might include local
> changes because of layout wishes, but XML should be always the same
> regardless of local layout).
True. Note that individual comment pages can be displayed as RSS if
you like, so that could be used to test that particular bit.
> >Hmm. Time for us to start using the SourceForge bug tracker, perhaps?
>
> Sure, I added already the dateTime stuff. Although I do keep track of
> ToDo on my instant outline, too.
Great. I wonder if I can get it to e-mail me with bugs, the way a
local bugzilla install seems to ...
> >Another suggestion, btw: create a desktop client to do something cool
> >with
> >the XML formats. You could probably whip up a weblogs.com /
> >weblogUpdates.py?format=xml client in C# or Python/wxPython in a couple
> >of
> >hours ... hmm ...
>
> As long as the API doesn't break as it is the case with my current
> undergoings with regard to combined metaWebLog/aggregator API client for
> Radio ;-)
Yeah!
For that matter, it might be a good idea to go through the code and
check out the use of unicode and local ascii. I haven't thought about
i18n when writing stuff, so I'm sure there are encoding problems all
over the place.
If you create a category with German chars in the name, will it
upstream and show up on the weblogUpdates page, btw? I seem to recall
having trouble with that a while back when I published a bzero weblog
in French to an RCS ... not sure what PyCS does.
> >Yet another suggestion: get /weblogUpdates.py (and
> >/modules/system/weblogUpdates.py) to accept pings with 'category' set to
> >'rss', so we can do a localised sort of 'weblogs.com for rss' on each
> >server
>
> Yep, that's another part I think we should strive to reach, much more
> internal infrastructure. Tasks should run on the local server, if the
> admin wishes to do so. Another part I think should be implemented on the
> local server is commentTracking with RSS output. Your implementation is
> cool, but I think it would be better if it ran in the community, so the
> feed could give out more information than it does now (for example give
> out the first N words of the comment, give out the blog's name where the
> comment was, etc.)
Sounds good. Note that I've already done this for comment *threads*,
but not for *users*. (i.e. there is an RSS feed for the comments on
post 100 for user 123, but there isn't an RSS feed to show you the
last 10 comments for user 123).
Cheers,
Phil :)
Hi!
> We need to think about making PyCS more developer-friendly. Out of pure
> laziness, I haven't gone out of my way to encourage others to help out
> so
> far, but it's something that should be done ;-)
Oh, I can't say anything bad about it, I have worked with far less
usefull code before. It's actually a quite nicely layed out source for
PyCS. Ok, there could be more documentatin, but in the end the only
reliable documentation is the source, so I don't care much for
standalone docs.
> Pick a version and implement that, and let people add more as they like.
> Add a 'format' argument to weblogUpdates.py:
I think one step should be done before: implement XML-writer
infrastructure so that modules can import a pycs_xmlWriter and use that
to create XML in a very easy way. After that adding XML output to any
part of the system should be easy. And another nice effect would be the
ability to use XHTML and so render output in just another format. I
think of the proposed format parameter to internally connect output data
with a template that's constructed out of XML, wether it being RSS, RDF,
OPML or XHTML. This would unify all output formats to one standard way
of doing it.
Places I like to see RSS output of:
weblogUpdates
rankings
referers
searches
Places I like to see XML output (opml format would be nice, as one can
handle that in Frontier) from:
userdata
directory structure (directory.opml as a starting point would be good)
> How about starting an overall test for the system?
Yep, people setting up test installations and using automated or
part-automated-part-manual testings on them would be nice, as
programmers tend to test around bugs ...
> Next, something to go through and verify each of the dynamic pages
> would be
> cool. Post a comment, check that it shows up, then log in as the user
> and
> delete it, etc.
I think those parts can be addressed when we have XML output. So we can
easily compare output with expected output. And since it goes through
the same output channel internally, one can test just the XML output and
only check XHTML output on some parts, not on all (XHTML output is
tedious to validate against expected results, as it might include local
changes because of layout wishes, but XML should be always the same
regardless of local layout).
> Hmm. Time for us to start using the SourceForge bug tracker, perhaps?
Sure, I added already the dateTime stuff. Although I do keep track of
ToDo on my instant outline, too.
> Another suggestion, btw: create a desktop client to do something cool
> with
> the XML formats. You could probably whip up a weblogs.com /
> weblogUpdates.py?format=xml client in C# or Python/wxPython in a couple
> of
> hours ... hmm ...
As long as the API doesn't break as it is the case with my current
undergoings with regard to combined metaWebLog/aggregator API client for
Radio ;-)
> Yet another suggestion: get /weblogUpdates.py (and
> /modules/system/weblogUpdates.py) to accept pings with 'category' set to
> 'rss', so we can do a localised sort of 'weblogs.com for rss' on each
> server
Yep, that's another part I think we should strive to reach, much more
internal infrastructure. Tasks should run on the local server, if the
admin wishes to do so. Another part I think should be implemented on the
local server is commentTracking with RSS output. Your implementation is
cool, but I think it would be better if it ran in the community, so the
feed could give out more information than it does now (for example give
out the first N words of the comment, give out the blog's name where the
comment was, etc.)
Lot of places to have lot of fun hacking at :-)
bye, Georg
Dean Goodmanson:
> When you spot a feature/task that could be
> accomplished in one "sitting" (1-2 hours), please post
> it so lurkers-like-me can cherry-pick some meaningful
> contribution.
Good idea!
We need to think about making PyCS more developer-friendly. Out of pure
laziness, I haven't gone out of my way to encourage others to help out so
far, but it's something that should be done ;-)
> For example:
>
> * Recently Updated in XML format. (RSS, RDF, which
> version?)
Pick a version and implement that, and let people add more as they like.
Add a 'format' argument to weblogUpdates.py:
http://foo/system/weblogUpdates.py?format=xml
http://foo/system/weblogUpdates.py?format=rss2
http://foo/system/weblogUpdates.py?format=rss1
'xml' should return the weblogs.com format (see www.weblogs.com/changes.xml
for an example). The others are up to you ...
> * Specific Unit Tests: Module/Function, Type of Test.
How about starting an overall test for the system?
The first step would be a unit test that:
- uses the xmlStorageSystem API to register a blog on the server
- posts a file to it
- downloads that via HTTP to make sure it posted OK
- deletes it off the server
- verifies that it now returns a 404 error
Once that's done, the next step would be something that:
- sends a weblogs.com ping to the server
- downloads weblogUpdates.py?format=xml (once that's implemented!) and
verifies that the blog now shows up
Next, something to go through and verify each of the dynamic pages would be
cool. Post a comment, check that it shows up, then log in as the user and
delete it, etc.
> A more detailed description and example can be found
> here: http://subversion.tigris.org/project_tasks.html
> (Thanks to PieterB at ZWiki for the link)
Hmm. Time for us to start using the SourceForge bug tracker, perhaps?
Another suggestion, btw: create a desktop client to do something cool with
the XML formats. You could probably whip up a weblogs.com /
weblogUpdates.py?format=xml client in C# or Python/wxPython in a couple of
hours ... hmm ...
Yet another suggestion: get /weblogUpdates.py (and
/modules/system/weblogUpdates.py) to accept pings with 'category' set to
'rss', so we can do a localised sort of 'weblogs.com for rss' on each server
...
Cheers,
Phil
To the folks in the thick of it:
When you spot a feature/task that could be
accomplished in one "sitting" (1-2 hours), please post
it so lurkers-like-me can cherry-pick some meaningful
contribution.
For example:
* Recently Updated in XML format. (RSS, RDF, which
version?)
* Specific Unit Tests: Module/Function, Type of Test.
A more detailed description and example can be found
here: http://subversion.tigris.org/project_tasks.html
(Thanks to PieterB at ZWiki for the link)
My 2 cents...
- Dean
