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

27 files changed, 825 insertions, 0 deletions

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" <wking@drexel.edu> 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 <bignose+hates-spam@benfinney.id.au>
+
+
+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 <gian@grys.it> 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 <bignose+hates-spam@benfinney.id.au>
+
+
+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 <gian@grys.it> 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 <bignose+hates-spam@benfinney.id.au>
+
+
+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" <wking@drexel.edu> 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" <wking@drexel.edu>'
+
+
+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" <wking@drexel.edu>'
+
+
+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" <wking@drexel.edu>'
+
+
+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 <gian@grys.it> 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 <gian@grys.it>
+
+
+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   <cjb@laptop.org>
+
+_______________________________________________
+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: <m3iqi9thk1.fsf@pullcord.laptop.org>
+
+
+Content-type: text/plain
+
+
+Date: Fri, 03 Jul 2009 20:31:26 -0400
+
+
+From: Chris Ball <cjb@laptop.org>
+
+
+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 <gian@grys.it>
+
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 <gian@grys.it>
+
+
+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 <cjb@laptop.org> 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 <gian@grys.it>
+
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" <wking@drexel.edu> 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 <gian@grys.it>
+
+
+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 <gian@grys.it>
+
+
+creator: W. Trevor King <wking@drexel.edu>
+
+
+reporter: Gianluca Montecchi <gian@grys.it>
+
+
+severity: wishlist
+
+
+status: assigned
+
+
+summary: Static html report generation
+
+
+time: Tue, 21 Jul 2009 18:43:06 +0000
+