Re: [HT2HTML-devel] Future development

[<ba...@zo...>]

I answered these in private email, so let me repeat myself...

    GL> Question 1: (licence)

    GL> Is ht2html open source?  It has all the appearances of an open
    GL> source project, but I don't see any agreement in any of the
    GL> downloaded files or on any of the webpages.  May I freely
    GL> modify this, distribute patches, or would it be best for me to
    GL> join the ht2html group so I can submit CVS changes for added
    GL> features?

It is open source, and should be considered to be covered under the
PSF license (with the words Python scratched out and the words HT2HTML
written in in crayon).

    GL> Question 2: (practical)

    GL> I want to switch TMDA's design over from purely text-based:

    GL>     http://tmda.sourceforge.net/

    GL> To something a little more graphical:

    GL>     http://wolfhome.com/~gre7g/layout2.htm

    GL> This shouldn't be too impossible, but ht2html makes a bunch of
    GL> assumptions that will sabotage the process (such as fixed size
    GL> spacers).  Clearly those pieces of code would have to be
    GL> overridden or changed to make this work.  Do you know anyone
    GL> who has done this before or would I be breaking new ground?

You'd probably be breaking new ground.

    GL> Question 3: (philosophical)

    GL> I understand that ht2html allows us to build a class that can
    GL> then override various portions of the output, but I was
    GL> wondering why you chose to do this with with functions?

    GL> In other words, why have functions like get_style(),
    GL> get_stylesheet(), get_banner(), etc. that only return a
    GL> string?  Wouldn't it have been simpler and more
    GL> straightforward to just keep a class with a bunch of class
    GL> constants such as style, stylesheet, banner, etc. and then
    GL> allow us to overload these values?  It seems to me that it
    GL> would be simpler and more straightforward to define values
    GL> than functions.  It also makes more readible code to pull out
    GL> variables than functions.

Mostly historical baggage from the earlier implementations.  I won't
make any claims about the cleanliness or flexibility of the code, just
that it's been Good Enough for our purposes up to now.

-Barry