David Binger wrote:

> On Jan 27, 2005, at 8:05 AM, Michele Simionato wrote:
>> BTW, about the lacking documentation, there could be two reasons:
>>
>> 1, people are not willing to contribute it;
>> 2. people would be willing, but since we are still in alpha and things
>> could
>>     change, they are waiting before spending time on documentation.
>>
>> Are we in case 1 or 2?
>
> Both cases hinder the advancement of documentation.
> I expect that the Quixote 2 code will be fairly stable for a while, now,
> so this is probably a good time to improve the documentation.

I've been impressed with Quixote 2's stability and reliability.  I haven't
had one crash, and very few bug encounters.

>> For the moment I am greatly profiting from Mike Orr's "superdemo".
>> Is there a chance to get it in the official distribution? I think it
>> would
>> make a great addition, especially for the authentication part.
>
> I like Mike's demo, too.  I am starting to think, however, that all but
> the most
> basic demos should be pointed to, rather than included in a CNRI
> Quixote release.
> I think the demos will be maintained and improved better that way, and,
> like Mike's,
> they can be maintained 'live' somewhere so that they can be seen even
> before someone
> decides to install Quixote.  The http://quixote.ca/qx/ wiki seems like
> a good place
> to collect such links.  Mike, maybe you want to add something there?

I'm glad people find the Superdemo useful.  I noticed that Quixote 2.0a3
came with a new demo that was much simpler than the others, essentially a
"Hello, world!" application with a hyperlink.  That is reassuring to users
trying to navigate the unfamiliar Quixote maze.  For me it only confirmed
what I presumed intuitively, but it was nice to have that confirmation.
Perhaps we should break up the other existing demos and have a simple form
demo (text widgets only) alongside mini_demo.py, and a more advanced form
demo (various widget types).

I would like to see demos like the Superdemo in the distribution, covering
all advanced features and techniques, but perhaps it's not really
feasable, given the issues of differing quality between authors, the delay
caused by the Quixote release cycle, and duplication of documentation
(each demo README explaining the same thing differently).

The main problem with the wiki is it's not well publicized.  Nowhere on
the main Quixote page is it listed.  I only learned about it from this
list.  There is a link from the quixote.ca site, but you wouldn't realize
that looking at Quixote's home page, which only says, "There is also an
introduction and a set of tutorials on the quixote.ca web site."  (BTW,
there's also no explanation of why quixote.ca exists, how official its
status is, or whether it's as up to date as the main site.)

If we do put demo entries and documentation on the wiki, we should have a
standard prominent place to date the entries (e.g., just below the title).
 Then people will know to take pages that haven't been updated in six
months with a grain of salt.

Could we also have an FTP directory somewhere to upload demo/doc tarballs
so I don't have to commit to keeping my computer on 24 hours?

The next version of the Superdemo, available perhaps in late February,
will have several new pages of techniques I've encountered, drop Quixote 1
compatibility, and may change the login scheme.  I've found the
header/footer via Publish.filter_output() strategy works very well once
you've made the headers/footers robust enough to to be called during an
exception (at which point certain request/user variables may be missing).

The login system has worked well for logging in and out, cascading through
LDAP authenticators to static password lists, and usually works for
returning you to the page you were on with your new privileges, but there
are some borderline issues with the latter.  I had to hack in query-string
preservation because some of my pages depend on query variables.  That led
to the problem that logging in and out repeatedly on the same page, or
pressing the browser's Back button, can result in URLs like:
    ?login=1&logout=1
That can cause unpredictable behavior depending on how exactly the login
routine examines it.  Pressing the Back button can also get you to a page
that says you're logged in when you're not, or even reinstates your login
status unexpectedly.  Having multiple sets of query variables in the same
request, each used by a different function, is difficult to maintain.  So
I'm undecided whether to keep this or to switch to a simpler login scheme
that takes you to a standalone login page and then redirects to the home
page.  I've tried messing with HTTP_REFERER but it's another thing that
works sometimes but now always.

Since a demo can have only one login scheme, I'd have to split out any
others to their own mini demos.

Regarding uploading large files through the web, even if you can, do you
really want to?  First you'll have to make sure the webserver and all the
browsers involved can support it and aren't configured to reject it.  Then
there's the time to upload and the possibility of it aborting in the
middle, although if it's on a LAN these may not be significant.  But how
would you resume an upload if it was aborted?  Then there's the efficiency
issue: the browser has to base64-encode the file, making it larger than it
is, and the server has to decode it.  It often works better in a LAN to
put the file in a network-mounted directory and have the server pick it
up, either triggered by a web request or automatically by a cron job.

-- Mike Orr