From jim at zope.com Tue Jun 16 11:36:44 2009 From: jim at zope.com (Jim Fulton) Date: Tue, 16 Jun 2009 05:36:44 -0400 Subject: [Web-SIG] Announcing bobo Message-ID: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> Bobo is a light-weight framework for creating WSGI web applications. It's goal is to be easy to use and remember. You don't have to be a genius. It addresses 2 problems: - Mapping URLs to objects - Calling objects to generate HTTP responses Bobo doesn't have a templateing language, a database integration layer, or a number of other features that can be provided by WSGI middle-ware or application-specific libraries. Bobo builds on other frameworks, most notably WSGI and WebOb. To learn more. visit: http://bobo.digicool.com Jim -- Jim Fulton Zope Corporation From robillard.etienne at gmail.com Tue Jun 16 16:51:50 2009 From: robillard.etienne at gmail.com (Etienne Robillard) Date: Tue, 16 Jun 2009 10:51:50 -0400 Subject: [Web-SIG] Announcing bobo In-Reply-To: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> Message-ID: <4A37B186.6090903@gmail.com> Nothing very new here. At least next time try to be a little more creative, otherwise this is getting slightly boring and repetitive... Regards, -- Etienne Jim Fulton wrote: > Bobo is a light-weight framework for creating WSGI web applications. > > It's goal is to be easy to use and remember. You don't have to be a genius. > > It addresses 2 problems: > > - Mapping URLs to objects > > - Calling objects to generate HTTP responses > > Bobo doesn't have a templateing language, a database integration layer, > or a number of other features that can be provided by WSGI > middle-ware or application-specific libraries. > > Bobo builds on other frameworks, most notably WSGI and WebOb. > > To learn more. visit: http://bobo.digicool.com > > Jim > > -- > Jim Fulton > Zope Corporation -- Etienne Robillard Green Tea Hackers Club Blog: PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC "L'imagination est plus importante que le savoir" -- Albert Einstein From maluke at gmail.com Tue Jun 16 17:02:25 2009 From: maluke at gmail.com (Sergey Schetinin) Date: Tue, 16 Jun 2009 18:02:25 +0300 Subject: [Web-SIG] Announcing bobo In-Reply-To: <4A37B186.6090903@gmail.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> Message-ID: <116315680906160802p3d90c397h6164b23c943ebcb3@mail.gmail.com> On 2009-06-16, Etienne Robillard wrote: > > Nothing very new here. At least next time try to be a little more > creative, otherwise this is getting slightly boring and repetitive... > I think that's a bit rough, but indeed there are quite a few frameworks / components that do this thing and I kind of don't get why people want to write their apps that way. I wonder if Jim or anyone else could explain the rationale behind all these URL routing libraries. Nobody minds calling functions from other functions -- that's basics of programming, but for some reason URL dispatching is seen as something different. Why? This is not a criticism, I just really would like to understand this. -Sergey From faassen at startifact.com Tue Jun 16 17:19:45 2009 From: faassen at startifact.com (Martijn Faassen) Date: Tue, 16 Jun 2009 17:19:45 +0200 Subject: [Web-SIG] Announcing bobo In-Reply-To: <4A37B186.6090903@gmail.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> Message-ID: <8928d4e90906160819s56f7aaa2tbb65244cb7dbc05@mail.gmail.com> Hey, On Tue, Jun 16, 2009 at 4:51 PM, Etienne Robillard wrote: > > Nothing very new here. At least next time try to be a little more > creative, otherwise this is getting slightly boring and repetitive... It's a bit rich to call Jim Fulton uncreative concerning web development. I suggest you delve into the history of Python web development for a bit. Of course back in '97 there was more to invent than there is today. Regards, Martijn From pje at telecommunity.com Tue Jun 16 17:47:22 2009 From: pje at telecommunity.com (P.J. Eby) Date: Tue, 16 Jun 2009 11:47:22 -0400 Subject: [Web-SIG] Announcing bobo In-Reply-To: <8928d4e90906160819s56f7aaa2tbb65244cb7dbc05@mail.gmail.com > References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <8928d4e90906160819s56f7aaa2tbb65244cb7dbc05@mail.gmail.com> Message-ID: <20090616154428.0906C3A4060@sparrow.telecommunity.com> At 05:19 PM 6/16/2009 +0200, Martijn Faassen wrote: >Hey, > >On Tue, Jun 16, 2009 at 4:51 PM, Etienne >Robillard wrote: > > > > Nothing very new here. At least next time try to be a little more > > creative, otherwise this is getting slightly boring and repetitive... > >It's a bit rich to call Jim Fulton uncreative concerning web >development. I suggest you delve into the history of Python web >development for a bit. Of course back in '97 there was more to invent >than there is today. Surely Etienne is joking, since anybody who knows Python web development should know that Bobo was actually the first Python web framework ever developed, 12 years ago, and that it invented quite a lot of the things found in Python web frameworks today, not to mention being the forerunner of all things Zope. It's rather nice to see it back, reincarnated on today's egg/WSGI infrastructure. The original Bobo was what convinced me to become a Python programmer 12 years ago. (...after I realized that a Bobo-equivalent framework could not be implemented in Perl without far greater wizardry than I was capable of managing, while in Python it was nearly trivial to do so. I left Perl and never looked back.) From robillard.etienne at gmail.com Tue Jun 16 18:15:29 2009 From: robillard.etienne at gmail.com (Etienne Robillard) Date: Tue, 16 Jun 2009 12:15:29 -0400 Subject: [Web-SIG] Announcing bobo In-Reply-To: <8928d4e90906160819s56f7aaa2tbb65244cb7dbc05@mail.gmail.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <8928d4e90906160819s56f7aaa2tbb65244cb7dbc05@mail.gmail.com> Message-ID: <4A37C521.4080708@gmail.com> Martin, I don't care about '97, pretty much. I think that if this Jim guy has lots of experience then at least he could not pretend that other people works are made by/for geniuses, which is probably untrue anyway. There's other ways to advertise a open source project. One method is to discriminate other projects, thus making it's own work appears better in some ways or another. Of courses this has nothing to do in being a genius.. You don't have to be a genius to copy-and-paste things. regards, Etienne Martijn Faassen wrote: > Hey, > > On Tue, Jun 16, 2009 at 4:51 PM, Etienne > Robillard wrote: >> Nothing very new here. At least next time try to be a little more >> creative, otherwise this is getting slightly boring and repetitive... > > It's a bit rich to call Jim Fulton uncreative concerning web > development. I suggest you delve into the history of Python web > development for a bit. Of course back in '97 there was more to invent > than there is today. > > Regards, > > Martijn > -- Etienne Robillard Green Tea Hackers Club Blog: PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC From arw1961 at yahoo.com Tue Jun 16 18:27:00 2009 From: arw1961 at yahoo.com (Aaron Watters) Date: Tue, 16 Jun 2009 09:27:00 -0700 (PDT) Subject: [Web-SIG] Announcing bobo Message-ID: <266800.64406.qm@web32006.mail.mud.yahoo.com> > Nobody minds calling functions from other > functions -- > that's basics of programming, but for some reason URL > dispatching is > seen as something different. Why? I don't know, but every time I see a strange data structure with regular expressions in it that is supposed to define my web application URL structure, my skin crawls. I think the simplicity of FILE_PATH==URL is one of the main reasons for the popularity of PHP -- other than that I can't think of any excuse for PHP. If python had a framework that had a simple and straightforward organization 5 to 10 years ago I don't think either PHP or Ruby/Rails would have ever evolved. BTW, this was one of the primary reasons I created WHIFF -- I wanted a structure where I just dropped files into a directory and they were automatically treated as applications or middlewares with an URL derived from the file path with associated services which could be combined in a natural fashion... There wasn't anything like that available, so I had to create it. -- Aaron Watters === http://aaron.oirt.rutgers.edu/myapp/amcharts/doc http://aaron.oirt.rutgers.edu/myapp/docs/W1500.whyIsWhiffCool less is more. From faassen at startifact.com Tue Jun 16 18:39:02 2009 From: faassen at startifact.com (Martijn Faassen) Date: Tue, 16 Jun 2009 18:39:02 +0200 Subject: [Web-SIG] Announcing bobo In-Reply-To: <4A37C521.4080708@gmail.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <8928d4e90906160819s56f7aaa2tbb65244cb7dbc05@mail.gmail.com> <4A37C521.4080708@gmail.com> Message-ID: <8928d4e90906160939x6d58defbj70a6d337cb473d8b@mail.gmail.com> Hey, On Tue, Jun 16, 2009 at 6:15 PM, Etienne Robillard wrote: > I don't care about '97, pretty much. Those who do not learn from history are destined to repeat it. :) > I think that if this Jim guy has lots of experience then at least he > could not pretend that other people works are made by/for geniuses, > which is probably untrue anyway. There's other ways to advertise a open source project I think you misread him. He said it the goal is for it to be simple, he didn't say other people's works are complicated. Besides; I think Jim would be the first to admit that some of his other works are actually a bit harder to understand for other people. Zope 2 and Zope 3, which Jim both designed, are considered by many to be more than a little bit intimidating. > One method > is to discriminate other projects, thus making it's own work appears > better in some ways or another. Of courses this has nothing to do in > being a genius.. You don't have to be a genius to copy-and-paste things. You're reading things that Jim didn't write anywhere as far as I know. He doesn't compare Bobo with anything else. He just states what the goal is. What he does say is that he built Bobo on other people's work, giving it credit. Regards, Martijn From nathan at yergler.net Tue Jun 16 18:39:06 2009 From: nathan at yergler.net (Nathan Yergler) Date: Tue, 16 Jun 2009 09:39:06 -0700 Subject: [Web-SIG] Announcing bobo In-Reply-To: <4A37C521.4080708@gmail.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <8928d4e90906160819s56f7aaa2tbb65244cb7dbc05@mail.gmail.com> <4A37C521.4080708@gmail.com> Message-ID: <53039e7b0906160939ud3f3d50v917532d8dc6b81cd@mail.gmail.com> On Tue, Jun 16, 2009 at 9:15 AM, Etienne Robillard wrote: > > Martin, > > I don't care about '97, pretty much. > > I think that if this Jim guy has lots of experience then at least he > could not pretend that other people works are made by/for geniuses, > which is probably untrue anyway. How do you know that Jim believes this? I don't see anything in his initial announcement (or in skimming the documentation) that implies you should choose Bobo over any other framework. > > There's other ways to advertise a open source project. One method > is to discriminate other projects, thus making it's own work appears > better in some ways or another. Of courses this has nothing to do in > being a genius.. You don't have to be a genius to copy-and-paste things. > Again, this seems to be a stretch. Jim simply sent a message letting people know about Bobo. I for one appreciate that, as it's useful for me to have different tools in my toolkit for approaching different problems. Bobo may share features (or non-features) with other frameworks (web.py comes to mind) but that doesn't mean it's "copy and paste". This feels like an ad hominem argument which is both surprising and unproductive. Nathan > regards, > > Etienne > > > Martijn Faassen wrote: >> Hey, >> >> On Tue, Jun 16, 2009 at 4:51 PM, Etienne >> Robillard wrote: >>> Nothing very new here. At least next time try to be a little more >>> creative, otherwise this is getting slightly boring and repetitive... >> >> It's a bit rich to call Jim Fulton uncreative concerning web >> development. I suggest you delve into the history of Python web >> development for a bit. Of course back in '97 there was more to invent >> than there is today. >> >> Regards, >> >> Martijn >> > > > -- > Etienne Robillard > Green Tea Hackers Club > Blog: > PGP Fingerprint: AED6 B33B B41D 5F4F A92A ?2B71 874C FB27 F3A9 BDCC > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: http://mail.python.org/mailman/options/web-sig/nathan%40yergler.net > From duncan.mcgreggor at gmail.com Tue Jun 16 18:41:20 2009 From: duncan.mcgreggor at gmail.com (Duncan M. McGreggor) Date: Tue, 16 Jun 2009 11:41:20 -0500 Subject: [Web-SIG] Announcing bobo In-Reply-To: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> Message-ID: <4A37CB30.5060109@gmail.com> Jim Fulton wrote: > Bobo is a light-weight framework for creating WSGI web applications. > > It's goal is to be easy to use and remember. You don't have to be a genius. > > It addresses 2 problems: > > - Mapping URLs to objects > > - Calling objects to generate HTTP responses > > Bobo doesn't have a templateing language, a database integration layer, > or a number of other features that can be provided by WSGI > middle-ware or application-specific libraries. > > Bobo builds on other frameworks, most notably WSGI and WebOb. > > To learn more. visit: http://bobo.digicool.com > > Jim > > -- > Jim Fulton > Zope Corporation Thanks Jim! d From faassen at startifact.com Tue Jun 16 18:43:28 2009 From: faassen at startifact.com (Martijn Faassen) Date: Tue, 16 Jun 2009 18:43:28 +0200 Subject: [Web-SIG] Announcing bobo In-Reply-To: <266800.64406.qm@web32006.mail.mud.yahoo.com> References: <266800.64406.qm@web32006.mail.mud.yahoo.com> Message-ID: <8928d4e90906160943r43cd22d1ve2e4bc4b7f637101@mail.gmail.com> Hey, On Tue, Jun 16, 2009 at 6:27 PM, Aaron Watters wrote: [snip] > If python had a framework that had a simple and > straightforward organization 5 to 10 years ago I don't > think either PHP or Ruby/Rails would have ever evolved. 5 years ago would've been far too late for PHP. Even 10 years ago; PHP has been around since '95 and I think was fairly popular quite soon. Even Rails goes back to '04 - not sure when it got really popular. (anyway, I know you were around back then and before me, I just like history) In general, I don't think there's anything that could stop people from creating their own new web frameworks. :) At best we can aim to reuse bits and pieces and work towards making that easier. Regards, Martijn From orsenthil at gmail.com Tue Jun 16 18:44:27 2009 From: orsenthil at gmail.com (Senthil Kumaran) Date: Tue, 16 Jun 2009 22:14:27 +0530 Subject: [Web-SIG] Announcing bobo Message-ID: <20090616164427.GB17884@ubuntu.ubuntu-domain> On Tue, Jun 16, 2009 at 12:15:29PM -0400, Etienne Robillard wrote: > I think that if this Jim guy has lots of experience then at least he > could not pretend that other people works are made by/for geniuses, > which is probably untrue anyway. Hey, I don't understand why are being so negative with your comments. Does not sound good. I surely dont know what your contributions are, but I do know what Jim Fulton's contributions are. -- Senthil From robillard.etienne at gmail.com Tue Jun 16 18:51:48 2009 From: robillard.etienne at gmail.com (Etienne Robillard) Date: Tue, 16 Jun 2009 12:51:48 -0400 Subject: [Web-SIG] Announcing bobo In-Reply-To: <20090616164427.GB17884@ubuntu.ubuntu-domain> References: <20090616164427.GB17884@ubuntu.ubuntu-domain> Message-ID: <4A37CDA4.4050006@gmail.com> Hey, don't you people know that you could use a more polite word than "Hey" to salute people ? I'm just telling my own views. If you disagree then please say something more meaningful than this. Who cares what you know. Senthil Kumaran wrote: > On Tue, Jun 16, 2009 at 12:15:29PM -0400, Etienne Robillard wrote: >> I think that if this Jim guy has lots of experience then at least he >> could not pretend that other people works are made by/for geniuses, >> which is probably untrue anyway. > > Hey, I don't understand why are being so negative with your comments. > Does not sound good. I surely dont know what your contributions are, > but I do know what Jim Fulton's contributions are. > > -- Etienne Robillard Green Tea Hackers Club Blog: PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC From robillard.etienne at gmail.com Tue Jun 16 19:38:58 2009 From: robillard.etienne at gmail.com (Etienne Robillard) Date: Tue, 16 Jun 2009 13:38:58 -0400 Subject: [Web-SIG] Announcing bobo In-Reply-To: <53039e7b0906160939ud3f3d50v917532d8dc6b81cd@mail.gmail.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <8928d4e90906160819s56f7aaa2tbb65244cb7dbc05@mail.gmail.com> <4A37C521.4080708@gmail.com> <53039e7b0906160939ud3f3d50v917532d8dc6b81cd@mail.gmail.com> Message-ID: <4A37D8B2.7050600@gmail.com> I recommend you quit using latin to try looking smarter. ;) I do I'm discouraged to see so much adversion between Python web frameworks fighting for the same goal. To say that "you don't to be a genius" implies that all other web frameworks are made for geniuses, which is probably offending for less-mature projects. Of courses I might have misread or taking for granted that this was a totally new project.. My apologies then to Jim... ;) Regards, Etienne > This feels like an ad hominem argument which is both surprising and > unproductive. > > Nathan > >> regards, >> >> Etienne >> >> >> Martijn Faassen wrote: >>> Hey, >>> >>> On Tue, Jun 16, 2009 at 4:51 PM, Etienne >>> Robillard wrote: >>>> Nothing very new here. At least next time try to be a little more >>>> creative, otherwise this is getting slightly boring and repetitive... >>> It's a bit rich to call Jim Fulton uncreative concerning web >>> development. I suggest you delve into the history of Python web >>> development for a bit. Of course back in '97 there was more to invent >>> than there is today. >>> >>> Regards, >>> >>> Martijn >>> >> >> -- >> Etienne Robillard >> Green Tea Hackers Club >> Blog: >> PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC >> _______________________________________________ >> Web-SIG mailing list >> Web-SIG at python.org >> Web SIG: http://www.python.org/sigs/web-sig >> Unsubscribe: http://mail.python.org/mailman/options/web-sig/nathan%40yergler.net >> > -- Etienne Robillard Green Tea Hackers Club Blog: PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC From orsenthil at gmail.com Tue Jun 16 19:49:48 2009 From: orsenthil at gmail.com (Senthil Kumaran) Date: Tue, 16 Jun 2009 23:19:48 +0530 Subject: [Web-SIG] Announcing bobo In-Reply-To: <4A37CDA4.4050006@gmail.com> References: <20090616164427.GB17884@ubuntu.ubuntu-domain> <4A37CDA4.4050006@gmail.com> Message-ID: <20090616174948.GB4314@ubuntu.ubuntu-domain> On Tue, Jun 16, 2009 at 12:51:48PM -0400, Etienne Robillard wrote: > Hey, don't you people know that you could use a more polite word > than "Hey" to salute people ? > > I'm just telling my own views. If you disagree then please say something > more meaningful than this. Who cares what you know. Sorry for that. I wrote that immediately after reading your response. Others have responded more appropriately. Thank you, Senthil From jasonrbriggs at gmail.com Tue Jun 16 21:34:38 2009 From: jasonrbriggs at gmail.com (Jason Briggs) Date: Tue, 16 Jun 2009 20:34:38 +0100 Subject: [Web-SIG] Announcing bobo References: Message-ID: Typical. The first time I make the effort to reply to the list, I reply-to-sender rather than to-list. I'm a muppet. Anyway, reply below.... Begin forwarded message: > From: Jason Briggs > Date: 16 June 2009 20:04:46 BST > To: Etienne Robillard > Subject: Re: [Web-SIG] Announcing bobo > > "Ad hominen" isn't using latin to look smart. It's a common-term > description of a type of argument... which just happens to be latin. > > You probably already knew that, but based on your previous emails I > wasn't sure -- so just for your info. > > J > > > > On 16 Jun 2009, at 18:38, Etienne Robillard wrote: > >> >> I recommend you quit using latin to try looking smarter. ;) >> >> I do I'm discouraged to see so much adversion between Python web >> frameworks fighting for the same goal. >> >> To say that "you don't to be a genius" implies that all other web >> frameworks are made for geniuses, which is probably offending for >> less-mature projects. Of courses I might have misread or taking for >> granted that this was a totally new project.. >> >> My apologies then to Jim... ;) >> >> Regards, >> >> Etienne >> >>> This feels like an ad hominem argument which is both surprising and >>> unproductive. >>> >>> Nathan >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ctb at msu.edu Tue Jun 16 19:53:17 2009 From: ctb at msu.edu (C. Titus Brown) Date: Tue, 16 Jun 2009 10:53:17 -0700 Subject: [Web-SIG] Announcing bobo In-Reply-To: <4A37D8B2.7050600@gmail.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <8928d4e90906160819s56f7aaa2tbb65244cb7dbc05@mail.gmail.com> <4A37C521.4080708@gmail.com> <53039e7b0906160939ud3f3d50v917532d8dc6b81cd@mail.gmail.com> <4A37D8B2.7050600@gmail.com> Message-ID: <20090616175317.GA8903@idyll.org> Hey all, I think we can pretty safely ignore Etienne as either a troll or an unnecessarily rude person. Has anyone looked at Bobo yet? I'd be interested in comparisons between it and Quixote, which is what I've mostly used in the past. I believe that Bobo begat Zope, which begat Quixote as (I thought) an attempt to return to Bobo-style programming, and so I'm curious about what sort of choices Bobo has made. thanks, --titus -- C. Titus Brown, ctb at msu.edu From robillard.etienne at gmail.com Tue Jun 16 23:53:20 2009 From: robillard.etienne at gmail.com (Etienne Robillard) Date: Tue, 16 Jun 2009 17:53:20 -0400 Subject: [Web-SIG] Announcing bobo In-Reply-To: <20090616175317.GA8903@idyll.org> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <8928d4e90906160819s56f7aaa2tbb65244cb7dbc05@mail.gmail.com> <4A37C521.4080708@gmail.com> <53039e7b0906160939ud3f3d50v917532d8dc6b81cd@mail.gmail.com> <4A37D8B2.7050600@gmail.com> <20090616175317.GA8903@idyll.org> Message-ID: <4A381450.3000308@gmail.com> Pfft, I bet this thread would have never happened without my initial intervention. Likewise, I think you're just using this thread for your own interests, disregarding my own arguments on why web frameworks are so hard to cope with. If you want to start a thread for Bobo, please switch mailing-list or create a new thread, as all I wanted was to tell Jim my disappointement regarding Bobo, and I still think its not very revolutionary. Regards, Etienne C. Titus Brown wrote: > Hey all, > > I think we can pretty safely ignore Etienne as either a troll or an > unnecessarily rude person. > > Has anyone looked at Bobo yet? I'd be interested in comparisons between > it and Quixote, which is what I've mostly used in the past. I believe > that Bobo begat Zope, which begat Quixote as (I thought) an attempt to > return to Bobo-style programming, and so I'm curious about what sort of > choices Bobo has made. > > thanks, > --titus -- Etienne Robillard Green Tea Hackers Club Blog: PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC From dstanek at dstanek.com Wed Jun 17 00:34:14 2009 From: dstanek at dstanek.com (David Stanek) Date: Tue, 16 Jun 2009 18:34:14 -0400 Subject: [Web-SIG] Announcing bobo In-Reply-To: <4A381450.3000308@gmail.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <8928d4e90906160819s56f7aaa2tbb65244cb7dbc05@mail.gmail.com> <4A37C521.4080708@gmail.com> <53039e7b0906160939ud3f3d50v917532d8dc6b81cd@mail.gmail.com> <4A37D8B2.7050600@gmail.com> <20090616175317.GA8903@idyll.org> <4A381450.3000308@gmail.com> Message-ID: On Tue, Jun 16, 2009 at 5:53 PM, Etienne Robillard wrote: > > If you want to start a thread for Bobo, please switch mailing-list or > create a new thread, as all I wanted was to tell Jim my disappointement > regarding Bobo, and I still think its not very revolutionary. > Depends on what you mean by revolutionary. I am in the framework hating camp. This back to basics style framework is what I like to see. Frameworks like Django, TurboGears and Zope just don't allow me to do what I want. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek From mnot at mnot.net Wed Jun 17 01:45:55 2009 From: mnot at mnot.net (Mark Nottingham) Date: Wed, 17 Jun 2009 09:45:55 +1000 Subject: [Web-SIG] FYI: nbhttp Message-ID: <9B664E43-6C09-4320-BDB8-7180D54C0986@mnot.net> I've recently put up a library that I've been working on for a little while, nbhttp: "nb" stands for non-blocking; this is explicitly an asynchronous/event- driven library, with both a server and a client component. They can be trivially used together to implement a proxy. The aim is to be HTTP/1.1 compliant (and it's most of the way there, with the exceptions of expect/continue and pipelining support), to be as performant as possible, and to expose as much of the raw protocol as possible. That last motiviation is because nbhttp is used by REDbot , a HTTP resource checker, and it needs "deep" access into what's happening on the wire (without intervening software trying to be helpful). It is very rough, mostly undocumented, and will probably crash. It is WSGI-like, but not WSGI compatible, because there were a few places where WSGI was too constraining. However, it may be useful as food for thought in API revisions. Or not. :) Cheers, -- Mark Nottingham http://www.mnot.net/ From graham.dumpleton at gmail.com Wed Jun 17 01:49:15 2009 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Wed, 17 Jun 2009 09:49:15 +1000 Subject: [Web-SIG] FYI: nbhttp In-Reply-To: <9B664E43-6C09-4320-BDB8-7180D54C0986@mnot.net> References: <9B664E43-6C09-4320-BDB8-7180D54C0986@mnot.net> Message-ID: <88e286470906161649u14c16e7ag2880e086c65af763@mail.gmail.com> 2009/6/17 Mark Nottingham : > I've recently put up a library that I've been working on for a little while, > nbhttp: > ? > > "nb" stands for non-blocking; this is explicitly an > asynchronous/event-driven library, with both a server and a client > component. They can be trivially used together to implement a proxy. > > The aim is to be HTTP/1.1 compliant (and it's most of the way there, with > the exceptions of expect/continue and pipelining support), to be as > performant as possible, and to expose as much of the raw protocol as > possible. > > That last motiviation is because nbhttp is used by REDbot > , a HTTP resource checker, and it needs "deep" access > into what's happening on the wire (without intervening software trying to be > helpful). > > It is very rough, mostly undocumented, and will probably crash. It is > WSGI-like, but not WSGI compatible, because there were a few places where > WSGI was too constraining. However, it may be useful as food for thought in > API revisions. Or not. :) Can you explain the difference to WSGI so that don't have to go digging through source code to work it out, or is there documentation somewhere which explains it? Graham From mnot at mnot.net Wed Jun 17 01:56:39 2009 From: mnot at mnot.net (Mark Nottingham) Date: Wed, 17 Jun 2009 09:56:39 +1000 Subject: [Web-SIG] FYI: nbhttp In-Reply-To: <88e286470906161649u14c16e7ag2880e086c65af763@mail.gmail.com> References: <9B664E43-6C09-4320-BDB8-7180D54C0986@mnot.net> <88e286470906161649u14c16e7ag2880e086c65af763@mail.gmail.com> Message-ID: <07532F08-4BE7-4957-B7D6-505BB50A0FC2@mnot.net> The biggest functional difference (there are cosmetic ones that could be papered over) is that there needs to be some way to pause bytes being pushed out; this was discussed a LONG time ago here WRT async servers (I haven't followed discussion closely since, so apologies if I've missed something more recent). The other difference is that WSGI isn't symmetric regarding requests and responses; you push a response out with a function, but you have to read request bytes in from a file-like object. This doesn't work so well when you want to invert the API to use it as a client API as well, and it doesn't work with the all push-based approach that push_tcp takes (i.e., the socket pushes the app bytes upon a read(), and the app pushes bytes to the socket with write()). I should have mentioned -- the easiest way to see the API is to look at at the bottoms of src/client.py and src/server.py, as well as scripts/proxy.py. Cheers, On 17/06/2009, at 9:49 AM, Graham Dumpleton wrote: > 2009/6/17 Mark Nottingham : >> I've recently put up a library that I've been working on for a >> little while, >> nbhttp: >> >> >> "nb" stands for non-blocking; this is explicitly an >> asynchronous/event-driven library, with both a server and a client >> component. They can be trivially used together to implement a proxy. >> >> The aim is to be HTTP/1.1 compliant (and it's most of the way >> there, with >> the exceptions of expect/continue and pipelining support), to be as >> performant as possible, and to expose as much of the raw protocol as >> possible. >> >> That last motiviation is because nbhttp is used by REDbot >> , a HTTP resource checker, and it needs "deep" >> access >> into what's happening on the wire (without intervening software >> trying to be >> helpful). >> >> It is very rough, mostly undocumented, and will probably crash. It is >> WSGI-like, but not WSGI compatible, because there were a few places >> where >> WSGI was too constraining. However, it may be useful as food for >> thought in >> API revisions. Or not. :) > > Can you explain the difference to WSGI so that don't have to go > digging through source code to work it out, or is there documentation > somewhere which explains it? > > Graham -- Mark Nottingham http://www.mnot.net/ From alan at xhaus.com Wed Jun 17 03:13:31 2009 From: alan at xhaus.com (Alan Kennedy) Date: Wed, 17 Jun 2009 02:13:31 +0100 Subject: [Web-SIG] Announcing bobo In-Reply-To: <4A381450.3000308@gmail.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <8928d4e90906160819s56f7aaa2tbb65244cb7dbc05@mail.gmail.com> <4A37C521.4080708@gmail.com> <53039e7b0906160939ud3f3d50v917532d8dc6b81cd@mail.gmail.com> <4A37D8B2.7050600@gmail.com> <20090616175317.GA8903@idyll.org> <4A381450.3000308@gmail.com> Message-ID: <4a951aa00906161813k4805c258uda0d3f82e2231a9a@mail.gmail.com> [Etienne] > If you want to start a thread for Bobo, please switch mailing-list or > create a new thread, as all I wanted was to tell Jim my disappointement > regarding Bobo, and I still think its not very revolutionary. I completely disagree; this is definitely the appopriate list for discussing web frameworks and new approaches. There is no perfect framework in python, or any other language. It is only with the introduction, discussion, acceptance and assimilation of new ideas that we all move forward together. Jim has the longest history of all in Python web frameworks; he created the very concept. He founded and built the entire Zope community; I will always listen to what he has to say. I wish you the best of luck with your own web framework, notmm http://gthc.org/projects/notmm/0.2.12/ Which seems to have some potential, but currently lacks community support. http://gthc.org/community/ I'm looking forward to Europython, where I know I'll be meeting some great python folks, and hopefully some of us will get to continue our WSGI revision discussions. All the best, Alan. From wilk at flibuste.net Wed Jun 17 10:15:20 2009 From: wilk at flibuste.net (William Dode) Date: Wed, 17 Jun 2009 08:15:20 +0000 (UTC) Subject: [Web-SIG] Announcing bobo References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <8928d4e90906160819s56f7aaa2tbb65244cb7dbc05@mail.gmail.com> <4A37C521.4080708@gmail.com> <53039e7b0906160939ud3f3d50v917532d8dc6b81cd@mail.gmail.com> <4A37D8B2.7050600@gmail.com> <20090616175317.GA8903@idyll.org> <4A381450.3000308@gmail.com> Message-ID: On 16-06-2009, Etienne Robillard wrote: > > Pfft, I bet this thread would have never happened without my initial > intervention. Likewise, I think you're just using this thread for your > own interests, disregarding my own arguments on why web frameworks are > so hard to cope with. > > If you want to start a thread for Bobo, please switch mailing-list or > create a new thread, as all I wanted was to tell Jim my disappointement > regarding Bobo, and I still think its not very revolutionary. Imho you just describe your mistake ! You should start an other thread to discuss about the number of web framework instead of focus specialy on bobo. In fact, web framework like bobo is an answer to this problem (the number of framework). Like you said there is nothing revolutionary, it use other components (paste and webob), it means that we begin to stop to reinvent the wheel and search for the concensus on the smaller efficient framework. And this is really fine ! -- William Dod? - http://flibuste.net Informaticien Ind?pendant From noah.gift at gmail.com Wed Jun 17 10:56:16 2009 From: noah.gift at gmail.com (Noah Gift) Date: Wed, 17 Jun 2009 20:56:16 +1200 Subject: [Web-SIG] Announcing bobo In-Reply-To: References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <8928d4e90906160819s56f7aaa2tbb65244cb7dbc05@mail.gmail.com> <4A37C521.4080708@gmail.com> <53039e7b0906160939ud3f3d50v917532d8dc6b81cd@mail.gmail.com> <4A37D8B2.7050600@gmail.com> <20090616175317.GA8903@idyll.org> <4A381450.3000308@gmail.com> Message-ID: +1 Bobo. I like stuff Jim writes. -- Cheers, Noah -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at zope.com Wed Jun 17 11:05:05 2009 From: jim at zope.com (Jim Fulton) Date: Wed, 17 Jun 2009 05:05:05 -0400 Subject: [Web-SIG] Announcing bobo In-Reply-To: <8928d4e90906160939x6d58defbj70a6d337cb473d8b@mail.gmail.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <8928d4e90906160819s56f7aaa2tbb65244cb7dbc05@mail.gmail.com> <4A37C521.4080708@gmail.com> <8928d4e90906160939x6d58defbj70a6d337cb473d8b@mail.gmail.com> Message-ID: On Jun 16, 2009, at 12:39 PM, Martijn Faassen wrote: ... > He said it the goal is for it to be simple, > he didn't say other people's works are complicated. Yup, however I can see how "You don't have to be a genius" could be construed as implying that you do have to be a genius to use other frameworks. It was intended to be a play on the name "bobo", which can be translated as "idiot" in Spanish. I absolutely don't want to bad-mouth other frameworks. I've removed this unnecessary sentence from the PyPI page and from the packages long description in subversion. Jim -- Jim Fulton Zope Corporation From chris at simplistix.co.uk Wed Jun 17 11:12:34 2009 From: chris at simplistix.co.uk (Chris Withers) Date: Wed, 17 Jun 2009 10:12:34 +0100 Subject: [Web-SIG] Announcing bobo In-Reply-To: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> Message-ID: <4A38B382.3050700@simplistix.co.uk> Hey Jim, Jim Fulton wrote: > Bobo is a light-weight framework for creating WSGI web applications. Do you know if there are plans/possibilities to make the routing part of Bobo available for other frameworks and/or in a non-decorator fashion? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From jim at zope.com Wed Jun 17 11:46:30 2009 From: jim at zope.com (Jim Fulton) Date: Wed, 17 Jun 2009 05:46:30 -0400 Subject: [Web-SIG] Announcing bobo In-Reply-To: <116315680906160802p3d90c397h6164b23c943ebcb3@mail.gmail.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <116315680906160802p3d90c397h6164b23c943ebcb3@mail.gmail.com> Message-ID: <1E0D548A-E378-4A5C-A2EA-07317B4BF9A9@zope.com> On Jun 16, 2009, at 11:02 AM, Sergey Schetinin wrote: ... > indeed there are quite a few > frameworks / components that do this thing and I kind of don't get why > people want to write their apps that way. I wonder if Jim or anyone > else could explain the rationale behind all these URL routing > libraries. Nobody minds calling functions from other functions -- > that's basics of programming, but for some reason URL dispatching is > seen as something different. Why? > > This is not a criticism, I just really would like to understand this. Fair enough. I'm not sure I understand your question. You need some way of mapping URLs onto Python objects that handle them. You can do this on a case by case basis by inspecting a URL and doing some sort of ad hoc dispatch in your application. Is that what you mean by "calling functions from other functions"? I've found it useful to have a standard mechanism for this that you can use over and over without reinventing it each time. In the original bobo (aka "python object publisher") that I wrote in '96, I mapped URLs onto object names in modules. Later, I extended this to use object keys and this grew into a traversal model. There were some difficulties with this approach: - I needed some way to decide which objects should be URL accessible. This led to some less than optimal rules. - The traversal model mapped well onto an object database, but not so well onto relational models. Many people have taken the approach of providing an explicit separate (from code) mechanism of mapping URLs onto their Python objects. Usually, this involves having a table mapping URL patterns of some sort onto object identifiers. I like explicit. :) BTW, Chris McDonough provides a nice comparison of traversal and what he calls "URL Dispatch" based on a mapping table (Pylons routes) in: http://docs.repoze.org/bfg/narr/urlmapping.html#differences-between-traversal-and-url-dispatch One of my goals with bobo is express web applications with Python as much as practical. While bobo does support the ability to provide an external mapping, I definitely wanted to be able to express the mapping in the code. One of the advantages of recreating bobo in the 21st century is that I get to use Python decorators, which provide a way to be very explicit about which objects are available to handle URLs. (Other web frameworks use decorators for this purpose too. Bobo is *not* revolutionary in any way. :) I find the route syntax used by Rails and Pylons to be very appealing. It uses fairly simple path patterns with placeholders. It doesn't use regular expressions. I don't personally care for the controller+action model used by Rails and borrowed by Pylons, so, after looking at using Pylon's routes implementation, which I took a lot of inspiration from, I went with a slightly different model. Basically, a route maps onto an object and when a URL matches a route, we call the object. (Of course, there are other details, but they're covered by the bobo documentation.) I hope this helps and that I haven't totally misunderstood your original question. Jim -- Jim Fulton Zope Corporation From jim at zope.com Wed Jun 17 11:52:08 2009 From: jim at zope.com (Jim Fulton) Date: Wed, 17 Jun 2009 05:52:08 -0400 Subject: [Web-SIG] Announcing bobo In-Reply-To: <4A38B382.3050700@simplistix.co.uk> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A38B382.3050700@simplistix.co.uk> Message-ID: <72B213C3-2F43-4602-8E20-3311289D4C97@zope.com> On Jun 17, 2009, at 5:12 AM, Chris Withers wrote: > Hey Jim, > > Jim Fulton wrote: >> Bobo is a light-weight framework for creating WSGI web applications. > > Do you know if there are plans/possibilities to make the routing > part of Bobo available for other frameworks I'm working on another project, bozo, to facilitate using bobo resources in Zope and use Zope components with bobo applications. > and/or in a non-decorator fashion? Bobo provides a mechanism to express routes separately from your Python code. Of course, Pylons also provides a route scheme that doesn't use decorators. repose.bfg integrates Pylons routes with other WSGI and Zope frameworks. Jim -- Jim Fulton Zope Corporation From arw1961 at yahoo.com Wed Jun 17 15:01:37 2009 From: arw1961 at yahoo.com (Aaron Watters) Date: Wed, 17 Jun 2009 06:01:37 -0700 (PDT) Subject: [Web-SIG] Announcing bobo Message-ID: <864396.79620.qm@web32007.mail.mud.yahoo.com> Re Jim's summary of URL routing > ...I hope this helps ... It helped me. Interesting summary. Thanks. I'm all for making things as simple and explicit as possible (at least as an optional or default behavior) and it looks like Bobo is much better than many other approaches in supporting simple and explicit URL routing. Thanks again, Jim. -- Aaron Watters http://aaron.oirt.rutgers.edu/myapp/docs/W1500.whyIsWhiffCool#Header6 http://aaron.oirt.rutgers.edu/myapp/amcharts/doc === Everything should be as simple as possible. But not simpler. -- Einstein From janssen at parc.com Wed Jun 17 20:53:46 2009 From: janssen at parc.com (Bill Janssen) Date: Wed, 17 Jun 2009 11:53:46 PDT Subject: [Web-SIG] Announcing bobo In-Reply-To: <72B213C3-2F43-4602-8E20-3311289D4C97@zope.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A38B382.3050700@simplistix.co.uk> <72B213C3-2F43-4602-8E20-3311289D4C97@zope.com> Message-ID: <36319.1245264826@parc.com> Jim Fulton wrote: > I'm working on another project, bozo, to facilitate using bobo > resources in Zope and use Zope components with bobo applications. Good names, Jim. Bill From maluke at gmail.com Thu Jun 18 00:42:32 2009 From: maluke at gmail.com (Sergey Schetinin) Date: Thu, 18 Jun 2009 01:42:32 +0300 Subject: [Web-SIG] Announcing bobo In-Reply-To: <1E0D548A-E378-4A5C-A2EA-07317B4BF9A9@zope.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <116315680906160802p3d90c397h6164b23c943ebcb3@mail.gmail.com> <1E0D548A-E378-4A5C-A2EA-07317B4BF9A9@zope.com> Message-ID: <116315680906171542g57fd275fi2c8d67c296cc04ac@mail.gmail.com> On 2009-06-17, Jim Fulton wrote: > On Jun 16, 2009, at 11:02 AM, Sergey Schetinin wrote: > ... > > indeed there are quite a few > > frameworks / components that do this thing and I kind of don't get why > > people want to write their apps that way. I wonder if Jim or anyone > > else could explain the rationale behind all these URL routing > > libraries. Nobody minds calling functions from other functions -- > > that's basics of programming, but for some reason URL dispatching is > > seen as something different. Why? > > > > This is not a criticism, I just really would like to understand this. > > > > > Fair enough. I'm not sure I understand your question. You need some way > of mapping URLs onto Python objects that handle them. You can do this on a > case by case basis by inspecting a URL and doing some sort of ad hoc > dispatch in your application. Is that what you mean by "calling functions > from other functions"? I've found it useful to have a standard mechanism > for this that you can use over and over without reinventing it each time. I guess didn't state my question properly, sorry. Let me explain what I meant by "calling functions" analogy. My point is that when we define a piece of functionality (as a function, class or whatever) we don't say where to use it. I mean, we may define functions as "take data from a this argument, process and return" and it's up to the caller to pass that data into the function, function doesn't say where that should come from or where in the rest of code should its body be injected or anything like that. So function is a definition of functionality and it is being called from somewhere else, the called should know as little as possible about the caller and its place relative to other calls its caller makes. At least that seems to be the advice for good software design. When considering webapps and what urls they should handle it seems like the same should apply -- webapps define contained blocks of functionality and the task of placing them somewhere in URL-space belongs to the "caller" which in this case would be a configuration or serving script or, most often, a parent application. Sure, this requires inspecting the URL, or as you said, "ad-hoc dispatching". I think that misrepresents this approach because all it boils down to is a series of if's, maybe a dictionary lookup and possibly regexp matching is some cases (I personally never had to use that for URL dispatch though). If we were to look at a similar approach in a different context, I don't think it would be fair to call a series of if/elifs "ad-hoc logic", so it's the same thing here. But let's go back to bobo, I can see how URL paths derived from file and function names are nice and make sense, but I'm not as thrilled with declaring the app path in a decorator. When looking at it from the perspective of "caller defines when and how the subroutine is called" I see that the entire (and very useful) level of abstraction is gone -- the application path is defined right where the application itself is defined. It's almost like declaring a piece of code and saying "just inject this into file X at line Y" -- not pretty. However, I have to admit, that if taken as an iterative improvement over file/function name it looks very reasonable. > In the original bobo (aka "python object publisher") that I wrote in '96, I > mapped URLs onto object names in modules. Later, I extended this to use > object keys and this grew into a traversal model. There were some > difficulties with this approach: > > - I needed some way to decide which objects should be URL accessible. This > led to some less than optimal rules. > > - The traversal model mapped well onto an object database, but not so well > onto relational models. > > Many people have taken the approach of providing an explicit separate (from > code) mechanism of mapping URLs onto their Python objects. Usually, this > involves having a table mapping URL patterns of some sort onto object > identifiers. I like explicit. :) I like explicit too, and I like decoupled as well :) By giving up the "manual" dispatching to some libraries people seem to dig themselves a hole without even realizing it. There's so little code saved by doing this, that I don't get it -- some of very useful features are given up and it doesn't look like a tradeoff -- just giving control up without a reason. ISTM that the reason is that this "manual dispatch" thing seems more complex than it is in reality. To some extent, various routing libraries make sense because they provide some level of extensibility, you know, like generic functions vs. series of ifs. But given how they are used -- one global routing object usually -- the need for that extensibility wouldn't be there if not this initial design. In my view, this kind of routing also has the same flaw as the one I see in bobo -- tight coupling. Apps know exactly what arguments they want to get and those are directly "plugged" into data output of path pattern used in the URL router. So basically there's a way to do dispatch with things like URLMap from Paste and other similarly minimal dispatch mechanisms that just plug one into another any way you wish and effortlessly and they are pretty much extensible as it gets -- they can be updated from anywhere in code. This is a very simple alternative to the routing libraries that I don't see used much. At the same time the problems with the popular, routing approach make people write more and more of those hoping to fix the problems that are actually inherent to the design. IMO anyway. I guess I'd better give some examples of how I think the URL dispatch "should be done", but I'm spent for today, sorry :) Maybe later, if this discussion will continue. Anyway, that was a long-winded way of asking a question you've already answered. Thanks. Also, love the bobo/bozo naming :) > BTW, Chris McDonough provides a nice comparison of traversal and what he > calls "URL Dispatch" based on a mapping table (Pylons routes) in: > > > http://docs.repoze.org/bfg/narr/urlmapping.html#differences-between-traversal-and-url-dispatch > > One of my goals with bobo is express web applications with Python as much > as practical. While bobo does support the ability to provide an external > mapping, I definitely wanted to be able to express the mapping in the code. > One of the advantages of recreating bobo in the 21st century is that I get > to use Python decorators, which provide a way to be very explicit about > which objects are available to handle URLs. (Other web frameworks use > decorators for this purpose too. Bobo is *not* revolutionary in any way. :) > > I find the route syntax used by Rails and Pylons to be very appealing. It > uses fairly simple path patterns with placeholders. It doesn't use regular > expressions. I don't personally care for the controller+action model used > by Rails and borrowed by Pylons, so, after looking at using Pylon's routes > implementation, which I took a lot of inspiration from, I went with a > slightly different model. Basically, a route maps onto an object and when a > URL matches a route, we call the object. (Of course, there are other > details, but they're covered by the bobo documentation.) > > I hope this helps and that I haven't totally misunderstood your original > question. > > > Jim > > -- > Jim Fulton > Zope Corporation > > > -- Best Regards, Sergey Schetinin http://s3bk.com/ -- S3 Backup http://word-to-html.com/ -- Word to HTML Converter From arw1961 at yahoo.com Thu Jun 18 03:36:09 2009 From: arw1961 at yahoo.com (Aaron Watters) Date: Wed, 17 Jun 2009 18:36:09 -0700 (PDT) Subject: [Web-SIG] Announcing bobo Message-ID: <84843.30450.qm@web32004.mail.mud.yahoo.com> --- On Wed, 6/17/09, Sergey Schetinin wrote: > When considering webapps and what urls they should handle > it seems > like the same should apply -- webapps define contained > blocks of > functionality and the task of placing them somewhere in > URL-space > belongs to the "caller" which in this case would be a > configuration or > serving script or, most often, a parent application. So you seem to be suggesting that a web component should not be aware of its URL in the same sense that an object is not aware of its variable name in the scope of the application that is using the object. Is that right? In particular you should be able to assign a component to any URL in the same sense that you can give an object any name. You should also be able to build relocatable URL trees which can be "mounted" anywhere in the "calling" application suite. Do I catch your meaning correctly? It's not clear to me whether Bobo allows or disallows this (I think whiff, and standard cgi, for two examples, support this sort of url handling). -- Aaron Watters http://aaron.oirt.rutgers.edu/myapp/docs/W1500.whyIsWhiffCool === Emacs Makes A Computer Slow From maluke at gmail.com Thu Jun 18 03:55:17 2009 From: maluke at gmail.com (Sergey Schetinin) Date: Thu, 18 Jun 2009 04:55:17 +0300 Subject: [Web-SIG] Announcing bobo In-Reply-To: <84843.30450.qm@web32004.mail.mud.yahoo.com> References: <84843.30450.qm@web32004.mail.mud.yahoo.com> Message-ID: <116315680906171855r48b57eeeh4d570ad75abe6a40@mail.gmail.com> On 2009-06-18, Aaron Watters wrote: > > > > --- On Wed, 6/17/09, Sergey Schetinin wrote: > > > When considering webapps and what urls they should handle > > it seems > > like the same should apply -- webapps define contained > > blocks of > > functionality and the task of placing them somewhere in > > URL-space > > belongs to the "caller" which in this case would be a > > configuration or > > serving script or, most often, a parent application. > > > So you seem to be suggesting that a web component > should not be aware of its URL in the same sense > that an object is not aware of > its variable name in the scope of the application > that is using the object. Is that right? > > In particular you should be able to assign a > component to any URL in the same sense that you > can give an object any name. You should also > be able to build relocatable URL trees which can > be "mounted" anywhere in the "calling" application > suite. Do I catch your meaning correctly? Spot on. > It's not clear to > me whether Bobo allows or disallows this > (I think whiff, and standard cgi, for two examples, > support this sort of url handling). Generally, I think "allowing" it is not enough, I'd prefer it to be *expected*, not just supported. Certainly if one wants to write their own apps this way there are plenty ways to do that, I'm just a bit sad that the default solution in Python webdev seems to be "bring in inflexible stuff you don't need" (not a stab at anything in particular, just something that seems to be the consensus ATM). I think one of the reasons for that is that you can't have a big website and screencasts to woo the newcomers and "good docs" and whatnot about writing a series of ifs, can you? Unlike the frameworkey stuff. I'd go to the Series-Of-Ifs-CON if there was one, though :) -- Best Regards, Sergey Schetinin http://s3bk.com/ -- S3 Backup http://word-to-html.com/ -- Word to HTML Converter From faassen at startifact.com Thu Jun 18 11:28:51 2009 From: faassen at startifact.com (Martijn Faassen) Date: Thu, 18 Jun 2009 11:28:51 +0200 Subject: [Web-SIG] Announcing bobo In-Reply-To: <116315680906171855r48b57eeeh4d570ad75abe6a40@mail.gmail.com> References: <84843.30450.qm@web32004.mail.mud.yahoo.com> <116315680906171855r48b57eeeh4d570ad75abe6a40@mail.gmail.com> Message-ID: <8928d4e90906180228j46992c56r21cce57c37d66a06@mail.gmail.com> Hey, On Thu, Jun 18, 2009 at 3:55 AM, Sergey Schetinin wrote: [snip] >> ?In particular you should be able to assign a >> ?component to any URL in the same sense that you >> ?can give an object any name. ?You should also >> ?be able to build relocatable URL trees which can >> ?be "mounted" anywhere in the "calling" application >> ?suite. ?Do I catch your meaning correctly? > > Spot on. This is what object traversal (as in Zope) tends to allow. While each individual URL tree (i.e. object structure) might have various expectations concerning relative URLs, they can be combined together by putting the right types of objects together. This allows the composition of larger web apps out of smaller components without there having to be a global map of how URLs map at all. Regards, Martijn From jim at zope.com Thu Jun 18 12:21:26 2009 From: jim at zope.com (Jim Fulton) Date: Thu, 18 Jun 2009 06:21:26 -0400 Subject: [Web-SIG] Announcing bobo In-Reply-To: <116315680906171542g57fd275fi2c8d67c296cc04ac@mail.gmail.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <116315680906160802p3d90c397h6164b23c943ebcb3@mail.gmail.com> <1E0D548A-E378-4A5C-A2EA-07317B4BF9A9@zope.com> <116315680906171542g57fd275fi2c8d67c296cc04ac@mail.gmail.com> Message-ID: <459FA050-84E5-4D09-844E-A338C8B2EAA3@zope.com> (Note that this discussion is getting rather dense. I suggest reading my reply all the way through befor responding to individual points. :) On Jun 17, 2009, at 6:42 PM, Sergey Schetinin wrote: > On 2009-06-17, Jim Fulton wrote: >> On Jun 16, 2009, at 11:02 AM, Sergey Schetinin wrote: >> ... >>> indeed there are quite a few >>> frameworks / components that do this thing and I kind of don't get >>> why >>> people want to write their apps that way. I wonder if Jim or anyone >>> else could explain the rationale behind all these URL routing >>> libraries. Nobody minds calling functions from other functions -- >>> that's basics of programming, but for some reason URL dispatching is >>> seen as something different. Why? >>> >>> This is not a criticism, I just really would like to understand >>> this. >>> >> >> >> Fair enough. I'm not sure I understand your question. You need >> some way >> of mapping URLs onto Python objects that handle them. You can do >> this on a >> case by case basis by inspecting a URL and doing some sort of ad hoc >> dispatch in your application. Is that what you mean by "calling >> functions >> from other functions"? I've found it useful to have a standard >> mechanism >> for this that you can use over and over without reinventing it each >> time. > > I guess didn't state my question properly, sorry. Let me explain what > I meant by "calling functions" analogy. My point is that when we > define a piece of functionality (as a function, class or whatever) we > don't say where to use it. I mean, we may define functions as "take > data from a this argument, process and return" and it's up to the > caller to pass that data into the function, function doesn't say where > that should come from or where in the rest of code should its body be > injected or anything like that. So function is a definition of > functionality and it is being called from somewhere else, the called > should know as little as possible about the caller and its place > relative to other calls its caller makes. At least that seems to be > the advice for good software design. But software still lives in a namespace. You usually assign a function a name in a module or package. It often depends on other functionality being available under specific names. In web applications, we often need to know where other components are in the URL space. OTOH, often a function doesn't depend on it's name and you feel that a web application shouldn't care about it's URL. I get that. :) > When considering webapps and what urls they should handle it seems > like the same should apply -- webapps define contained blocks of > functionality and the task of placing them somewhere in URL-space > belongs to the "caller" which in this case would be a configuration or > serving script or, most often, a parent application. OK, so you expect there to be a URL mapping, typically accomplished via some configuration mechanism outside the code. Most routing systems either require or allow this. > Sure, this > requires inspecting the URL, or as you said, "ad-hoc dispatching". I > think that misrepresents this approach because all it boils down to is > a series of if's, maybe a dictionary lookup and possibly regexp > matching is some cases (I personally never had to use that for URL > dispatch though). If we were to look at a similar approach in a > different context, I don't think it would be fair to call a series of > if/elifs "ad-hoc logic", so it's the same thing here. I wasn't trying to represent what you said. I was just guessing at what you said. So you don't mind routing systems that are configured through routing tables outside the code. (?) > But let's go back to bobo, I can see how URL paths derived from file > and function names are nice and make sense, but I'm not as thrilled > with declaring the app path in a decorator. When looking at it from > the perspective of "caller defines when and how the subroutine is > called" I see that the entire (and very useful) level of abstraction > is gone -- the application path is defined right where the application > itself is defined. It's almost like declaring a piece of code and > saying "just inject this into file X at line Y" -- not pretty. Again, I get that you want to separate URL from the code, but I don't agree with your analogy. This may not matter. Something to note is that the paths used in bobo are often not absolute. If you use subroutes, http://bobo.digicool.com/index.html#subroutes , then the paths used will be relative to a position in a URL tree. In the referenced section, the paths in the Document and Folder resources are relative to the URLs used to access a document or folder. An innovation in bobo, I think, is that it combines routes and traversal ("URL Dispatch" and traversal in http://docs.repoze.org/bfg/narr/urlmapping.html#differences-between-traversal-and-url-dispatch) > However, I have to admit, that if taken as an iterative improvement > over file/function name it looks very reasonable. I'm not sure what you're referring to here. >> In the original bobo (aka "python object publisher") that I wrote >> in '96, I >> mapped URLs onto object names in modules. Later, I extended this >> to use >> object keys and this grew into a traversal model. There were some >> difficulties with this approach: >> >> - I needed some way to decide which objects should be URL >> accessible. This >> led to some less than optimal rules. >> >> - The traversal model mapped well onto an object database, but not >> so well >> onto relational models. >> >> Many people have taken the approach of providing an explicit >> separate (from >> code) mechanism of mapping URLs onto their Python objects. >> Usually, this >> involves having a table mapping URL patterns of some sort onto object >> identifiers. I like explicit. :) > > I like explicit too, and I like decoupled as well :) By giving up the > "manual" dispatching to some libraries people seem to dig themselves a > hole without even realizing it. There's so little code saved by doing > this, that I don't get it -- some of very useful features are given up > and it doesn't look like a tradeoff -- just giving control up without > a reason. ISTM that the reason is that this "manual dispatch" thing > seems more complex than it is in reality. Nothing is given up. You can still configure paths externally if you want. (I'll have more to say on this below.) > To some extent, various routing libraries make sense because they > provide some level of extensibility, you know, like generic functions > vs. series of ifs. But given how they are used -- one global routing > object usually -- the need for that extensibility wouldn't be there if > not this initial design. I don't understand what extensibility you're referring to here or if this has anything to do with your objection to specifying paths in the code. Note that bobo doesn't require a global routing object. Bobo provides various ways of knitting URL trees together by having resources invoke other resources, as is done in the document-tree example referenced above. > In my view, this kind of routing also has the same flaw as the one I > see in bobo -- tight coupling. Apps know exactly what arguments they > want to get I'm confused. Generally, Python functions know what arguments they want to get. What does this have to do with routing? > and those are directly "plugged" into data output of path > pattern used in the URL router. Sorry, I can't parse this. :) > So basically there's a way to do dispatch with things like URLMap from > Paste and other similarly minimal dispatch mechanisms that just plug > one into another any way you wish and effortlessly and they are pretty > much extensible as it gets -- they can be updated from anywhere in > code. Can you explain how you see this as different from: http://bobo.digicool.com/more.html#configured-routes ? > This is a very simple alternative to the routing libraries that > I don't see used much. At the same time the problems with the popular, > routing approach make people write more and more of those hoping to > fix the problems that are actually inherent to the design. IMO anyway. I still don't understand what you perceive these inherent problems to be. On Jun 17, 2009, at 9:55 PM, Sergey Schetinin wrote: > On 2009-06-18, Aaron Watters wrote: >> >> >> >> --- On Wed, 6/17/09, Sergey Schetinin wrote: >> >>> When considering webapps and what urls they should handle >>> it seems >>> like the same should apply -- webapps define contained >>> blocks of >>> functionality and the task of placing them somewhere in >>> URL-space >>> belongs to the "caller" which in this case would be a >>> configuration or >>> serving script or, most often, a parent application. >> >> >> So you seem to be suggesting that a web component >> should not be aware of its URL in the same sense >> that an object is not aware of >> its variable name in the scope of the application >> that is using the object. Is that right? >> >> In particular you should be able to assign a >> component to any URL in the same sense that you >> can give an object any name. You should also >> be able to build relocatable URL trees which can >> be "mounted" anywhere in the "calling" application >> suite. Do I catch your meaning correctly? > > Spot on. > >> It's not clear to >> me whether Bobo allows or disallows this It does. http://bobo.digicool.com/more.html#configured-routes > Generally, I think "allowing" it is not enough, I'd prefer it to be > *expected*, not just supported. To some degree, this is the approach that Zope 3 took, It (strongly) encourages you to separate application implementation from configuration. This was motivated by a well-intentioned desire for the kind of flexibility I think you're advocating. The result was elegant but hard to deal with. I think it's great to have this flexibility when you need it, but in my experience, 99% of web applications don't need this sort of flexibility and the methods needed to support the flexibility become a tax. My design for bobo is based on the assumption that most people don't need a lot of flexibility while some do, where the former is the common case. It tries to make simple applications very easy to create, without making it hard to address more complex requirements. I feel good about bobo's ability to deal with simple applications. Time will tell if it accommodates more complex applications. :) This discussion falls into the larger debate of configuration vs convention and explicit vs implicit. I tend to prefer explicit, but am wary of systems that require a lot of configuration (having built one :). Most systems try to strike some balance, as does bobo. Jim -- Jim Fulton Zope Corporation From robillard.etienne at gmail.com Thu Jun 18 14:30:34 2009 From: robillard.etienne at gmail.com (Etienne Robillard) Date: Thu, 18 Jun 2009 08:30:34 -0400 Subject: [Web-SIG] Announcing bobo In-Reply-To: <459FA050-84E5-4D09-844E-A338C8B2EAA3@zope.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <116315680906160802p3d90c397h6164b23c943ebcb3@mail.gmail.com> <1E0D548A-E378-4A5C-A2EA-07317B4BF9A9@zope.com> <116315680906171542g57fd275fi2c8d67c296cc04ac@mail.gmail.com> <459FA050-84E5-4D09-844E-A338C8B2EAA3@zope.com> Message-ID: <4A3A336A.4030408@gmail.com> Hi, It is suggested that most web frameworks authors aims at a very (wide?) audience and bet that most peoples are bozos, clowns, or idiots. I think this rationale might work in some cases, because users of thoses frameworks indeed might not have all those hard-core technical knowledges about, say, URL routing, WSGI or even schema migration. However, is that the preferred way to design web frameworks or should we assume that the "user" is foremost an intelligent and respectful "developer" ? My hypothesis is that web frameworks can sometimes negatively influence a programmer efficiency to resolve a simple programming problem. I think this is particulary true when web frameworks are made restrictive: the available solutions are largely influenced by/for popular or community-accepted scenarios, thus shadowing or putting in the dark unconventional solutions. In a sense, this is perhaps an ethical problem for web framework authors and not very related to web programming in general.. Lastly, I don't know really if most people have "complex requirements". In my experience however "basic requirements" are still largely not understood by popular "full-stack" web frameworks. Best regards, Etienne Jim Fulton wrote: > To some degree, this is the approach that Zope 3 took, It (strongly) > encourages you to separate application implementation from > configuration. This was motivated by a well-intentioned desire for the > kind of flexibility I think you're advocating. The result was elegant > but hard to deal with. I think it's great to have this flexibility when > you need it, but in my experience, 99% of web applications don't need > this sort of flexibility and the methods needed to support the > flexibility become a tax. > > My design for bobo is based on the assumption that most people don't > need a lot of flexibility while some do, where the former is the common > case. It tries to make simple applications very easy to create, without > making it hard to address more complex requirements. I feel good about > bobo's ability to deal with simple applications. Time will tell if it > accommodates more complex applications. :) > > This discussion falls into the larger debate of configuration vs > convention and explicit vs implicit. I tend to prefer explicit, but am > wary of systems that require a lot of configuration (having built one > :). Most systems try to strike some balance, as does bobo. > > Jim > > -- > Jim Fulton > Zope Corporation > > > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: > http://mail.python.org/mailman/options/web-sig/robillard.etienne%40gmail.com > > -- Etienne Robillard Green Tea Hackers Club Blog: PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC From maluke at gmail.com Fri Jun 19 01:46:54 2009 From: maluke at gmail.com (Sergey Schetinin) Date: Fri, 19 Jun 2009 02:46:54 +0300 Subject: [Web-SIG] Announcing bobo In-Reply-To: <459FA050-84E5-4D09-844E-A338C8B2EAA3@zope.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <116315680906160802p3d90c397h6164b23c943ebcb3@mail.gmail.com> <1E0D548A-E378-4A5C-A2EA-07317B4BF9A9@zope.com> <116315680906171542g57fd275fi2c8d67c296cc04ac@mail.gmail.com> <459FA050-84E5-4D09-844E-A338C8B2EAA3@zope.com> Message-ID: <116315680906181646s66b452eexe7dbf932b54b5299@mail.gmail.com> On 2009-06-18, Jim Fulton wrote: > (Note that this discussion is getting rather dense. I suggest reading my > reply all the way through befor responding to individual points. :) > > > On Jun 17, 2009, at 6:42 PM, Sergey Schetinin wrote: > > > > On 2009-06-17, Jim Fulton wrote: > > > > > On Jun 16, 2009, at 11:02 AM, Sergey Schetinin wrote: > > > ... > > > > > > > indeed there are quite a few > > > > frameworks / components that do this thing and I kind of don't get why > > > > people want to write their apps that way. I wonder if Jim or anyone > > > > else could explain the rationale behind all these URL routing > > > > libraries. Nobody minds calling functions from other functions -- > > > > that's basics of programming, but for some reason URL dispatching is > > > > seen as something different. Why? > > > > > > > > This is not a criticism, I just really would like to understand this. > > > > > > > > > > > > > > > > > Fair enough. I'm not sure I understand your question. You need some > way > > > of mapping URLs onto Python objects that handle them. You can do this > on a > > > case by case basis by inspecting a URL and doing some sort of ad hoc > > > dispatch in your application. Is that what you mean by "calling > functions > > > from other functions"? I've found it useful to have a standard > mechanism > > > for this that you can use over and over without reinventing it each > time. > > > > > > > I guess didn't state my question properly, sorry. Let me explain what > > I meant by "calling functions" analogy. My point is that when we > > define a piece of functionality (as a function, class or whatever) we > > don't say where to use it. I mean, we may define functions as "take > > data from a this argument, process and return" and it's up to the > > caller to pass that data into the function, function doesn't say where > > that should come from or where in the rest of code should its body be > > injected or anything like that. So function is a definition of > > functionality and it is being called from somewhere else, the called > > should know as little as possible about the caller and its place > > relative to other calls its caller makes. At least that seems to be > > the advice for good software design. > > > > But software still lives in a namespace. You usually assign a function a > name in a module or package. It often depends on other functionality being > available under specific names. In web applications, we often need to know > where other components are in the URL space. OTOH, often a function > doesn't depend on it's name and you feel that a web application shouldn't > care about it's URL. I get that. :) Well, the app needs to know where its children are located and it controls that. If the app needs to know its siblings' paths I think that should be parametrized. That way, the parent can set up its components that they know where to find each other but there's still flexibility to it. Conventional paths work too, but there's plenty of code reuse lost as a result. Imagine a web forum app. The top level app is the topic list, there are "discussion thread" apps that it exposes at some paths, those apps would want to know the URL of the topic list so that they can link to it. They may assume that it's one level up or they might actually have a way to define where they are. In the latter case when the forum app created its children, it would have let the children know that it is their parent. Now consider someone writing a blog app for example, there are apps that represent specific blog entries and it would be nice to be able to reuse the "forum thread" component and expose it at a subpath, for example as /blog/entry-name/discussion. If we were not just using conventional paths in the implementation of that thread app we could just tell it that it should refer to its parent as a "blog entry X" or something. The point is that decoupling is a good enough thing to be worth at least few extra lines of code. If the forum app was using some routing library, things would be much more complicated -- it's no longer a matter of a few lines of code but a major PITA. > > > When considering webapps and what urls they should handle it seems > > like the same should apply -- webapps define contained blocks of > > functionality and the task of placing them somewhere in URL-space > > belongs to the "caller" which in this case would be a configuration or > > serving script or, most often, a parent application. > > > > OK, so you expect there to be a URL mapping, typically accomplished via > some configuration mechanism outside the code. Most routing systems either > require or allow this. > > > > Sure, this > > requires inspecting the URL, or as you said, "ad-hoc dispatching". I > > think that misrepresents this approach because all it boils down to is > > a series of if's, maybe a dictionary lookup and possibly regexp > > matching is some cases (I personally never had to use that for URL > > dispatch though). If we were to look at a similar approach in a > > different context, I don't think it would be fair to call a series of > > if/elifs "ad-hoc logic", so it's the same thing here. > > > > I wasn't trying to represent what you said. I was just guessing at what you > said. So you don't mind routing systems that are configured through routing > tables outside the code. (?) As long as all the routing system does is match a prefix, no parameter extraction, no regexp nonsense -- it's ok. However that makes it so small nobody would bother calling it anything, certainly not "routing system". Regarding configuration of these things -- I don't see any need to bring in anything but straight Python for this, but that's irrelevant. > > But let's go back to bobo, I can see how URL paths derived from file > > and function names are nice and make sense, but I'm not as thrilled > > with declaring the app path in a decorator. When looking at it from > > the perspective of "caller defines when and how the subroutine is > > called" I see that the entire (and very useful) level of abstraction > > is gone -- the application path is defined right where the application > > itself is defined. It's almost like declaring a piece of code and > > saying "just inject this into file X at line Y" -- not pretty. > > > > Again, I get that you want to separate URL from the code, but I don't agree > with your analogy. This may not matter. > > Something to note is that the paths used in bobo are often not absolute. > If you use subroutes, > http://bobo.digicool.com/index.html#subroutes, then the > paths used will be relative to a position in a URL tree. In the referenced > section, the paths in the Document and Folder resources are relative to the > URLs used to access a document or folder. > > An innovation in bobo, I think, is that it combines routes and traversal > ("URL Dispatch" and traversal in > http://docs.repoze.org/bfg/narr/urlmapping.html#differences-between-traversal-and-url-dispatch) > > > > > However, I have to admit, that if taken as an iterative improvement > > over file/function name it looks very reasonable. > > > > I'm not sure what you're referring to here. > I meant that bobo decorators seem a natural development to a system that would assign URLs based on file and function names. > > > > > > In the original bobo (aka "python object publisher") that I wrote in > '96, I > > > mapped URLs onto object names in modules. Later, I extended this to use > > > object keys and this grew into a traversal model. There were some > > > difficulties with this approach: > > > > > > - I needed some way to decide which objects should be URL accessible. > This > > > led to some less than optimal rules. > > > > > > - The traversal model mapped well onto an object database, but not so > well > > > onto relational models. > > > > > > Many people have taken the approach of providing an explicit separate > (from > > > code) mechanism of mapping URLs onto their Python objects. Usually, > this > > > involves having a table mapping URL patterns of some sort onto object > > > identifiers. I like explicit. :) > > > > > > > I like explicit too, and I like decoupled as well :) By giving up the > > "manual" dispatching to some libraries people seem to dig themselves a > > hole without even realizing it. There's so little code saved by doing > > this, that I don't get it -- some of very useful features are given up > > and it doesn't look like a tradeoff -- just giving control up without > > a reason. ISTM that the reason is that this "manual dispatch" thing > > seems more complex than it is in reality. > > > > Nothing is given up. You can still configure paths externally if you want. > (I'll have more to say on this below.) > > > > To some extent, various routing libraries make sense because they > > provide some level of extensibility, you know, like generic functions > > vs. series of ifs. But given how they are used -- one global routing > > object usually -- the need for that extensibility wouldn't be there if > > not this initial design. > > > > I don't understand what extensibility you're referring to here or if this > has anything to do with your objection to specifying paths in the code. > > Note that bobo doesn't require a global routing object. Bobo provides > various ways of knitting URL trees together by having resources invoke other > resources, as is done in the document-tree example referenced above. > > > > In my view, this kind of routing also has the same flaw as the one I > > see in bobo -- tight coupling. Apps know exactly what arguments they > > want to get > > > > I'm confused. Generally, Python functions know what arguments they want to > get. What does this have to do with routing? > > > > and those are directly "plugged" into data output of path > > pattern used in the URL router. > > > > Sorry, I can't parse this. :) The bobo apps consume data output of bobo url parser, which is a restriction that has nothing to do with the webapp functionality itself. It might make sense to use some data from a parent webapp, but it would need to be passed in a roundabout way. That's tight coupling I was referring to. Take the "forum topic" as blog entry discussion -- it's non-trivial if the topic id in the database is taken from the URL path. There are all kinds of reuse possibilities lost just by collapsing this level of abstraction (path -> app mapping). Even if there are ways to reconfigure the default mapping -- one ends up working against all the routing stuff original developers of the component put in, unwinding the tangle of tightly coupled implementation. Which is usually not worth it. > > So basically there's a way to do dispatch with things like URLMap from > > Paste and other similarly minimal dispatch mechanisms that just plug > > one into another any way you wish and effortlessly and they are pretty > > much extensible as it gets -- they can be updated from anywhere in > > code. > > > > Can you explain how you see this as different from: > http://bobo.digicool.com/more.html#configured-routes > ? It's bobo-specific. How would one use those apps from non-bobo app? How would one put non-bobo app into those mappings? I suppose there are ways to unwrap and rewrap things, but wouldn't it be nice if we could finally just do things like from somebody_else.forum import ForumApp urlmap['/forum'] = ForumApp(db_config=...) The point is that we can, thanks to WSGI, only if people were writing their stuff the boring way and not build walled gardens that make one thing easy and a thousand others impossible. This sounds accusatory, but please don't take it that way. I'm just voicing my opinion on the problem in python webdev that annoys many people I believe. Unless you share that feeling there's no need to take it into account. > > > This is a very simple alternative to the routing libraries that > > I don't see used much. At the same time the problems with the popular, > > routing approach make people write more and more of those hoping to > > fix the problems that are actually inherent to the design. IMO anyway. > > > > I still don't understand what you perceive these inherent problems to be. > > > On Jun 17, 2009, at 9:55 PM, Sergey Schetinin wrote: > > > > On 2009-06-18, Aaron Watters wrote: > > > > > > > > > > > > > > --- On Wed, 6/17/09, Sergey Schetinin wrote: > > > > > > > > > > When considering webapps and what urls they should handle > > > > it seems > > > > like the same should apply -- webapps define contained > > > > blocks of > > > > functionality and the task of placing them somewhere in > > > > URL-space > > > > belongs to the "caller" which in this case would be a > > > > configuration or > > > > serving script or, most often, a parent application. > > > > > > > > > > > > > So you seem to be suggesting that a web component > > > should not be aware of its URL in the same sense > > > that an object is not aware of > > > its variable name in the scope of the application > > > that is using the object. Is that right? > > > > > > In particular you should be able to assign a > > > component to any URL in the same sense that you > > > can give an object any name. You should also > > > be able to build relocatable URL trees which can > > > be "mounted" anywhere in the "calling" application > > > suite. Do I catch your meaning correctly? > > > > > > > Spot on. > > > > > > > It's not clear to > > > me whether Bobo allows or disallows this > > > > > > > It does. > > http://bobo.digicool.com/more.html#configured-routes > > > > Generally, I think "allowing" it is not enough, I'd prefer it to be > > *expected*, not just supported. > > > > To some degree, this is the approach that Zope 3 took, It (strongly) > encourages you to separate application implementation from configuration. > This was motivated by a well-intentioned desire for the kind of flexibility > I think you're advocating. The result was elegant but hard to deal with. I > think it's great to have this flexibility when you need it, but in my > experience, 99% of web applications don't need this sort of flexibility and > the methods needed to support the flexibility become a tax. I suppose the reason is that this separating the configuration was implemented as yet more stuff. My idea of configurable webapps is to pass configuration at instantiation. No extra code. IMO, the more complex configuration systems are needed when there's a need to penetrate though levels of framework crust (hello tight coupling) which is another thing I argue shouldn't be there. > My design for bobo is based on the assumption that most people don't need a > lot of flexibility while some do, where the former is the common case. It > tries to make simple applications very easy to create, without making it > hard to address more complex requirements. I feel good about bobo's ability > to deal with simple applications. Time will tell if it accommodates more > complex applications. :) As I said, your reply did explain how you see bobo and its purpose, and it makes complete sense. None of what I said is specifically about bobo, just general trends in python webdev. > This discussion falls into the larger debate of configuration vs convention > and explicit vs implicit. I tend to prefer explicit, but am wary of systems > that require a lot of configuration (having built one :). Most systems try > to strike some balance, as does bobo. > > > Jim > > -- > Jim Fulton > Zope Corporation > > > -- Best Regards, Sergey Schetinin http://s3bk.com/ -- S3 Backup http://word-to-html.com/ -- Word to HTML Converter From pje at telecommunity.com Fri Jun 19 02:14:40 2009 From: pje at telecommunity.com (P.J. Eby) Date: Thu, 18 Jun 2009 20:14:40 -0400 Subject: [Web-SIG] Announcing bobo In-Reply-To: <116315680906181646s66b452eexe7dbf932b54b5299@mail.gmail.co m> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <116315680906160802p3d90c397h6164b23c943ebcb3@mail.gmail.com> <1E0D548A-E378-4A5C-A2EA-07317B4BF9A9@zope.com> <116315680906171542g57fd275fi2c8d67c296cc04ac@mail.gmail.com> <459FA050-84E5-4D09-844E-A338C8B2EAA3@zope.com> <116315680906181646s66b452eexe7dbf932b54b5299@mail.gmail.com> Message-ID: <20090619001146.97CD83A404D@sparrow.telecommunity.com> At 02:46 AM 6/19/2009 +0300, Sergey Schetinin wrote: >but wouldn't it be nice if we could finally just do >things like > >from somebody_else.forum import ForumApp >urlmap['/forum'] = ForumApp(db_config=...) The Folder example in the bobo docs does basically that, actually. I think perhaps you've misunderstood what Bobo does; it not only provides a framework for fixed mappings, it also provides the basis for doing flexible mappings. In fact, that's what subroute parameters are for. So you could implement your urlmap above more or less like this: @bobo.scan_class class UrlMap(dict): @bobo.subroute('/:name') def subitem(self, name): try: return self[name] except KeyError: ... Although you'd probably need a __setitem__ that split on '/' and created sub-UrlMap instances if they don't already exist, but you get the idea I hope. Bobo's basic design, IOW, allows you to make pretty much any other design you like, but is very simple for relatively straightforward subtrees. Also, AFAICT, *all* bobo paths are relative paths treating the enclosing module or instance as a mount point, and there is nothing stopping you from mounting such objects at whatever locations you like. What bobo lacks (that would be nice) is a way to figure out what URL to address a specified object by, since the very flexibility that allows objects to have more than one name, also means that there is no obvious way to find what name to use for an object. From maluke at gmail.com Fri Jun 19 02:29:50 2009 From: maluke at gmail.com (Sergey Schetinin) Date: Fri, 19 Jun 2009 03:29:50 +0300 Subject: [Web-SIG] Announcing bobo In-Reply-To: <20090619001146.97CD83A404D@sparrow.telecommunity.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <116315680906160802p3d90c397h6164b23c943ebcb3@mail.gmail.com> <1E0D548A-E378-4A5C-A2EA-07317B4BF9A9@zope.com> <116315680906171542g57fd275fi2c8d67c296cc04ac@mail.gmail.com> <459FA050-84E5-4D09-844E-A338C8B2EAA3@zope.com> <116315680906181646s66b452eexe7dbf932b54b5299@mail.gmail.com> <20090619001146.97CD83A404D@sparrow.telecommunity.com> Message-ID: <116315680906181729r57a220acj282658995c0e7121@mail.gmail.com> On 2009-06-19, P.J. Eby wrote: > At 02:46 AM 6/19/2009 +0300, Sergey Schetinin wrote: > > > but wouldn't it be nice if we could finally just do > > things like > > > > from somebody_else.forum import ForumApp > > urlmap['/forum'] = ForumApp(db_config=...) > > > > The Folder example in the bobo docs does basically that, actually. > > I think perhaps you've misunderstood what Bobo does; it not only provides a > framework for fixed mappings, it also provides the basis for doing flexible > mappings. In fact, that's what subroute parameters are for. > > So you could implement your urlmap above more or less like this: > > @bobo.scan_class > class UrlMap(dict): > > @bobo.subroute('/:name') > def subitem(self, name): > try: > return self[name] > except KeyError: > ... Oh wait, I meant urlmap to be from paste.urlmap import URLMap urlmap = URLMap() ... Should have written that in the first place, sorry. > Although you'd probably need a __setitem__ that split on '/' and created > sub-UrlMap instances if they don't already exist, but you get the idea I > hope. > > Bobo's basic design, IOW, allows you to make pretty much any other design > you like, but is very simple for relatively straightforward subtrees. > > Also, AFAICT, *all* bobo paths are relative paths treating the enclosing > module or instance as a mount point, and there is nothing stopping you from > mounting such objects at whatever locations you like. I think they are, but that's not separate enough from implementation for me :) The problem is that if one were to actually separate this mapping completely there's suddenly nothing to the library anymore :) (I'm exaggerating, but it's not that far from truth). > What bobo lacks (that would be nice) is a way to figure out what URL to > address a specified object by, since the very flexibility that allows > objects to have more than one name, also means that there is no obvious way > to find what name to use for an object. > > -- Best Regards, Sergey Schetinin http://s3bk.com/ -- S3 Backup http://word-to-html.com/ -- Word to HTML Converter From maluke at gmail.com Fri Jun 19 02:36:45 2009 From: maluke at gmail.com (Sergey Schetinin) Date: Fri, 19 Jun 2009 03:36:45 +0300 Subject: [Web-SIG] Announcing bobo In-Reply-To: <20090619001146.97CD83A404D@sparrow.telecommunity.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <116315680906160802p3d90c397h6164b23c943ebcb3@mail.gmail.com> <1E0D548A-E378-4A5C-A2EA-07317B4BF9A9@zope.com> <116315680906171542g57fd275fi2c8d67c296cc04ac@mail.gmail.com> <459FA050-84E5-4D09-844E-A338C8B2EAA3@zope.com> <116315680906181646s66b452eexe7dbf932b54b5299@mail.gmail.com> <20090619001146.97CD83A404D@sparrow.telecommunity.com> Message-ID: <116315680906181736u31b32ee9g495b2dca236a55d7@mail.gmail.com> On 2009-06-19, P.J. Eby wrote: > So you could implement your urlmap above more or less like this: > > @bobo.scan_class > class UrlMap(dict): > > @bobo.subroute('/:name') > def subitem(self, name): > try: > return self[name] > except KeyError: > ... > > Although you'd probably need a __setitem__ that split on '/' and created > sub-UrlMap instances if they don't already exist, but you get the idea I > hope. Also, I actually have my version of URLMap (with dispatching on host and protocol removed and with indexing instead of prefix scan): http://code.google.com/p/pasteob/source/browse/trunk/pasteob/__init__.py#170 PathMap.__getitem__ method can be ignored as it's used for inspection only, not when actually dispatching. From jim at zope.com Fri Jun 19 16:05:04 2009 From: jim at zope.com (Jim Fulton) Date: Fri, 19 Jun 2009 10:05:04 -0400 Subject: [Web-SIG] Announcing bobo In-Reply-To: <4A3A336A.4030408@gmail.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <116315680906160802p3d90c397h6164b23c943ebcb3@mail.gmail.com> <1E0D548A-E378-4A5C-A2EA-07317B4BF9A9@zope.com> <116315680906171542g57fd275fi2c8d67c296cc04ac@mail.gmail.com> <459FA050-84E5-4D09-844E-A338C8B2EAA3@zope.com> <4A3A336A.4030408@gmail.com> Message-ID: On Jun 18, 2009, at 8:30 AM, Etienne Robillard wrote: > It is suggested that most web frameworks authors aims at a very > (wide?) > audience and bet that most peoples are bozos, clowns, or idiots. I > think > this rationale might work in some cases, because users of thoses > frameworks indeed might not have all those hard-core technical > knowledges about, say, URL routing, WSGI or even schema migration. I won't speak for other frameworks, but bobo's target audience is "idiots" in the same sense that the popular "idiot's guides" and "dummies" books are aimed at idiots and dummies. Of course, these books and bobo aren't *really* aimed at idiots or dummies (or bozos or clowns -- well maybe clowns). They're aimed at people who don't really want hard-core knowledge. They want to learn something quickly so that they can get things done. In my experience, many people writing web applications want to focus on their applications. They aren't really interested in nitty-gritty plumbing details, they just want to get their application working well. For many people, web development isn't their full time job. It's one of many things they do and they don't want to have a lot to remember or re-learn. Many full-time web developers have more interesting things to focus on that publishing mechanics. I know I do. Jim -- Jim Fulton Zope Corporation From chris at simplistix.co.uk Fri Jun 19 17:27:26 2009 From: chris at simplistix.co.uk (Chris Withers) Date: Fri, 19 Jun 2009 16:27:26 +0100 Subject: [Web-SIG] Announcing bobo In-Reply-To: <72B213C3-2F43-4602-8E20-3311289D4C97@zope.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A38B382.3050700@simplistix.co.uk> <72B213C3-2F43-4602-8E20-3311289D4C97@zope.com> Message-ID: <4A3BAE5E.2070909@simplistix.co.uk> Jim Fulton wrote: > > I'm working on another project, bozo, to facilitate using bobo resources > in Zope and use Zope components with bobo applications. Cool, hopefully bozo can be used for non-Zope applications too :-) >> and/or in a non-decorator fashion? > > Bobo provides a mechanism to express routes separately from your Python > code. Oh, I missed this... where is this documented? > Of course, Pylons also provides a route scheme that doesn't use > decorators. yeah, but I have an inkling that I'll prefer bobo's routing ;-) (particularly if I can put the routes in a persistent storage mechanism rather than having to have them in code or config files) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From jim at zope.com Fri Jun 19 17:34:49 2009 From: jim at zope.com (Jim Fulton) Date: Fri, 19 Jun 2009 11:34:49 -0400 Subject: [Web-SIG] Announcing bobo In-Reply-To: <4A3BAE5E.2070909@simplistix.co.uk> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A38B382.3050700@simplistix.co.uk> <72B213C3-2F43-4602-8E20-3311289D4C97@zope.com> <4A3BAE5E.2070909@simplistix.co.uk> Message-ID: On Jun 19, 2009, at 11:27 AM, Chris Withers wrote: > Jim Fulton wrote: >> I'm working on another project, bozo, to facilitate using bobo >> resources in Zope and use Zope components with bobo applications. > > Cool, hopefully bozo can be used for non-Zope applications too :-) bozo.component will be. It will provide a type-based resource- dispatch mechanism for bobo applications using zope.component. Of course, zope.component can be used for non-Zope-based applications. bozo.reuse is specifically geared to zope/bobo interoperability. Discussion on that should happen over on the zope-dev list. >>> and/or in a non-decorator fashion? >> Bobo provides a mechanism to express routes separately from your >> Python code. > > Oh, I missed this... where is this documented? http://bobo.digicool.com/more.html#configured-routes Jim -- Jim Fulton Zope Corporation From graham.dumpleton at gmail.com Sat Jun 20 07:42:17 2009 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Sat, 20 Jun 2009 15:42:17 +1000 Subject: [Web-SIG] Announcing bobo In-Reply-To: References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <116315680906160802p3d90c397h6164b23c943ebcb3@mail.gmail.com> <1E0D548A-E378-4A5C-A2EA-07317B4BF9A9@zope.com> <116315680906171542g57fd275fi2c8d67c296cc04ac@mail.gmail.com> <459FA050-84E5-4D09-844E-A338C8B2EAA3@zope.com> <4A3A336A.4030408@gmail.com> Message-ID: <88e286470906192242g9b4c98cvbc019a057c9c25c9@mail.gmail.com> 2009/6/20 Jim Fulton : > > On Jun 18, 2009, at 8:30 AM, Etienne Robillard wrote: >> >> It is suggested that most web frameworks authors aims at a very (wide?) >> audience and bet that most peoples are bozos, clowns, or idiots. I think >> this rationale might work in some cases, because users of thoses >> frameworks indeed might not have all those hard-core technical >> knowledges about, say, URL routing, WSGI or even schema migration. > > > I won't speak for other frameworks, but bobo's target audience is "idiots" > in the same sense that the popular "idiot's guides" and "dummies" books are > aimed at idiots and dummies. ?Of course, these books and bobo aren't > *really* aimed at idiots or dummies (or bozos or clowns -- well maybe > clowns). They're aimed at people who don't really want hard-core knowledge. > They want to learn something quickly so that they can get things done. ?In > my experience, many people writing web applications want to focus on their > applications. ?They aren't really interested in nitty-gritty plumbing > details, they just want to get their application working well. ?For many > people, web development isn't their full time job. ?It's one of many things > they do and they don't want to have a lot to remember or re-learn. Many > full-time web developers have more interesting things to focus on that > publishing mechanics. I know I do. Personally I believe 'bobo' would be a good alternative for the people who currently get drawn to the simplicity of 'publisher' in mod_python, especially if things are setup within Apache such that all they need to do is drop the bobo script file into their existing Apache document directories like they can now with 'publisher'. This way all the high level URL dispatch to specific bobo scripts is done for them and they don't have to care about it. With the provision of the request object, they can just get on with coding their application, adding any custom URL dispatching within the script file as needs be. Work in a way of automatically handling application process reloading when they make changes, and you start to approach the ease of doing things that PHP developers are so used to, and for which they cannot work out why Python is so hard in comparison. Graham From ctb at msu.edu Tue Jun 16 19:53:17 2009 From: ctb at msu.edu (C. Titus Brown) Date: Tue, 16 Jun 2009 10:53:17 -0700 Subject: [Web-SIG] Announcing bobo In-Reply-To: <4A37D8B2.7050600@gmail.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <8928d4e90906160819s56f7aaa2tbb65244cb7dbc05@mail.gmail.com> <4A37C521.4080708@gmail.com> <53039e7b0906160939ud3f3d50v917532d8dc6b81cd@mail.gmail.com> <4A37D8B2.7050600@gmail.com> Message-ID: <20090616175317.GA8903@idyll.org> Hey all, I think we can pretty safely ignore Etienne as either a troll or a rather rude person. Has anyone looked at Bobo yet? I'd be interested in comparisons between it and Quixote, which is what I've mostly used in the past. I believe that Bobo begat Zope, which begat Quixote as (I thought) an attempt to return to Bobo-style programming, and so I'm curious about what sort of choices Bobo has made. thanks, --titus -- C. Titus Brown, ctb at msu.edu From jason at briggs.net.nz Tue Jun 16 21:33:41 2009 From: jason at briggs.net.nz (Jason Briggs) Date: Tue, 16 Jun 2009 20:33:41 +0100 Subject: [Web-SIG] Announcing bobo References: Message-ID: <5154E834-8723-4EAF-A59C-8F72812219A0@briggs.net.nz> Typical. The first time I make the effort to reply to the list, I reply to sender rather than to list. I'm a muppet. Anyway, reply below.... Begin forwarded message: > From: Jason Briggs > Date: 16 June 2009 20:04:46 BST > To: Etienne Robillard > Subject: Re: [Web-SIG] Announcing bobo > > "Ad hominen" isn't using latin to look smart. It's a common-term > description of a type of argument... which just happens to be latin. > > You probably already knew that, but based on your previous emails I > wasn't sure -- so just for your info. > > J > > > > On 16 Jun 2009, at 18:38, Etienne Robillard wrote: > >> >> I recommend you quit using latin to try looking smarter. ;) >> >> I do I'm discouraged to see so much adversion between Python web >> frameworks fighting for the same goal. >> >> To say that "you don't to be a genius" implies that all other web >> frameworks are made for geniuses, which is probably offending for >> less-mature projects. Of courses I might have misread or taking for >> granted that this was a totally new project.. >> >> My apologies then to Jim... ;) >> >> Regards, >> >> Etienne >> >>> This feels like an ad hominem argument which is both surprising and >>> unproductive. >>> >>> Nathan >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at vanguardistas.net Thu Jun 18 08:54:51 2009 From: brian at vanguardistas.net (Brian Sutherland) Date: Thu, 18 Jun 2009 08:54:51 +0200 Subject: [Web-SIG] Announcing bobo In-Reply-To: <116315680906171542g57fd275fi2c8d67c296cc04ac@mail.gmail.com> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A37B186.6090903@gmail.com> <116315680906160802p3d90c397h6164b23c943ebcb3@mail.gmail.com> <1E0D548A-E378-4A5C-A2EA-07317B4BF9A9@zope.com> <116315680906171542g57fd275fi2c8d67c296cc04ac@mail.gmail.com> Message-ID: <20090618065451.GG6755@Boo.lan> On Thu, Jun 18, 2009 at 01:42:32AM +0300, Sergey Schetinin wrote: > But let's go back to bobo, I can see how URL paths derived from file > and function names are nice and make sense, but I'm not as thrilled > with declaring the app path in a decorator. When looking at it from > the perspective of "caller defines when and how the subroutine is > called" I see that the entire (and very useful) level of abstraction > is gone -- the application path is defined right where the application > itself is defined. It's almost like declaring a piece of code and > saying "just inject this into file X at line Y" -- not pretty. > However, I have to admit, that if taken as an iterative improvement > over file/function name it looks very reasonable. Seems like this style of declaring routes may be more like what you want: http://bobo.digicool.com/more.html#configured-routes -- Brian Sutherland From arw1961 at yahoo.com Mon Jun 22 01:06:59 2009 From: arw1961 at yahoo.com (Aaron Watters) Date: Sun, 21 Jun 2009 16:06:59 -0700 (PDT) Subject: [Web-SIG] Announcing bobo Message-ID: <147034.70027.qm@web32008.mail.mud.yahoo.com> [whoops: graham, I meant to 'reply all', sorry for repeat] --- On Sat, 6/20/09, Graham Dumpleton wrote > Personally I believe 'bobo' would be a good alternative for > the people > who currently get drawn to the simplicity of 'publisher' It's not clear to me whether bobo has the "just drop a file or directory in the parent directory and it works" property like PHP, modpy/publisher, vanilla CGI, and WHIFF do. Does it, Jim? I implemented WHIFF primarily because I wanted this property (and some others). WHIFF generalizes the "droppable file or directory" concept to allow an "application" to implement a fragment of a page or a middleware easily as well. Please see http://aaron.oirt.rutgers.edu/myapp/docs/W1100_1050.Grading http://aaron.oirt.rutgers.edu/myapp/docs/W1100_1200.wwiki for examples of how this works in WHIFF. -- Aaron Watters === % man woman Segmentation fault. From graham.dumpleton at gmail.com Mon Jun 22 01:29:16 2009 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Mon, 22 Jun 2009 09:29:16 +1000 Subject: [Web-SIG] Announcing bobo In-Reply-To: <147034.70027.qm@web32008.mail.mud.yahoo.com> References: <147034.70027.qm@web32008.mail.mud.yahoo.com> Message-ID: <88e286470906211629r7d23652cge5c024fe4b81b7b6@mail.gmail.com> 2009/6/22 Aaron Watters : > > [whoops: graham, I meant to 'reply all', sorry for repeat] > > --- On Sat, 6/20/09, Graham Dumpleton wrote >> Personally I believe 'bobo' would be a good alternative for >> the people >> who currently get drawn to the simplicity of 'publisher' > > It's not clear to me whether bobo has > the "just drop a file or directory in > the parent directory and it works" > property like PHP, modpy/publisher, vanilla CGI, > and WHIFF do. > > Does it, Jim? I already emailed Jim separately some days back to show exactly how this can be done using Apache/mod_wsgi 3.0. I was going to blog about how it is done, but been tied up on getting some other stuff out of the way. In other words, bobo doesn't need to support that sort of mechanism directly as Apache/mod_wsgi makes it a reasonably trivial thing to do. Graham > I implemented WHIFF primarily > because I wanted this property (and some others). > > WHIFF generalizes the "droppable file or directory" concept > to allow an "application" to implement a fragment of a page > or a middleware easily as well. > > Please see > > http://aaron.oirt.rutgers.edu/myapp/docs/W1100_1050.Grading > http://aaron.oirt.rutgers.edu/myapp/docs/W1100_1200.wwiki > > for examples of how this works in WHIFF. From arw1961 at yahoo.com Mon Jun 22 02:05:52 2009 From: arw1961 at yahoo.com (Aaron Watters) Date: Sun, 21 Jun 2009 17:05:52 -0700 (PDT) Subject: [Web-SIG] Announcing bobo Message-ID: <529426.3815.qm@web32005.mail.mud.yahoo.com> --- On Sun, 6/21/09, Graham Dumpleton wrote: > In other words, bobo doesn't need to support that sort of > mechanism > directly as Apache/mod_wsgi makes it a reasonably trivial > thing to do. Nice! Ideally the same mechanism should work for other WSGI implementations, and the same mechanism should also work for "dropping" (fragments of) applications into another bobo application. For example you can "drop in" middleware support for amCharts flash charts into any whiff application by adding an import statement to an __init__.py file, as described here http://aaron.oirt.rutgers.edu/myapp/amcharts/doc -- Aaron Watters === % if i had a ( for every $ bush spent, how many ('s would i have? too many ('s. From jim at zope.com Mon Jun 22 11:32:04 2009 From: jim at zope.com (Jim Fulton) Date: Mon, 22 Jun 2009 05:32:04 -0400 Subject: [Web-SIG] Announcing bobo In-Reply-To: <147034.70027.qm@web32008.mail.mud.yahoo.com> References: <147034.70027.qm@web32008.mail.mud.yahoo.com> Message-ID: <728A4901-49D4-4C27-874C-E72AB9A5D545@zope.com> On Jun 21, 2009, at 7:06 PM, Aaron Watters wrote: > > [whoops: graham, I meant to 'reply all', sorry for repeat] > > --- On Sat, 6/20/09, Graham Dumpleton > wrote >> Personally I believe 'bobo' would be a good alternative for >> the people >> who currently get drawn to the simplicity of 'publisher' > > It's not clear to me whether bobo has > the "just drop a file or directory in > the parent directory and it works" > property like PHP, modpy/publisher, vanilla CGI, > and WHIFF do. > > Does it, Jim? No more than any other WSGI application does, except that it is pretty light weight, so it is practical to run it using CGI. As Graham pointed out, he's created a cool extension to mod_wsgi that makes it easy to "drop in" bobo source files. I designed bobo so that source files can be pretty self contained (e.g. not requiring external configuration) which probably helps make this story work well. Jim -- Jim Fulton Zope Corporation From alain.poirier at net-ng.com Fri Jun 26 12:52:14 2009 From: alain.poirier at net-ng.com (Alain Poirier) Date: Fri, 26 Jun 2009 12:52:14 +0200 Subject: [Web-SIG] [ANN] Nagare 0.2.0 - Components and continuation-based web framework Message-ID: <200906261252.14884.alain.poirier@net-ng.com> Hi all, The version 0.2.0 of the Nagare web framework is now released ! To read about its features: http://www.nagare.org/trac/wiki/NagareFeatures Release info and download page: http://pypi.python.org/pypi/nagare Release info and download page of the examples: http://pypi.python.org/pypi/nagare.examples Source and documentation available at the website: http://www.nagare.org Mailing lists - the place to ask questions: http://groups.google.com/group/nagare-users About Nagare ============ Nagare is a components based framework: a Nagare application is a composition of interacting components each one with its own state and workflow kept on the server. Each component can have one or several views that are composed to generate the final web page. This enables the developers to reuse or write highly reusable components easily and quickly. Thanks to Stackless Python, Nagare is also a continuation-based web framework which enables to code a web application like a desktop application, with no need to split its control flow in a multitude of controllers and with the automatic handling of the back, fork and refresh actions from the browser. Its component model and use of the continuation come from the famous Seaside Smalltalk framework. Furthermore Nagare integrates the best tools and standard from the Python world. For example: - WSGI: binds the application to several possible publishers, - lxml: generates the DOM trees and brings to Nagare the full set of XML features (XSL, XPath, Schemas ...), - setuptools: installs, deploys and extends the Nagare framework and the Nagare applications too, - PEAK Rules: generic methods are heavily used in Nagare, to associate views to components, to define security rules, to translate Python code to Javascript ... - WebOb: for its Request and Response Objects. Examples ======== A complete "guess a number" game to taste how easy web coding becomes using continuations: import random from nagare import component, util class Number(component.Task): """A little game to guess a number """ def go(self, comp): """The game algorithm, using continuation for a pure linear Python code In: - ``comp`` -- this component """ self.attempt = 1 number = random.randint(1, 20) comp.call(util.Confirm('I choose a number between 1 and 20. Try to guess it')) while True: x = comp.call(util.Ask('Try #%d: ' % self.attempt)) if not x.isdigit(): continue x = int(x) if x > number: comp.call(util.Confirm('Choose a lower number')) if x < number: comp.call(util.Confirm('Choose a greater number')) if x == number: comp.call(util.Confirm('You guessed the number in %d attempts' % self.attempt)) break self.attempt += 1 A simple todo list, illustrating the programmatic HTML generation, the association of view(s) to Python objects and the direct association of callbacks to HTML form elements and links: from nagare import presentation from nagare.namespaces import xhtml # A plain Python ``TodoList`` class class TodoList(object): def __init__(self): self.todo = [] def add_todo(self, msg): self.todo.append(msg) # The default HTML view, generated in programmatic HTML @presentation.render_for(TodoList) def render(self, h, comp, model): # ``h`` is a (X)HTML renderer (http://www.nagare.org/trac/wiki/RendererObjects) with h.div: for msg in self.todo: h << h.blockquote(msg) << h.hr with h.form: h << 'New todo:' << h.br h << h.textarea.action(self.add_todo) << h.br h << h.input(type='submit', value='Add') return h.root 0.2.0 Changelog =============== Python Stackless 2.6.2 is now the recommanded Python version. New features ------------ - When an AJAX update contains CSS or Javascript urls, they are correctly fetched. - Multiple AJAX updates object added - Session lock added (distributed lock when memcached is used) - A session can now contains SQLAlchemy (and Elixir) entities - LRU management of the sessions and continuations - ``nagare-admin create-rules`` administrative command added. Generation of the Apache / lighttpd / ngnix rewrite rules to serve the statics contents. See :wiki:`NagareAdmin` - ``nagare-admin batch`` administrative command added. To execute Python statements. See :wiki:`NagareAdmin` - Easy WSGI pipe creation - An application can now be registered under several urls - The automatic reloader can be configured with a list of files to watch - API to logout and change the user identity/password added - automatic generation of a ``link(rel="canonical" ...)`` in the page header as an alias without the session and continuation parameters - ``min_compress_len`` parameter added in the memcached configuration - YUI AJAX modules updated to 2.7.0 - SQLAlchemy updated to 0.5.x Changes ------- - Complete refactoring of the AJAX communication. The "wire" format is now Javascript. - ``component.Component.init()`` and ``presentation.init_for()`` API changes. See :wiki:`RestfulUrl` Bugs fixed ---------- - #19, #23, #26: race condition in the sessions management - #22: don't clear the registered callbacks when an image is served - #21: set the security context at the beginning of the request handling - #13, #14: python to javascript translation updated Enjoy! A. Poirier From robillard.etienne at gmail.com Fri Jun 26 15:56:32 2009 From: robillard.etienne at gmail.com (Etienne Robillard) Date: Fri, 26 Jun 2009 09:56:32 -0400 Subject: [Web-SIG] [ANN] Nagare 0.2.0 - Components and continuation-based web framework In-Reply-To: <200906261252.14884.alain.poirier@net-ng.com> References: <200906261252.14884.alain.poirier@net-ng.com> Message-ID: <4A44D390.2050504@gmail.com> Ok.. I promise... I won't make an outrage this time! ;-) Congratulations for this new release! Etienne Alain Poirier wrote: > Hi all, > > The version 0.2.0 of the Nagare web framework is now released ! > > To read about its features: > http://www.nagare.org/trac/wiki/NagareFeatures > > Release info and download page: > http://pypi.python.org/pypi/nagare > > Release info and download page of the examples: > http://pypi.python.org/pypi/nagare.examples > > Source and documentation available at the website: > http://www.nagare.org > > Mailing lists - the place to ask questions: > http://groups.google.com/group/nagare-users > > About Nagare > ============ > > Nagare is a components based framework: a Nagare application > is a composition of interacting components each one with its > own state and workflow kept on the server. Each component > can have one or several views that are composed to generate > the final web page. This enables the developers to reuse or > write highly reusable components easily and quickly. > > Thanks to Stackless Python, Nagare is also a continuation-based > web framework which enables to code a web application like a > desktop application, with no need to split its control flow in > a multitude of controllers and with the automatic handling of > the back, fork and refresh actions from the browser. > > Its component model and use of the continuation come from the > famous Seaside Smalltalk framework. > > Furthermore Nagare integrates the best tools and standard from > the Python world. For example: > > - WSGI: binds the application to several possible publishers, > - lxml: generates the DOM trees and brings to Nagare the full > set of XML features (XSL, XPath, Schemas ...), > - setuptools: installs, deploys and extends the Nagare framework > and the Nagare applications too, > - PEAK Rules: generic methods are heavily used in Nagare, to > associate views to components, to define security rules, to > translate Python code to Javascript ... > - WebOb: for its Request and Response Objects. > > > Examples > ======== > > A complete "guess a number" game to taste how easy web coding > becomes using continuations: > > > import random > from nagare import component, util > > class Number(component.Task): > """A little game to guess a number > """ > def go(self, comp): > """The game algorithm, using continuation for a pure linear Python code > > In: > - ``comp`` -- this component > """ > self.attempt = 1 > number = random.randint(1, 20) > > comp.call(util.Confirm('I choose a number between 1 and 20. Try to guess > it')) > > while True: > x = comp.call(util.Ask('Try #%d: ' % self.attempt)) > if not x.isdigit(): > continue > > x = int(x) > > if x > number: > comp.call(util.Confirm('Choose a lower number')) > > if x < number: > comp.call(util.Confirm('Choose a greater number')) > > if x == number: > comp.call(util.Confirm('You guessed the number in %d attempts' % > self.attempt)) > break > > self.attempt += 1 > > > A simple todo list, illustrating the programmatic HTML generation, > the association of view(s) to Python objects and the direct association > of callbacks to HTML form elements and links: > > from nagare import presentation > from nagare.namespaces import xhtml > > # A plain Python ``TodoList`` class > class TodoList(object): > def __init__(self): > self.todo = [] > > def add_todo(self, msg): > self.todo.append(msg) > > # The default HTML view, generated in programmatic HTML > @presentation.render_for(TodoList) > def render(self, h, comp, model): > # ``h`` is a (X)HTML renderer > (http://www.nagare.org/trac/wiki/RendererObjects) > with h.div: > for msg in self.todo: > h << h.blockquote(msg) << h.hr > > with h.form: > h << 'New todo:' << h.br > h << h.textarea.action(self.add_todo) << h.br > h << h.input(type='submit', value='Add') > > return h.root > > 0.2.0 Changelog > =============== > > Python Stackless 2.6.2 is now the recommanded Python version. > > New features > ------------ > > - When an AJAX update contains CSS or Javascript urls, they are correctly > fetched. > - Multiple AJAX updates object added > - Session lock added (distributed lock when memcached is used) > - A session can now contains SQLAlchemy (and Elixir) entities > - LRU management of the sessions and continuations > - ``nagare-admin create-rules`` administrative command added. > Generation of the Apache / lighttpd / ngnix rewrite rules to serve the > statics > contents. See :wiki:`NagareAdmin` > - ``nagare-admin batch`` administrative command added. To execute Python > statements. See :wiki:`NagareAdmin` > - Easy WSGI pipe creation > - An application can now be registered under several urls > - The automatic reloader can be configured with a list of files to watch > - API to logout and change the user identity/password added > - automatic generation of a ``link(rel="canonical" ...)`` in the page header > as an alias without the session and continuation parameters > - ``min_compress_len`` parameter added in the memcached configuration > - YUI AJAX modules updated to 2.7.0 > - SQLAlchemy updated to 0.5.x > > Changes > ------- > > - Complete refactoring of the AJAX communication. The "wire" format is now > Javascript. > - ``component.Component.init()`` and ``presentation.init_for()`` API > changes. > See :wiki:`RestfulUrl` > > Bugs fixed > ---------- > > - #19, #23, #26: race condition in the sessions management > - #22: don't clear the registered callbacks when an image is served > - #21: set the security context at the beginning of the request handling > - #13, #14: python to javascript translation updated > > Enjoy! > > A. Poirier > > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: http://mail.python.org/mailman/options/web-sig/robillard.etienne%40gmail.com > -- Etienne Robillard Green Tea Hackers Club Blog: PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC From randy at rcs-comp.com Mon Jun 29 23:41:00 2009 From: randy at rcs-comp.com (Randy Syring) Date: Mon, 29 Jun 2009 17:41:00 -0400 Subject: [Web-SIG] Trac-like Query Builder Message-ID: <4A4934EC.7030807@rcs-comp.com> Does anyone know of a Python package that would provide query building functionality like Trac has when doing a custom query on the tickets? -- -------------------------------------- Randy Syring RCS Computers & Web Solutions 502-644-4776 http://www.rcs-comp.com "Whether, then, you eat or drink or whatever you do, do all to the glory of God." 1 Cor 10:31 From me at gustavonarea.net Tue Jun 30 15:24:48 2009 From: me at gustavonarea.net (Gustavo Narea) Date: Tue, 30 Jun 2009 15:24:48 +0200 Subject: [Web-SIG] Trac-like Query Builder In-Reply-To: <4A4934EC.7030807@rcs-comp.com> References: <4A4934EC.7030807@rcs-comp.com> Message-ID: <200906301524.49064.me@gustavonarea.net> Hello, Randy said: > Does anyone know of a Python package that would provide query building > functionality like Trac has when doing a custom query on the tickets? Are you talking about a front-end that allows end-users "assemble" the query, or a back-end that turns user-provided data into a result filter (e.g., SQL `WHERE` clause)? If it's the later, you may want to see this: https://launchpad.net/booleano With it, you'll be able to have text-based filters like: * ticket.id == 12 * ticket.assignee == users.myself or not ticket.assignee * ticket.assignee in {users.myself, users.admin} * ticket.title contains "Foo Bar" Or, without namespaces: * id == 12 * assignee == myself or not assignee * assignee in {myself, admin} * title contains "Foo Bar" Unfortunately it's a rather new piece of software and should get the first alpha/usable release this week. HTH, -- Gustavo Narea . | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | From fumanchu at aminus.org Tue Jun 30 17:16:47 2009 From: fumanchu at aminus.org (Robert Brewer) Date: Tue, 30 Jun 2009 08:16:47 -0700 Subject: [Web-SIG] Trac-like Query Builder References: <4A4934EC.7030807@rcs-comp.com> <200906301524.49064.me@gustavonarea.net> Message-ID: Gustavo Narea wrote: > Randy said: > > Does anyone know of a Python package that would provide query building > > functionality like Trac has when doing a custom query on the tickets? > > Are you talking about a front-end that allows end-users "assemble" the > query, or a back-end that turns user-provided data into a result filter > (e.g., SQL `WHERE` clause)? > > If it's the later, you may want to see this: > https://launchpad.net/booleano > Unfortunately it's a rather new piece of software and should get the first > alpha/usable release this week. Heck, if all you want is the back end, Geniusql (and therefore Dejavu) allows you to build comparison expressions and combine them with "+", "&", and "|": >>> from geniusql import logic >>> a = logic.comparison('Name', 6, ['Dave', 'Jerry', 'Sue']) >>> a logic.Expression(lambda x: x.Name in ['Dave', 'Jerry', 'Sue']) >>> b = logic.comparison('Size', 2, 30) >>> b logic.Expression(lambda x: x.Size == 30) >>> a + b logic.Expression(lambda x: (x.Name in ['Dave', 'Jerry', 'Sue']) and (x.Size == 30)) >>> a & b logic.Expression(lambda x: (x.Name in ['Dave', 'Jerry', 'Sue']) and (x.Size == 30)) >>> a | b logic.Expression(lambda x: (x.Name in ['Dave', 'Jerry', 'Sue']) or (x.Size == 30)) >>> c = logic.Expression(lambda g, h: g.Name == h.Name) >>> c logic.Expression(lambda g, h: g.Name == h.Name) >>> a + c logic.Expression(lambda x, h: (x.Name in ['Dave', 'Jerry', 'Sue']) and (x.Name == h.Name)) You then pass those to the storage layer where they are automatically converted to backend-specific SQL etc. Been runnin' like a champ for years, not days. [1] Robert Brewer fumanchu at aminus.org [1] OK, I did have to commit a patch just now for comparison() in py2.5+--but it's a short one ;) http://www.aminus.net/geniusql/changeset/280 -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at gustavonarea.net Tue Jun 30 17:43:08 2009 From: me at gustavonarea.net (Gustavo Narea) Date: Tue, 30 Jun 2009 17:43:08 +0200 Subject: [Web-SIG] Trac-like Query Builder In-Reply-To: References: <4A4934EC.7030807@rcs-comp.com> <200906301524.49064.me@gustavonarea.net> Message-ID: <200906301743.08403.me@gustavonarea.net> Hello, Booleano and Geniusql seem to be two different things: * If you need to *parse* a text-based filter (aka "boolean expression"), use Booleano. * If you already have the data in a useful form (i.e., no need to parse anything), use Geniusql. BTW, you can use a Booleano parse tree not only to create an SQL `WHERE` clause, but also to create a SQLAlchemy filter, for example -- you can turn these trees into anything you need (or at least that's the goal). Cheers, - Gustavo. Robert said: > Heck, if all you want is the back end, Geniusql (and therefore Dejavu) allows you to build comparison expressions and combine them with "+", "&", and "|": > >>> from geniusql import logic > >>> a = logic.comparison('Name', 6, ['Dave', 'Jerry', 'Sue']) > >>> a > > logic.Expression(lambda x: x.Name in ['Dave', 'Jerry', 'Sue']) > > >>> b = logic.comparison('Size', 2, 30) > >>> b > > logic.Expression(lambda x: x.Size == 30) > > >>> a + b > > logic.Expression(lambda x: (x.Name in ['Dave', 'Jerry', 'Sue']) and > (x.Size == 30)) > > >>> a & b > > logic.Expression(lambda x: (x.Name in ['Dave', 'Jerry', 'Sue']) and > (x.Size == 30)) > > >>> a | b > > logic.Expression(lambda x: (x.Name in ['Dave', 'Jerry', 'Sue']) or (x.Size > == 30)) > > >>> c = logic.Expression(lambda g, h: g.Name == h.Name) > >>> c > > logic.Expression(lambda g, h: g.Name == h.Name) > > >>> a + c > > logic.Expression(lambda x, h: (x.Name in ['Dave', 'Jerry', 'Sue']) and > (x.Name == h.Name)) > > You then pass those to the storage layer where they are automatically > converted to backend-specific SQL etc. Been runnin' like a champ for years, > not days. [1] > > > Robert Brewer > fumanchu at aminus.org > > [1] OK, I did have to commit a patch just now for comparison() in > py2.5+--but it's a short one ;) > http://www.aminus.net/geniusql/changeset/280 -- Gustavo Narea . | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about |