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

1 files changed, 123 insertions, 0 deletions

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