> I disagree. There's already a similar website that generates Aportis
> DOC format, and people still download DOC generators and use them
> instead.
About two years ago, when the parser was still perl/awk/sed based
and pretty rough, I came up with an email-only interface for Plucker, which
worked, but had massive scalability issues. I will be resurrecting that soon
also for those who can't get parsers to work, or who are behind firewalls,
etc. It's very simple to do. The piece(s) that were missing was an email way
to cancel the parse or override it with newer parameters with a follow-up
email.
The goal, of course, with a new idea I'm playing with (and with
*HEAVY* help from my friend Rasmus Lerdorf) is to allow the user to log into
the website, and specify their preference:
- Store the pdb in a blob in their "account" for later manual
retrieval when they visit the site (scheduled of course)
- Mail the user back a one-time random link to their content when
it's finished parsing, such as http://my.plkr.org/plucks/26141613
- Mail the user back the pdb itself, in full, and then alternately
specify compression (zip, bz2, tar.gz) for the content. Some
mailers and MTAs will refuse attachments or messages over a
certain size (thank you spam). This should alleviate some of that.
- Send the user back a template so they can parse it themselves,
locall, based on their OS of choice. If they run Windows, they get
a .ini file, if it's non-Windows (i.e. POSIX systems), they get
back a home.html file, and if they want syndication, I will have
to figure out how to do a proper XML export. Before we can even
think XML or RSS, we have to come up with a logical schema and
DTD for this.. I'd put the XML on the bottom of my priority list
at the moment. Those who remember the previous site before this
current revision will probably remember the "Build-It" page
within the site that allowed a user to create a proper syntax for
local plucking. This would be an extension of that.
Right now the most important part is security and maintaining
session (hopefully sans cookies, I hate them and so do most .eu people).
Once a user can log in and save some preferences by walking through a set of
"Druid" forms (anyone have a better name for that other than "Wizard"? Linux
uses Druid, so that's what I'm used to).
This is my first "experiment" with php driving this, so it's going
to be a little weird. I'm normally used to doing it in perl, and pushing out
the repetitive elements to HTML::Template and friends. This should be fun.
I've had issues with scalability using mod_perl with mod_gzip, so I'm going
to try to roll this in php and do some head-to-head tests.
> I'm sure that the Linux Documentation Project, for example, would want
> to be able to control generation of their HOWTOs in Plucker form,
> without waiting for the Plucker website to do it.
I actually had set up a pretty huge page with a bunch of drop-down
forms and submit buttons for Gutenberg's etexts, the HOWTOs at Linuxdoc, and
the RFC pages at ibiblio. You would pick what you wanted, it would fetch the
raw file, convert it and present it for download. As long as Linuxdoc's
publically available .txt HOWTOs are the most current, the user will always
get the most-current version converted on the fly. I'd like to add the
ability to determine if the reote file is changed when the user selects the
item they want from the dropdown, and if it hasn't changed, pull a locally
converted copy that was converted by someone else previously. If it's new,
convert it on the fly, and store it locally again for someone else.
Sitescooper isn't ideal for this, and personally, running all of these
python, perl, and other tools at an interactive session isn't really
scalable either, nor is it fun to program the logic flow.
> I think the best approach is to give people a choice. Some people will
> want a tool, some won't. Which I think is all that's being proposed
> here.
Exactly. It breaks down like this:
"Show me" - create a config on the fly, display to user
"Give me" - create runtime pdb, send to browser for download
"Mail me" - send via email the pdb or an expiring link to it on the
server
"Save for me" - store them on the server for the user to retrieve
interactively when they log in.
> It doesn't directly, but you could generate HTML files from rtf and PDF.
Sure, we can try to convert from pdf, html, txt, rtf, Word doc to
Plucker file format, but let's start slowly here. I'm learning the language
as well as trying to design and implement the functionality.
[dd]
