From 9ef8e376212786d8a99cfa19bfcd9c6e70735d0a Mon Sep 17 00:00:00 2001 From: "W. Trevor King" Date: Tue, 21 Jul 2009 15:22:09 -0400 Subject: I imported a few threads from the mailing list as wishlist bugs. 12c:uw: Bug aggregation. Multi-repo meta-BE? 529:ow: How should we version BE? 2f0:aw: Static html report generation 22b:aw: Sorting targets chronologically d99:aw: CherryPy interface "Cherry-flavored BE" e08:aw: Interactive email interface --- .../074ef29a-3f1d-46dc-8561-7a56af7e6d67/body | 23 ++++ .../074ef29a-3f1d-46dc-8561-7a56af7e6d67/values | 14 +++ .../1dba8196-654b-4ca0-9a95-fb334af81863/body | 47 ++++++++ .../1dba8196-654b-4ca0-9a95-fb334af81863/values | 14 +++ .../3bf57ee7-710f-4a01-a8af-8bb9eb9dc937/body | 25 +++++ .../3bf57ee7-710f-4a01-a8af-8bb9eb9dc937/values | 14 +++ .../55263144-9775-4b18-ab83-29d66ed91a53/body | 50 +++++++++ .../55263144-9775-4b18-ab83-29d66ed91a53/values | 14 +++ .../68927fef-6ce1-4a1f-a414-28695d913a50/body | 23 ++++ .../68927fef-6ce1-4a1f-a414-28695d913a50/values | 14 +++ .../83202b83-eea8-452f-8239-d468940bddba/body | 123 +++++++++++++++++++++ .../83202b83-eea8-452f-8239-d468940bddba/values | 14 +++ .../8c1c4f38-a8d4-4cf9-a9f0-e9846ebbcad8/body | 47 ++++++++ .../8c1c4f38-a8d4-4cf9-a9f0-e9846ebbcad8/values | 14 +++ .../b900f7fd-bab6-48c4-922c-a051f933da58/body | 35 ++++++ .../b900f7fd-bab6-48c4-922c-a051f933da58/values | 14 +++ .../c7ace551-2982-4683-bca3-b5e66056cce5/body | 93 ++++++++++++++++ .../c7ace551-2982-4683-bca3-b5e66056cce5/values | 14 +++ .../cb5689f4-7c36-4c44-b380-ca9e06e80bae/body | 32 ++++++ .../cb5689f4-7c36-4c44-b380-ca9e06e80bae/values | 11 ++ .../da97e18f-33d6-469e-9d93-6457b9a6bfca/body | 45 ++++++++ .../da97e18f-33d6-469e-9d93-6457b9a6bfca/values | 14 +++ .../e5248100-ea02-4205-a4c1-ac7a577c6362/body | 43 +++++++ .../e5248100-ea02-4205-a4c1-ac7a577c6362/values | 11 ++ .../fd7ab206-5937-4ede-9e78-97aff098b677/body | 43 +++++++ .../fd7ab206-5937-4ede-9e78-97aff098b677/values | 14 +++ .../2f048ac5-5564-4b34-b7f9-605357267ed2/values | 20 ++++ 27 files changed, 825 insertions(+) create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/074ef29a-3f1d-46dc-8561-7a56af7e6d67/body create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/074ef29a-3f1d-46dc-8561-7a56af7e6d67/values create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/1dba8196-654b-4ca0-9a95-fb334af81863/body create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/1dba8196-654b-4ca0-9a95-fb334af81863/values create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/3bf57ee7-710f-4a01-a8af-8bb9eb9dc937/body create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/3bf57ee7-710f-4a01-a8af-8bb9eb9dc937/values create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/55263144-9775-4b18-ab83-29d66ed91a53/body create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/55263144-9775-4b18-ab83-29d66ed91a53/values create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/68927fef-6ce1-4a1f-a414-28695d913a50/body create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/68927fef-6ce1-4a1f-a414-28695d913a50/values create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/83202b83-eea8-452f-8239-d468940bddba/body create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/83202b83-eea8-452f-8239-d468940bddba/values create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/8c1c4f38-a8d4-4cf9-a9f0-e9846ebbcad8/body create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/8c1c4f38-a8d4-4cf9-a9f0-e9846ebbcad8/values create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/b900f7fd-bab6-48c4-922c-a051f933da58/body create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/b900f7fd-bab6-48c4-922c-a051f933da58/values create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/body create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/values create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/cb5689f4-7c36-4c44-b380-ca9e06e80bae/body create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/cb5689f4-7c36-4c44-b380-ca9e06e80bae/values create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/body create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/values create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/e5248100-ea02-4205-a4c1-ac7a577c6362/body create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/e5248100-ea02-4205-a4c1-ac7a577c6362/values create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/fd7ab206-5937-4ede-9e78-97aff098b677/body create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/fd7ab206-5937-4ede-9e78-97aff098b677/values create mode 100644 .be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/values (limited to '.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2') diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/074ef29a-3f1d-46dc-8561-7a56af7e6d67/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/074ef29a-3f1d-46dc-8561-7a56af7e6d67/body new file mode 100644 index 0000000..5ce4f1c --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/074ef29a-3f1d-46dc-8561-7a56af7e6d67/body @@ -0,0 +1,23 @@ +"W. Trevor King" writes: + +> On Sat, Jul 04, 2009 at 10:19:35AM +1000, Ben Finney wrote: +> > Instead of a separate command for each output format, could we have +> > a single "produce a static report of the bug database" command, and +> > specify output format as an option? +> > […] +> +> Do people like this architecture better than my be-xml-to-mbox +> approach? + +I think this question is illuminated by the related question: Is mbox +output a static report, or another read-write data store? + +It can technically be both, of course, which is why the question may be +helpful: it may help show what is the *conceptual* purpose of the mbox +output format for Bugs Everywhere. + +-- + \ “Time is the great legalizer, even in the field of morals.” | + `\ —Henry L. Mencken | +_o__) | +Ben Finney diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/074ef29a-3f1d-46dc-8561-7a56af7e6d67/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/074ef29a-3f1d-46dc-8561-7a56af7e6d67/values new file mode 100644 index 0000000..b83f4a6 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/074ef29a-3f1d-46dc-8561-7a56af7e6d67/values @@ -0,0 +1,14 @@ +Alt-id: <87hbxqrckv.fsf@benfinney.id.au> + + +Content-type: text/plain + + +Date: Mon, 06 Jul 2009 08:26:24 +1000 + + +From: Ben Finney + + +In-reply-to: cb5689f4-7c36-4c44-b380-ca9e06e80bae + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/1dba8196-654b-4ca0-9a95-fb334af81863/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/1dba8196-654b-4ca0-9a95-fb334af81863/body new file mode 100644 index 0000000..dbf3b1b --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/1dba8196-654b-4ca0-9a95-fb334af81863/body @@ -0,0 +1,47 @@ +Gianluca Montecchi writes: + +> 1) is it ok to develop this command ? I know that this is not a fully +> featured web interface, but I am sure that it can be usefull. + +Yes, definitely. I can see it being a very easy way to put one's bug +database online for browsing. + +> I am open to suggestion about it of course. + +Instead of a separate command for each output format, could we have a +single “produce a static report of the bug database” command, and +specify output format as an option? + +How about: + + be report + be report --format ascii + be report --format rst + be report --format html + +Where the ‘--format’ option has a default of, e.g., “ascii”. + +This would mean that you are implementing the ‘html’ format of this +putative command. + +> 2) I see that every command is implemented with a python file in the +> becommand dir. For a better code, I'd like to split the command +> implementation into two files: a file that contain the actual code and +> a second file that have the html related part, any problem with this ? + +This sounds quite sensible to me. The existence of a command implies a +module of the same name in ‘becommand’, but there's no necessary +implication that that module can't import modules from elsewhere to do +its work. + +-- + \ “It ain't so much the things we don't know that get us in | + `\ trouble. It's the things we know that ain't so.” —Artemus Ward | +_o__) (1834–1867), U.S. journalist | +Ben Finney + + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/1dba8196-654b-4ca0-9a95-fb334af81863/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/1dba8196-654b-4ca0-9a95-fb334af81863/values new file mode 100644 index 0000000..4ef9544 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/1dba8196-654b-4ca0-9a95-fb334af81863/values @@ -0,0 +1,14 @@ +Alt-id: <87y6r5qoyw.fsf@benfinney.id.au> + + +Content-type: text/plain + + +Date: Sat, 04 Jul 2009 10:19:35 +1000 + + +From: Ben Finney + + +In-reply-to: cb5689f4-7c36-4c44-b380-ca9e06e80bae + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/3bf57ee7-710f-4a01-a8af-8bb9eb9dc937/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/3bf57ee7-710f-4a01-a8af-8bb9eb9dc937/body new file mode 100644 index 0000000..4276b9c --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/3bf57ee7-710f-4a01-a8af-8bb9eb9dc937/body @@ -0,0 +1,25 @@ +Gianluca Montecchi writes: + +> On Monday 06 July 2009 12:48:39 W. Trevor King wrote: +> > Gianluca is clearly thinking about a static report [for a collection +> > of HTML files as output]: +> +> You are right, static, but not exactly a report as I think Ben is +> thinking + +I think it exactly is a report: multiple, static, browseable pages +reporting the state of the database at a point in time. + +What makes you think that term doesn't apply? + +-- + \ “The problem with television is that the people must sit and | + `\ keep their eyes glued on a screen: the average American family | +_o__) hasn't time for it.” —_The New York Times_, 1939 | +Ben Finney + + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/3bf57ee7-710f-4a01-a8af-8bb9eb9dc937/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/3bf57ee7-710f-4a01-a8af-8bb9eb9dc937/values new file mode 100644 index 0000000..7dee5d6 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/3bf57ee7-710f-4a01-a8af-8bb9eb9dc937/values @@ -0,0 +1,14 @@ +Alt-id: <87skh9p8ax.fsf@benfinney.id.au> + + +Content-type: text/plain + + +Date: Tue, 07 Jul 2009 11:53:58 +1000 + + +From: Ben Finney + + +In-reply-to: cb5689f4-7c36-4c44-b380-ca9e06e80bae + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/55263144-9775-4b18-ab83-29d66ed91a53/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/55263144-9775-4b18-ab83-29d66ed91a53/body new file mode 100644 index 0000000..8451bd7 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/55263144-9775-4b18-ab83-29d66ed91a53/body @@ -0,0 +1,50 @@ +On Mon, Jul 06, 2009 at 08:26:24AM +1000, Ben Finney wrote: +> "W. Trevor King" writes: +> +> > On Sat, Jul 04, 2009 at 10:19:35AM +1000, Ben Finney wrote: +> > > Instead of a separate command for each output format, could we have +> > > a single "produce a static report of the bug database" command, and +> > > specify output format as an option? +> > +> > Do people like this architecture better than my be-xml-to-mbox +> > approach? +> +> I think this question is illuminated by the related question: Is mbox +> output a static report, or another read-write data store? + +Gianluca is clearly thinking about a static report: + +On Fri, Jul 03, 2009 at 10:50:17PM +0200, Gianluca Montecchi wrote: +> The goal is to be able to do something like "be html /web/page" to have in the +> /web/page directory some static html pages that basically are the dump of the +> be repository, much like ditz have + +I think truly interactive frontends like Steve's working on need to be +build on top of libbe directly, since they'll need to make lots of +small changes to the database, and it's to slow to be reloading the +database for every change. Static dumps like my mbox or Gianluca's +html could just parse the xml output of `be list' and other be +commands. + +There should also be an xml import for `be new' and `be comment' so +you could import new bugs/comments from whatever format after writing +a whatever->xml converter. This would allow you to email new bugs and +comments to the database (e.g. via some procmail-spawned +be-parse-email script) which would give you some level of +interactivity, but you'd have to regenerate your mbox to see your new +comments in your mail reader. + +I think interactive use that gives you live-updates in your mail +reader isn't worth the trouble, since you'd need to teach BE imap or +smtp+mbox-locking. Hmm, maybe it smtp+mbox-locking wouldn't be so bad, +but that would be a distinct frontend project like Steve's, not part +of the becommands. + +Trevor + +-- +This email may be signed or encrypted with GPG (http://www.gnupg.org). +The GPG signature (if present) will be attached as 'signature.asc'. +For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy + +My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/55263144-9775-4b18-ab83-29d66ed91a53/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/55263144-9775-4b18-ab83-29d66ed91a53/values new file mode 100644 index 0000000..6f9ecf7 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/55263144-9775-4b18-ab83-29d66ed91a53/values @@ -0,0 +1,14 @@ +Alt-id: <20090706104839.GA19537@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Mon, 6 Jul 2009 06:48:39 -0400 + + +From: '"W. Trevor King" ' + + +In-reply-to: 074ef29a-3f1d-46dc-8561-7a56af7e6d67 + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/68927fef-6ce1-4a1f-a414-28695d913a50/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/68927fef-6ce1-4a1f-a414-28695d913a50/body new file mode 100644 index 0000000..3b53533 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/68927fef-6ce1-4a1f-a414-28695d913a50/body @@ -0,0 +1,23 @@ +On Sat, Jul 04, 2009 at 10:19:35AM +1000, Ben Finney wrote: +> Instead of a separate command for each output format, could we have a +> single "produce a static report of the bug database" command, and +> specify output format as an option? +> +> How about: +> +> be report +> be report --format ascii +> be report --format rst +> be report --format html + +Do people like this architecture better than my be-xml-to-mbox +approach? I think the tradeoff is easy output format implementation +vs cluttered core codebase. Should we use both, depending on how +useful people think the output format will be? + +-- +This email may be signed or encrypted with GPG (http://www.gnupg.org). +The GPG signature (if present) will be attached as 'signature.asc'. +For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy + +My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/68927fef-6ce1-4a1f-a414-28695d913a50/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/68927fef-6ce1-4a1f-a414-28695d913a50/values new file mode 100644 index 0000000..3452022 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/68927fef-6ce1-4a1f-a414-28695d913a50/values @@ -0,0 +1,14 @@ +Alt-id: <20090705143108.GB10709@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Sun, 5 Jul 2009 10:31:08 -0400 + + +From: '"W. Trevor King" ' + + +In-reply-to: 1dba8196-654b-4ca0-9a95-fb334af81863 + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/83202b83-eea8-452f-8239-d468940bddba/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/83202b83-eea8-452f-8239-d468940bddba/body new file mode 100644 index 0000000..9bf3851 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/83202b83-eea8-452f-8239-d468940bddba/body @@ -0,0 +1,123 @@ +On Fri, Jul 03, 2009 at 10:50:17PM +0200, Gianluca Montecchi wrote: +> +> Hello to everyone +> +> As i said in a previous mail, I am working on a "html" command for be. +> The goal is to be able to do something like "be html /web/page" to have in the +> /web/page directory some static html pages that basically are the dump of the +> be repository, much like ditz have +> This will enable a simple and fast publish of the bus list and details on the +> web, at least in read only mode. +> +> So I'd like to ask some question: +> 1) is it ok to develop this command ? I know that this is not a fully featured +> web interface, but I am sure that it can be usefull. +> +> I am open to suggestion about it of course. +> +> 2) I see that every command is implemented with a python file in the becommand +> dir. For a better code, I'd like to split the command implementation into two +> files: a file that contain the actual code and a second file that have the html +> related part, any problem with this ? I don't like to have the html part and +> the code part in one big and unreadable file. +> +> I'd like to hear other opinion about this. +> +> Thanks for now +> bye +> Gianluca +> +> +> _______________________________________________ +> Be-devel mailing list +> Be-devel@bugseverywhere.org +> http://void.printf.net/cgi-bin/mailman/listinfo/be-devel + +On Mon, Jul 06, 2009 at 10:18:33PM +0200, Gianluca Montecchi wrote: +> This sound like an interesting idea, but what i'd like to do is not, strictly +> speaking, a report. It is a full tree of html pages that are browseable, both +> on line and offline + +I'm not sure what distinction you're making about "report". You're +just producing a static snapshot of the current database status, +right? The number of pages and completeness of coverage are nice, but +it's still a static entity generated from a particular snapshot, which +is what I mean by "report" ;). + +> > > 2) I see that every command is implemented with a python file in the +> > > becommand dir. For a better code, I'd like to split the command +> > > implementation into two files: a file that contain the actual code and +> > > a second file that have the html related part, any problem with this ? +> > +> > This sounds quite sensible to me. The existence of a command implies a +> > module of the same name in ‘becommand’, but there's no necessary +> > implication that that module can't import modules from elsewhere to do +> > its work. +> +> The "elsewhere" for now is the same directory, just another module +> + +On Mon, Jul 06, 2009 at 10:38:56PM +0200, Gianluca Montecchi wrote: +> > On Fri, Jul 03, 2009 at 10:50:17PM +0200, Gianluca Montecchi wrote: +> > > The goal is to be able to do something like "be html /web/page" to have +> > > in the /web/page directory some static html pages that basically are the +> > > dump of the be repository, much like ditz have +> > +> > I think truly interactive frontends like Steve's working on need to be +> > build on top of libbe directly, since they'll need to make lots of +> > small changes to the database, and it's to slow to be reloading the +> > database for every change. Static dumps like my mbox or Gianluca's +> > html could just parse the xml output of `be list' and other be +> > commands. +> +> Ok, but if I want to have an html dump that is browseable, I need to parse the +> xml. Am I correct ? +> If yes, should not be easiear to use directly the libbe ? + +Using libbe directly is easier, but also more tightly tied to the be +internals which could weigh down future refactoring. Partly I'm +afraid of our 2.5 different html-output mechanisms. Either their +should be a single Right Way that tries to satisfy everyone, or a +smorgasbord of loosely coupled translators, so it's not so painful to +kill them if/when they go out of style :p. + +On Mon, Jul 06, 2009 at 10:46:54PM +0200, Gianluca Montecchi wrote: +> On Saturday 04 July 2009 02:31:26 Chris Ball wrote: +> > It might be a good idea for "be html" to use the CherryPy web interface +> > that Steve is working on. The command could start up the CherryPy app +> > and scrape all of the available pages to get a stand-alone dump; this +> > would avoid having to keep two (okay, more than two at this point) +> > separate sets of HTML templates in the source tree. What do you think? +> +> It can be do, but this implies that CherryPy must be installed and configured, +> a thing that I don't want to impose. My idea is to offer a simpler way to have +> some html pages, where you just need to have BE installed. + +I agree that not needing CherryPy for a static html dump is good. +Also, read-only templates will look different from the CherryPy +interactive templates. +1 for another quasi-redundant template set +;). + +> > > 2) I see that every command is implemented with a python file in +> > > the becommand dir. For a better code, I'd like to split the +> > > command implementation into two files: a file that contain the +> > > actual code and a second file that have the html related part, +> > > any problem with this ? I don't like to have the html part and +> > > the code part in one big and unreadable file. +> > +> > I agree that becommands/*.py commands should not contain any HTML +> > layout code. Putting it somewhere else instead sounds fine. +> +> I am in doubt with the "somewhere else", since for now I put the html template +> into a separate file in the same directory. Suggestion ? + +I think that only code intended only for command line use only should +go into becommands, but really, just dump it anywhere and we can shift +it around later :p. + +-- +This email may be signed or encrypted with GPG (http://www.gnupg.org). +The GPG signature (if present) will be attached as 'signature.asc'. +For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy + +My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/83202b83-eea8-452f-8239-d468940bddba/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/83202b83-eea8-452f-8239-d468940bddba/values new file mode 100644 index 0000000..ac3b5ab --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/83202b83-eea8-452f-8239-d468940bddba/values @@ -0,0 +1,14 @@ +Alt-id: <20090707013454.GA3721@mjolnir.home.net> + + +Content-type: text/plain + + +Date: Mon, 6 Jul 2009 21:34:54 -0400 + + +From: '"W. Trevor King" ' + + +In-reply-to: da97e18f-33d6-469e-9d93-6457b9a6bfca + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/8c1c4f38-a8d4-4cf9-a9f0-e9846ebbcad8/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/8c1c4f38-a8d4-4cf9-a9f0-e9846ebbcad8/body new file mode 100644 index 0000000..2301eba --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/8c1c4f38-a8d4-4cf9-a9f0-e9846ebbcad8/body @@ -0,0 +1,47 @@ +On Saturday 04 July 2009 02:19:35 Ben Finney wrote: +> Gianluca Montecchi writes: + +> +> > I am open to suggestion about it of course. +> +> Instead of a separate command for each output format, could we have a +> single “produce a static report of the bug database” command, and +> specify output format as an option? +> +> How about: +> +> be report +> be report --format ascii +> be report --format rst +> be report --format html +> +> Where the ‘--format’ option has a default of, e.g., “ascii”. +> +> This would mean that you are implementing the ‘html’ format of this +> putative command. +> + +This sound like an interesting idea, but what i'd like to do is not, strictly +speaking, a report. It is a full tree of html pages that are browseable, both +on line and offline + +> > 2) I see that every command is implemented with a python file in the +> > becommand dir. For a better code, I'd like to split the command +> > implementation into two files: a file that contain the actual code and +> > a second file that have the html related part, any problem with this ? +> +> This sounds quite sensible to me. The existence of a command implies a +> module of the same name in ‘becommand’, but there's no necessary +> implication that that module can't import modules from elsewhere to do +> its work. + +The "elsewhere" for now is the same directory, just another module + +bye +Gianluca + + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/8c1c4f38-a8d4-4cf9-a9f0-e9846ebbcad8/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/8c1c4f38-a8d4-4cf9-a9f0-e9846ebbcad8/values new file mode 100644 index 0000000..6259717 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/8c1c4f38-a8d4-4cf9-a9f0-e9846ebbcad8/values @@ -0,0 +1,14 @@ +Alt-id: <200907062218.33895.gian@grys.it> + + +Content-type: text/plain + + +Date: Mon, 06 Jul 2009 22:18:33 +0200 + + +From: Gianluca Montecchi + + +In-reply-to: 1dba8196-654b-4ca0-9a95-fb334af81863 + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/b900f7fd-bab6-48c4-922c-a051f933da58/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/b900f7fd-bab6-48c4-922c-a051f933da58/body new file mode 100644 index 0000000..50a30e8 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/b900f7fd-bab6-48c4-922c-a051f933da58/body @@ -0,0 +1,35 @@ +Hi Gianluca, + + > As i said in a previous mail, I am working on a "html" command + > for be. The goal is to be able to do something like "be html + > /web/page" to have in the /web/page directory some static html + > pages that basically are the dump of the be repository, much like + > ditz have. This will enable a simple and fast publish of the bus + > list and details on the web, at least in read only mode. + +It might be a good idea for "be html" to use the CherryPy web interface +that Steve is working on. The command could start up the CherryPy app +and scrape all of the available pages to get a stand-alone dump; this +would avoid having to keep two (okay, more than two at this point) +separate sets of HTML templates in the source tree. What do you think? + + > 2) I see that every command is implemented with a python file in + > the becommand dir. For a better code, I'd like to split the + > command implementation into two files: a file that contain the + > actual code and a second file that have the html related part, + > any problem with this ? I don't like to have the html part and + > the code part in one big and unreadable file. + +I agree that becommands/*.py commands should not contain any HTML +layout code. Putting it somewhere else instead sounds fine. + +Thanks! + +- Chris. +-- +Chris Ball + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/b900f7fd-bab6-48c4-922c-a051f933da58/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/b900f7fd-bab6-48c4-922c-a051f933da58/values new file mode 100644 index 0000000..7d09f96 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/b900f7fd-bab6-48c4-922c-a051f933da58/values @@ -0,0 +1,14 @@ +Alt-id: + + +Content-type: text/plain + + +Date: Fri, 03 Jul 2009 20:31:26 -0400 + + +From: Chris Ball + + +In-reply-to: cb5689f4-7c36-4c44-b380-ca9e06e80bae + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/body new file mode 100644 index 0000000..8991cfb --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/body @@ -0,0 +1,93 @@ +> On Mon, Jul 06, 2009 at 10:18:33PM +0200, Gianluca Montecchi wrote: +>> This sound like an interesting idea, but what i'd like to do is not, +>> strictly +>> speaking, a report. It is a full tree of html pages that are browseable, +>> both +>> on line and offline +> +> I'm not sure what distinction you're making about "report". You're +> just producing a static snapshot of the current database status, +> right? The number of pages and completeness of coverage are nice, but +> it's still a static entity generated from a particular snapshot, which +> is what I mean by "report" ;). + +Mmm, my bad here. +I normally speak about "report" as something that is not browseable, like +the output of a report generator (reportlab or whatever), but I admit that +basically also the html output I am working on is a report. + + +> On Mon, Jul 06, 2009 at 10:38:56PM +0200, Gianluca Montecchi wrote: +>> +>> Ok, but if I want to have an html dump that is browseable, I need to +>> parse the +>> xml. Am I correct ? +>> If yes, should not be easiear to use directly the libbe ? +> +> Using libbe directly is easier, but also more tightly tied to the be +> internals which could weigh down future refactoring. Partly I'm +> afraid of our 2.5 different html-output mechanisms. Either their +> should be a single Right Way that tries to satisfy everyone, or a +> smorgasbord of loosely coupled translators, so it's not so painful to +> kill them if/when they go out of style :p. + +I know that using libbe I am more tightly tied to the internals, but +I am trying to keep the command code and the presentation code crearly +separated to minimize this problem. I am not sure this is a real problem +anyway. + + +> On Mon, Jul 06, 2009 at 10:46:54PM +0200, Gianluca Montecchi wrote: +>> On Saturday 04 July 2009 02:31:26 Chris Ball wrote: +>> > It might be a good idea for "be html" to use the CherryPy web +>> interface +>> > that Steve is working on. The command could start up the CherryPy app +>> > and scrape all of the available pages to get a stand-alone dump; this +>> > would avoid having to keep two (okay, more than two at this point) +>> > separate sets of HTML templates in the source tree. What do you +>> think? +>> +>> It can be do, but this implies that CherryPy must be installed and +>> configured, +>> a thing that I don't want to impose. My idea is to offer a simpler way +>> to have +>> some html pages, where you just need to have BE installed. +> +> I agree that not needing CherryPy for a static html dump is good. +> Also, read-only templates will look different from the CherryPy +> interactive templates. +1 for another quasi-redundant template set +> ;). + +The look is not a problem. I can always use the same html Steve is using. +I am also playing with the idea to have the template themeable some time +after I have a fully working version. + +> +>> > > 2) I see that every command is implemented with a python file in +>> > > the becommand dir. For a better code, I'd like to split the +>> > > command implementation into two files: a file that contain the +>> > > actual code and a second file that have the html related part, +>> > > any problem with this ? I don't like to have the html part and +>> > > the code part in one big and unreadable file. +>> > +>> > I agree that becommands/*.py commands should not contain any HTML +>> > layout code. Putting it somewhere else instead sounds fine. +>> +>> I am in doubt with the "somewhere else", since for now I put the html +>> template +>> into a separate file in the same directory. Suggestion ? +> +> I think that only code intended only for command line use only should +> go into becommands, but really, just dump it anywhere and we can shift +> it around later :p. + +Of course. + +bye +Gianluca + + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/values new file mode 100644 index 0000000..e846ff5 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/values @@ -0,0 +1,14 @@ +Alt-id: <6f719a1c43fdcba8bdbfee1130072595.squirrel@webmail.grys.it> + + +Content-type: text/plain + + +Date: Tue, 07 Jul 2009 14:15:08 +0200 + + +From: gian@grys.it + + +In-reply-to: 83202b83-eea8-452f-8239-d468940bddba + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/cb5689f4-7c36-4c44-b380-ca9e06e80bae/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/cb5689f4-7c36-4c44-b380-ca9e06e80bae/body new file mode 100644 index 0000000..d8f14fc --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/cb5689f4-7c36-4c44-b380-ca9e06e80bae/body @@ -0,0 +1,32 @@ +Hello to everyone + +As i said in a previous mail, I am working on a "html" command for be. +The goal is to be able to do something like "be html /web/page" to have in the +/web/page directory some static html pages that basically are the dump of the +be repository, much like ditz have +This will enable a simple and fast publish of the bus list and details on the +web, at least in read only mode. + +So I'd like to ask some question: +1) is it ok to develop this command ? I know that this is not a fully featured +web interface, but I am sure that it can be usefull. + +I am open to suggestion about it of course. + +2) I see that every command is implemented with a python file in the becommand +dir. For a better code, I'd like to split the command implementation into two +files: a file that contain the actual code and a second file that have the html +related part, any problem with this ? I don't like to have the html part and +the code part in one big and unreadable file. + +I'd like to hear other opinion about this. + +Thanks for now +bye +Gianluca + + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/cb5689f4-7c36-4c44-b380-ca9e06e80bae/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/cb5689f4-7c36-4c44-b380-ca9e06e80bae/values new file mode 100644 index 0000000..e95ab61 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/cb5689f4-7c36-4c44-b380-ca9e06e80bae/values @@ -0,0 +1,11 @@ +Alt-id: <200907032250.17327.gian@grys.it> + + +Content-type: text/plain + + +Date: Fri, 03 Jul 2009 22:50:17 +0200 + + +From: Gianluca Montecchi + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/body new file mode 100644 index 0000000..27dca1e --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/body @@ -0,0 +1,45 @@ +On Saturday 04 July 2009 02:31:26 Chris Ball wrote: +> Hi Gianluca, +> +> > As i said in a previous mail, I am working on a "html" command +> > for be. The goal is to be able to do something like "be html +> > /web/page" to have in the /web/page directory some static html +> > pages that basically are the dump of the be repository, much like +> > ditz have. This will enable a simple and fast publish of the bus +> > list and details on the web, at least in read only mode. +> +> It might be a good idea for "be html" to use the CherryPy web interface +> that Steve is working on. The command could start up the CherryPy app +> and scrape all of the available pages to get a stand-alone dump; this +> would avoid having to keep two (okay, more than two at this point) +> separate sets of HTML templates in the source tree. What do you think? + +It can be do, but this implies that CherryPy must be installed and configured, +a thing that I don't want to impose. My idea is to offer a simpler way to have +some html pages, where you just need to have BE installed. + +My very first implementation was a script that parse directly the .be directory +to build the pages, without BE itself installed. + + +> > 2) I see that every command is implemented with a python file in +> > the becommand dir. For a better code, I'd like to split the +> > command implementation into two files: a file that contain the +> > actual code and a second file that have the html related part, +> > any problem with this ? I don't like to have the html part and +> > the code part in one big and unreadable file. +> +> I agree that becommands/*.py commands should not contain any HTML +> layout code. Putting it somewhere else instead sounds fine. + +I am in doubt with the "somewhere else", since for now I put the html template +into a separate file in the same directory. Suggestion ? + +thanks +bye +Gianluca + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/values new file mode 100644 index 0000000..1bf2dc4 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/da97e18f-33d6-469e-9d93-6457b9a6bfca/values @@ -0,0 +1,14 @@ +Alt-id: <200907062246.54804.gian@grys.it> + + +Content-type: text/plain + + +Date: Mon, 06 Jul 2009 22:46:54 +0200 + + +From: Gianluca Montecchi + + +In-reply-to: b900f7fd-bab6-48c4-922c-a051f933da58 + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/e5248100-ea02-4205-a4c1-ac7a577c6362/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/e5248100-ea02-4205-a4c1-ac7a577c6362/body new file mode 100644 index 0000000..1d2b619 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/e5248100-ea02-4205-a4c1-ac7a577c6362/body @@ -0,0 +1,43 @@ +On Thursday 25 June 2009 16:23:04 Steve Losh wrote: +> On Jun 25, 2009, at 10:02 AM, Chris Ball wrote: +> >> Oh, and obviously there must still be bugs in BE. Please submit +> >> more ;). +> > +> > Perhaps it's a good time to merge Steve Losh's CherryPy web interface? +> > +> > http://void.printf.net/pipermail/be-devel/2009-February/000095.html +> > http://bitbucket.org/sjl/cherryflavoredbugseverywhere/ +> +> Hey, I haven't touched the web interface in a while, but I should have +> some time to fix some stuff up tonight and tomorrow. Hold off on +> merging it in until then. +> +> I'm still curious as to what people think the role of a web interface +> like this should be. When I wrote it I meant it as a single-user +> interface like the command line one. It could definitely work as a +> public, read-only interface too. + +I'd really like to have some sort of web interface for BE, also in read-only +mode. + +I am thinking to write (actually I wrote some test code) a tool to parse a BE +repository to output a set of static html pages to put online, like the "ditz +html" command, but this was before I start to play with BE sourcecode, so now +I ma thinking to implement it as a BE command. + +> If the goal is to allow more than one person to add issues, how should +> commits go? One commit per change? Commit every X minutes if necessary? + +I think that a simple web interface should be read-only. + +Eventually, to allow to add issues also from the web interface, it should be +done to a specific branch, one commit per change. + +just my 2 cents... +bye +Gianluca + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/e5248100-ea02-4205-a4c1-ac7a577c6362/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/e5248100-ea02-4205-a4c1-ac7a577c6362/values new file mode 100644 index 0000000..2285e1d --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/e5248100-ea02-4205-a4c1-ac7a577c6362/values @@ -0,0 +1,11 @@ +Alt-id: <200906252203.08535.gian@grys.it> + + +Content-type: text/plain + + +Date: Thu, 25 Jun 2009 22:03:08 +0200 + + +From: Gianluca Montecchi + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/fd7ab206-5937-4ede-9e78-97aff098b677/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/fd7ab206-5937-4ede-9e78-97aff098b677/body new file mode 100644 index 0000000..2e4f851 --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/fd7ab206-5937-4ede-9e78-97aff098b677/body @@ -0,0 +1,43 @@ +On Monday 06 July 2009 12:48:39 W. Trevor King wrote: +> On Mon, Jul 06, 2009 at 08:26:24AM +1000, Ben Finney wrote: +> > "W. Trevor King" writes: +> > > On Sat, Jul 04, 2009 at 10:19:35AM +1000, Ben Finney wrote: +> > > > Instead of a separate command for each output format, could we have +> > > > a single "produce a static report of the bug database" command, and +> > > > specify output format as an option? +> > > +> > > Do people like this architecture better than my be-xml-to-mbox +> > > approach? +> > +> > I think this question is illuminated by the related question: Is mbox +> > output a static report, or another read-write data store? +> +> Gianluca is clearly thinking about a static report: + +You are right, static, but not exactly a report as I think Ben is thinking + +> +> On Fri, Jul 03, 2009 at 10:50:17PM +0200, Gianluca Montecchi wrote: +> > The goal is to be able to do something like "be html /web/page" to have +> > in the /web/page directory some static html pages that basically are the +> > dump of the be repository, much like ditz have +> +> I think truly interactive frontends like Steve's working on need to be +> build on top of libbe directly, since they'll need to make lots of +> small changes to the database, and it's to slow to be reloading the +> database for every change. Static dumps like my mbox or Gianluca's +> html could just parse the xml output of `be list' and other be +> commands. + +Ok, but if I want to have an html dump that is browseable, I need to parse the +xml. Am I correct ? +If yes, should not be easiear to use directly the libbe ? + + +bye +Gianluca + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/fd7ab206-5937-4ede-9e78-97aff098b677/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/fd7ab206-5937-4ede-9e78-97aff098b677/values new file mode 100644 index 0000000..b61fc2b --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/fd7ab206-5937-4ede-9e78-97aff098b677/values @@ -0,0 +1,14 @@ +Alt-id: <200907062238.56930.gian@grys.it> + + +Content-type: text/plain + + +Date: Mon, 06 Jul 2009 22:38:56 +0200 + + +From: Gianluca Montecchi + + +In-reply-to: 55263144-9775-4b18-ab83-29d66ed91a53 + diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/values new file mode 100644 index 0000000..093611e --- /dev/null +++ b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/values @@ -0,0 +1,20 @@ +assigned: Gianluca Montecchi + + +creator: W. Trevor King + + +reporter: Gianluca Montecchi + + +severity: wishlist + + +status: assigned + + +summary: Static html report generation + + +time: Tue, 21 Jul 2009 18:43:06 +0000 + -- cgit