Menu
▾
▴
pyblosxom-devel
|
From: 'Wari W. <wa...@ce...> - 2003-02-05 02:26:58
|
BTW, I cc to pyblosxom-devel as this topic spawns of to something that devel list might me interested in. * Blake Winton <bl...@ph...> [030204 22:57]: > So, have you gotten any bug reports recently? Being a python software (unlike perl blosxom) I don't have that much users giving me bug reports, if they have, they included a patch for it (interesting indeed). > Are you using any of the SourceForge features, other than the mailing > lists? Tried to but with miniscule user base, I don't see sf.net to be a main focal point of activity. > I notice that they have a place for bug tracking and another for > documentation. The documentation thingy is not as good as a wiki I guess, that's why I have a wiki site for documentation. Anyone who feels that the docs is lacking can always contribute if they need to. > If anyone is submitting bugs, I'd love to help track them down and > fix them. (Of course, if no-one is submitting bugs, good job! ;) Bugs, what bugs? pyblosxom is 1000% bug free :) NOT. hehe. There is one or two lying about. 1. Entry files that starts with a digit will fail to get picked up by pyblosxom when using a single entry link: See: http://roughingit.subtlehints.net/pyblosxom/2003/Jan/31#1044019277 http://roughingit.subtlehints.net/pyblosxom/development/1044019277.html The second url borks. This bug requires some modification (or even refactoring) of libs.Pyblosxom.startup() or could even be done better with a urlhandler() thingy, which is not available yet. Which is why I didn't fix this before releasing 0.6 2. Proper url handler to handle things queries like 2003/Jan/index.html or /development/index.html I think the main point of this is that handling or URLs must be fixed or pluggable so that we can do sane URL handlings or handle other stuff like comments or searches, etc.. -- Regards: Wari Wahab Senior R&D Engineer Celestix Networks http://www.celestix.com/ |
|
From: will <wi...@bl...> - 2003-02-05 04:18:07
|
I've had lots of experience with SourceForge over the last 3 years and I really hate their documentation manager and forums system. Tracking bugs and features sucks unless you have a really small amount of them. Now granted it's free so it's lame to complain much. I once wasn't a fan of the wiki, but after playing with it this last weekend I agree with Wari that it's a decent system for our documentation. It just needs some more content. :) In terms of the url handler, I can jerry rig that pretty quickly (1 hour) based on what Blake wrote for the /plugin-info thing if anyone is interested. Essentially it'd involve creating a url_handler callback chain which gets called at the beginning with the url and environment data. Then the first registered function that can handle the url in the chain handles it and the chain stops. Blake mentioned in a previous email a bunch of issues with this namely what happens when two things want to handle the same url. I think to that I would say we're designing a pretty small system here and while that's something to think about for functional completeness, I don't think it's an issue we really care about (I know I don't care :) ). If a plugin writer has this problem, then they can always register themselves with the callback chain with a higher priority and thus pre-empt other handling function. I think when a function handles the url, it's building the whole page and that's the end of our run. I can't think of a use case where we'd want two different functions to handle the url and do different things. I vaguely remember there being other issues, but I can't remember what they were. /will On Wed, 5 Feb 2003, 'Wari Wahab' wrote: > > BTW, I cc to pyblosxom-devel as this topic spawns of to something that > devel list might me interested in. > > * Blake Winton <bl...@ph...> [030204 22:57]: > > So, have you gotten any bug reports recently? > > Being a python software (unlike perl blosxom) I don't have that much > users giving me bug reports, if they have, they included a patch for it > (interesting indeed). > > > Are you using any of the SourceForge features, other than the mailing > > lists? > > Tried to but with miniscule user base, I don't see sf.net to be a main > focal point of activity. > > > I notice that they have a place for bug tracking and another for > > documentation. > > The documentation thingy is not as good as a wiki I guess, that's why I > have a wiki site for documentation. Anyone who feels that the docs is > lacking can always contribute if they need to. > > > If anyone is submitting bugs, I'd love to help track them down and > > fix them. (Of course, if no-one is submitting bugs, good job! ;) > > Bugs, what bugs? pyblosxom is 1000% bug free :) NOT. hehe. There is one > or two lying about. > > 1. Entry files that starts with a digit will fail to get picked up by > pyblosxom when using a single entry link: > See: > http://roughingit.subtlehints.net/pyblosxom/2003/Jan/31#1044019277 > http://roughingit.subtlehints.net/pyblosxom/development/1044019277.html > > The second url borks. This bug requires some modification (or even > refactoring) of libs.Pyblosxom.startup() or could even be done better > with a urlhandler() thingy, which is not available yet. Which is why > I didn't fix this before releasing 0.6 > > 2. Proper url handler to handle things queries like 2003/Jan/index.html > or /development/index.html > > I think the main point of this is that handling or URLs must be fixed or > pluggable so that we can do sane URL handlings or handle other stuff > like comments or searches, etc.. -- whatever it is, you can find it at http://www.bluesock.org/~willg/ except Will--you can only see him in real life. |
|
From: 'Wari W. <wa...@ce...> - 2003-02-05 08:59:39
|
* will <wi...@bl...> [030205 13:16]: > I've had lots of experience with SourceForge over the last 3 years and > I really hate their documentation manager and forums system. Tracking > bugs and features sucks unless you have a really small amount of them. > Now granted it's free so it's lame to complain much. Any idea how to remove some of those services, like forums and documentation manager from my sourceforge page? > I once wasn't a fan of the wiki, but after playing with it this last > weekend I agree with Wari that it's a decent system for our > documentation. It just needs some more content. :) I know the documentation isn't great, and I'm extremely jealous of Rael's documentation :) But I can't just copy and paste from his site :) Most of his documentation do apply for pyblosxom as well. > In terms of the url handler, I can jerry rig that pretty quickly (1 > hour) based on what Blake wrote for the /plugin-info thing if anyone > is interested. Essentially it'd involve creating a url_handler > callback chain which gets called at the beginning with the url and > environment data. Then the first registered function that can handle > the url in the chain handles it and the chain stops. Then you need to change some of the code in startup() and run(), maybe combine some of the URL discovery, and each url_handler either returns an entryList or do something and stop there (You may want head.html and foot.html templates to run). So this is not a hack, more thoughts have to be thunked before doing something big like this. > Blake mentioned in a previous email a bunch of issues with this namely > what happens when two things want to handle the same url. I think to > that I would say we're designing a pretty small system here and while > that's something to think about for functional completeness, I don't > think it's an issue we really care about (I know I don't care :) ). > If a plugin writer has this problem, then they can always register > themselves with the callback chain with a higher priority and thus > pre-empt other handling function. I can possibly classify some types of URL that url_handler would want to process. 1. Category, directories of your blosxom blogs 2. Permanent entry links 3. Year, month, date. These are standard blosxom stuff 4. ?q= for queries 5. ?flav= for flavours 6. ?q=xxx&flav=xxx both 7. /plugin-info or whatever plugins that 'hijacks' item 1 and 2 8. Some form of comments or feedbacks. 9. All of the above are GET data, what about POST? PUT or DELETE? 10. 1 2 3 7 8 should usually work together with 5 Of course a default handler could do what pyblosxom is handling now, which is 1 2 3 5. Not that easy I think, or there could be several handlers for such things that worked in order. * Handler for entries (Entries and or feedback outputs) * Handler for events (feedback inputs, search queries) * Handler for special plugins like /plugin_info * Handler for actions (redirect after feedback inputs?) > I think when a function handles the url, it's building the whole page > and that's the end of our run. I can't think of a use case where we'd > want two different functions to handle the url and do different > things. Thought of already, above :) > I vaguely remember there being other issues, but I can't remember what > they were. Not issues, just proper implementation needed. -- Regards: Wari Wahab Senior R&D Engineer Celestix Networks http://www.celestix.com/ |
|
From: Blake W. <bl...@ph...> - 2003-02-05 13:27:26
|
> I think when a function handles the url, it's building the > whole page and that's the end of our run. I can't think of > a use case where we'd want two different functions to handle > the url and do different things. No? How about moving logstats.py to the url handler as well? It would log the url and referrer, and then pass it off to the actual page handler (which would then call it to stuff the referrer information into the py dict. As long as the urlHandlers return true to indicate we should stop processing, and false to indicate we should continue, there should be no problems with these sorts of scenarios. Later, Blake. |
|
From: will <wi...@bl...> - 2003-02-05 15:00:41
|
On Wed, 5 Feb 2003, Blake Winton wrote:
>
> > I think when a function handles the url, it's building the whole page
> > and that's the end of our run. I can't think of a use case where we'd
> > want two different functions to handle the url and do different
> > things.
>
> No? How about moving logstats.py to the url handler as well? It would
> log the url and referrer, and then pass it off to the actual page
> handler (which would then call it to stuff the referrer information into
> the py dict.
That's not a handler. That would be event notification. I think the
issue here is less that what I'm planning on doing is problematic and
doesn't solve our existing use cases and more that we're not using the
same vocabulary the same way.
Maybe handler is the wrong word, but if you look in api.py, the
documentation for executeHandler is:
Each function tries to see if it can handle the data being
passed in as input. If it can handle the data, then it does
so and returns api.HANDLED. We continue through the list of
registered functions until we hit the end (none of them
handled it) or one of the functions has handled the data
and we don't need to proceed further.
We could toss logstats.py in the the url handler chain and it'd work as
you've suggested. But it should be noted that it's not handling the
url--it's using the executeHandler mechanism as event notification.
That's fine, but that's not really what I was asking for. I'll try to put
it another way. My issue is are there any use cases where we want to have
two functions that generate an entire page from the same url?
It's interesting to note that the executeHandler chain can't modify the
url. I don't know if we want to have a transformation process in here
too. So then functions can modify the url they get passed based on
whatever it is that they do.
Going to what Wari was saying, I really think that the mechanism for
taking an entrylist, parsing/formatting it, and wrapping it in head/foot
templates should be a mechanism that's available to all url handlers so
that the ones that want to build a page like we have now (url handling for
dates, specific entries, categories, ...) can do so without too many
issues and ones that have almost nothing to do with our existing layout
(head, story/story/story/story, foot) can do as they like (this could be a
way to implement a MoinMoin plugin).
It would probably take an entry list and a py dict. We might even have it
now, but I think it's in pyblosxom.py.
I don't think that the querystring should get parsed by separate url
handlers. Though maybe we should do that and it can modify the py dict
(assuming we make it global). I think that's more trouble than it's worth
though. I think we're better off letting url handlers work at a higher
scope and then they can use functions in tools.py (some of which we'll
have to extract from pyblosxom.py) to do the actual work based on
querystring attributes.
Anyhow, I don't see any showstopper issues yet. What I'm planning on
doing handles everything that's been mentioned so far. The basic
implementation steps would be:
1. break out the page generation code into a tools function
2. create a url_handler callback chain in api.py
3. change the run method so that it calls the url handler
4. build a function for handling all the urls we handle now
that generate entry lists and generate a page
5. add a function for generating /plugin-info
Step 5 will be really primitive at the moment and only really exists so
that we can have two different url handling functions in the callback
chain. Blake can fill in the rest with the code he's written.
Any other thoughts/issues/concerns?
/will
|
|
From: will <wi...@bl...> - 2003-02-05 15:08:27
|
Just for the record, I don't mean to imply that this conversation is stupid in any way. The more use cases that we can come up with, the more confident we'll be that the new mechanisms handle it and future ideas. So it's all good. One possibility is that I could create a will branch or something like that and experiment with things there. Then you guys can adopt the pieces you're interested in adopting and we can discuss the pieces that need discussing without it affecting the repository. I should warn you, though, that I've never played with branches in CVS. But I have in other version control systems, so I can't imagine that it's that hard. CVS has branches right? Any thoughts on that? /will On Wed, 5 Feb 2003, will wrote: > On Wed, 5 Feb 2003, Blake Winton wrote: > > > > > I think when a function handles the url, it's building the whole page > > > and that's the end of our run. I can't think of a use case where we'd > > > want two different functions to handle the url and do different > > > things. > > > > No? How about moving logstats.py to the url handler as well? It would > > log the url and referrer, and then pass it off to the actual page > > handler (which would then call it to stuff the referrer information into > > the py dict. > > That's not a handler. That would be event notification. I think the > issue here is less that what I'm planning on doing is problematic and > doesn't solve our existing use cases and more that we're not using the > same vocabulary the same way. > > Maybe handler is the wrong word, but if you look in api.py, the > documentation for executeHandler is: > > Each function tries to see if it can handle the data being > passed in as input. If it can handle the data, then it does > so and returns api.HANDLED. We continue through the list of > registered functions until we hit the end (none of them > handled it) or one of the functions has handled the data > and we don't need to proceed further. > > > We could toss logstats.py in the the url handler chain and it'd work as > you've suggested. But it should be noted that it's not handling the > url--it's using the executeHandler mechanism as event notification. > That's fine, but that's not really what I was asking for. I'll try to put > it another way. My issue is are there any use cases where we want to have > two functions that generate an entire page from the same url? > > It's interesting to note that the executeHandler chain can't modify the > url. I don't know if we want to have a transformation process in here > too. So then functions can modify the url they get passed based on > whatever it is that they do. > > Going to what Wari was saying, I really think that the mechanism for > taking an entrylist, parsing/formatting it, and wrapping it in head/foot > templates should be a mechanism that's available to all url handlers so > that the ones that want to build a page like we have now (url handling for > dates, specific entries, categories, ...) can do so without too many > issues and ones that have almost nothing to do with our existing layout > (head, story/story/story/story, foot) can do as they like (this could be a > way to implement a MoinMoin plugin). > > It would probably take an entry list and a py dict. We might even have it > now, but I think it's in pyblosxom.py. > > I don't think that the querystring should get parsed by separate url > handlers. Though maybe we should do that and it can modify the py dict > (assuming we make it global). I think that's more trouble than it's worth > though. I think we're better off letting url handlers work at a higher > scope and then they can use functions in tools.py (some of which we'll > have to extract from pyblosxom.py) to do the actual work based on > querystring attributes. > > Anyhow, I don't see any showstopper issues yet. What I'm planning on > doing handles everything that's been mentioned so far. The basic > implementation steps would be: > > 1. break out the page generation code into a tools function > 2. create a url_handler callback chain in api.py > 3. change the run method so that it calls the url handler > 4. build a function for handling all the urls we handle now > that generate entry lists and generate a page > 5. add a function for generating /plugin-info > > > Step 5 will be really primitive at the moment and only really exists so > that we can have two different url handling functions in the callback > chain. Blake can fill in the rest with the code he's written. > > Any other thoughts/issues/concerns? > > /will > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Pyblosxom-devel mailing list > Pyb...@li... > https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel > -- whatever it is, you can find it at http://www.bluesock.org/~willg/ except Will--you can only see him in real life. |
|
From: Blake W. <bl...@ph...> - 2003-02-05 16:22:16
|
> We could toss logstats.py in the the url handler chain and > it'd work as you've suggested. But it should be noted that > it's not handling the url--it's using the executeHandler > mechanism as event notification. That's fine, but that's > not really what I was asking for. I'll try to put it > another way. My issue is are there any use cases where we > want to have two functions that generate an entire page from > the same url? Okay, I see the difference. Hmmm... If you insist on having the word "entire" in there, then I can't imagine how we would want two functions to be called, both handling the same url. If you modify your last sentence to read: > My issue is are there any use cases where we want to have > two functions that generate parts of a page from the same > url? Then I would suggest that the comment plugin could only display the comments, and leave the displaying of the actual body of a post to the default pageview plugin. We could have the comment plugin call the base template stuff, but if there's already a plugin that does that, why not just have it run first, and append our stuff on the end? > It's interesting to note that the executeHandler chain > can't modify the url. I don't know if we want to have > a transformation process in here too. So then functions > can modify the url they get passed based on whatever it > is that they do. I'ld like it, but more in a geeky sort of way than in a I-can-think-of-a-use-for-it sort of way. At best it would be like a poor-man's redirect. The executeHandler chain can change the flavour, can't they? > Going to what Wari was saying, I really think that the > mechanism for taking an entrylist, parsing/formatting it, > and wrapping it in head/foot templates should be a mechanism > that's available to all url handlers > > It would probably take an entry list and a py dict. We might > even have it now, but I think it's in pyblosxom.py. Could we make it a well-defined plugin with a method that other bits of code could use? > to do the actual work based on querystring attributes. And some other pieces of data, like REQUEST_METHOD. > 1. break out the page generation code into a tools function [snip...] > 4. build a function for handling all the urls we handle now > that generate entry lists and generate a page Wouldn't this just call the tools function? > Any other thoughts/issues/concerns? Sounds okay to me... And now the next reply. > Just for the record, I don't mean to imply that this conversation > is stupid in any way. The more use cases that we can come up > with, the more confident we'll be that the new mechanisms handle > it and future ideas. So it's all good. Yeah, I figured that. > One possibility is that I could create a will branch or something > like that and experiment with things there. Then you guys can > adopt the pieces you're interested in adopting and we can discuss > the pieces that need discussing without it affecting the repository. Sounds like a good idea, but branches kind of scare me. I never know which branch I should work off of, and it doubles the amount of stuff I have to look through. I think I'ld come down on the get it working in a simple form on your local box, and then check it in to the main branch, and we can discuss it when we all see it running. If it's something that we really think we're not going to use, then why spend time on it. If it's something that we will want to merge in to the base, then why not stick it there to begin with? > I should warn you, though, that I've never played with branches in > CVS. But I have in other version control systems, so I can't > imagine that it's that hard. CVS has branches right? Yup. Later, Blake. |
|
From: will <wi...@bl...> - 2003-02-05 16:52:26
|
On Wed, 5 Feb 2003, Blake Winton wrote:
>
> If you modify your last sentence to read:
>
> > My issue is are there any use cases where we want to have
> > two functions that generate parts of a page from the same
> > url?
>
> Then I would suggest that the comment plugin could only display
> the comments, and leave the displaying of the actual body of
> a post to the default pageview plugin. We could have the comment
> plugin call the base template stuff, but if there's already a
> plugin that does that, why not just have it run first, and
> append our stuff on the end?
Mmm... I'm thinking that the url handling functions are mostly there to
assemble things--I don't think they should be doing lots of stuff on their
own. They would examine the url (and it's interesting that you brought up
REQUEST_METHOD because that's not part of the url and I hadn't factored
that in--so I may have to backpedal on some of my thoughts at some point)
and handle it according to what they do where "handle" would mostly
involve calling functions in tools.py to do most of the work. The thing
that the url handler does is figures out what the data to work on would
be. Is this a url for looking at a specific category of entries? Is this
a url for looking at a date of entries? Is this url for posting a
comment? Is this a url for viewing plugin information? ...
[As a side point, it's unclear as to whether we should take our existing
functionality and split it into a series of handlers (one for categories,
one for entries, and one for dates) or not. I vote yes but we can do that
refactoring later.]
So then I'd take the existing handling of urls and dump it into a function
that would:
1. examine the url
2. figure out which entries need to be displayed
3. call the tools.py function that takes an entrylist and a py dict
and generates story portion of the page
4. call the tools.py function to wrap the story portion of the page
in a head/foot set
Steps 3 and 4 involve functions that don't exist yet in tools.py, but the
code is in pyblosxom.py.
Wari and I were talking about how to handle comments a while back and he's
thinking it's essentially another entrylist. So then comment viewing (and
possibly posting) would be entry oriented and could use the same
mechanisms described above.
I'm not seeing these url handling functions as being all that long. I
would think it'd take a few lines to figure out whether it's going to
handle the url or not, then maybe 10 to 20 lines to call all the functions
in tools.py to actually generate the page.
It's interesting to note that we could adjust your plugin-info module so
that it just generates its own story portion and then calls the tools.py
function to wrap it into a head/foot block.
Incidentally, that might require some adjustments to some of the plugins
we currently have. I know the pycalendar one looks at entrylist data for
initialization.
> > It's interesting to note that the executeHandler chain
> > can't modify the url. I don't know if we want to have
> > a transformation process in here too. So then functions
> > can modify the url they get passed based on whatever it
> > is that they do.
>
> I'ld like it, but more in a geeky sort of way than in a
> I-can-think-of-a-use-for-it sort of way. At best it would
> be like a poor-man's redirect.
>
> The executeHandler chain can change the flavour, can't they?
If the flavour is part of the url, then yes, it could.
Ok. If we implement it as a transform, then the rules change a bit. A
url handling function could:
1. not do anything and just return the unadjusted url
2. adjust the url and return the adjusted url
3. handle the url and return some value that indicates that the
url has been handled
In executeTransform, there's no "stop processing" kind of thing--so we
pass the data through all of the registered functions. We would need
something to indicate to the function that the url has been handled, so if
it's going to do page generation kind of handling, it shouldn't bother.
> > Going to what Wari was saying, I really think that the mechanism for
> > taking an entrylist, parsing/formatting it, and wrapping it in
> > head/foot templates should be a mechanism that's available to all url
> > handlers
> >
> > It would probably take an entry list and a py dict. We might even
> > have it now, but I think it's in pyblosxom.py.
>
> Could we make it a well-defined plugin with a method that other bits of
> code could use?
Why should it be a plugin? I was thinking these sorts of general
functions would be in tools.py and available to everyone. The nature of
plugins is that they may or may not be installed and therefore may or may
not be available.
> > to do the actual work based on querystring attributes.
>
> And some other pieces of data, like REQUEST_METHOD.
Hmmm... I'm going to have to toss this around. I'm wondering if we
should build a HTTP request object of some sort and pass that around
instead. That changes this whole discussion from a "url handler" to a
"http request handler". Mmm... That actually makes more sense to do.
Though that might be overkill--those variables are already available in
the os.environ dict which everything can see.
> > 1. break out the page generation code into a tools function
> [snip...]
> > 4. build a function for handling all the urls we handle now
> > that generate entry lists and generate a page
>
> Wouldn't this just call the tools function?
Yes. But the function doesn't exist yet. I think it's part of the code
in pyblosxom.py.
I think what I'll do is whip this together and send a diff. Then people
can see the sorts of things I've changed without me having to commit to
the repository.
If it looks decent, then we can commit it and augment it there. If it
looks like a terrible approach, then we can try another one.
I'm actually going to California tomorrow for a few days, so I may wait
until Monday to do changes. Then I won't potentially do something that
causes issues and then skip town causing everyone to be irritated for a
few days.
It also gives us more time to toss more ideas around.
Also, I can write things down into a specification, if you guys like. It
might help as it'd be a coherent document instead of a series of replies
spread out across several email threads.
/will
|
|
From: will <wi...@bl...> - 2003-02-05 17:18:12
|
I'm into replying to my own emails today. All these things running through my head right now. More below: On Wed, 5 Feb 2003, will wrote: > > > > to do the actual work based on querystring attributes. > > > > And some other pieces of data, like REQUEST_METHOD. > > Hmmm... I'm going to have to toss this around. I'm wondering if we > should build a HTTP request object of some sort and pass that around > instead. That changes this whole discussion from a "url handler" to a > "http request handler". Mmm... That actually makes more sense to do. > > Though that might be overkill--those variables are already available in > the os.environ dict which everything can see. If we go with the transform mechanism, then we'd want to move those variables from os.environ to some kind of HTTP request object the contents of which could be changed. Also, when I'm saying "HTTP request object", I really mean just a dict of name/value pairs. /will |
|
From: Wari W. <wa...@ce...> - 2003-02-06 06:23:01
|
* will <wi...@bl...> [030206 01:15]: > If we go with the transform mechanism, then we'd want to move those > variables from os.environ to some kind of HTTP request object the > contents of which could be changed. Wow, great conversation you guys have, I'm gonna have to read and re-read :) > Also, when I'm saying "HTTP request object", I really mean just a dict > of name/value pairs. Before we go on further here, this is something I've been meaning to get done and ask you guys. I wanted to use jonpy cgi modules http://jonpy.sourceforge.net/ which is great for consolidating CGI related processing. Look at http://jonpy.sourceforge.net/cgi.html where there's params, environ and cookies data (if we need in the future). jonpy also does mod_python and fastCGI. Mod_python and fastCGI requires pyblosxom to run more like a servlet thingy (pyblosxom should never exit), and without modification to pyblosxom at all the modpy and fcgi modules can be used in the boot up code and ensures that pyblosxom never dies (sounds like an 007 movie). Yay, or nay? I need your vote. This will require major tweaks in pyblosxom code but I should be able to get it done in the weekend. -- Regards: Wari Wahab Senior R&D Engineer Celestix Networks http://www.celestix.com/ |
Thanks for helping keep SourceForge clean.
X