Dr said:
[...]
It is always possible that a newsgroup FAQ maintainer will lose interest
for one or more of several reasons.
Therefore, the FAQ-writing system should not require anything other than
ordinarily-available software. That's automatic for a plain-text FAQ
(except that not everybody here can CRON a news-post); but not so if the
need is to maintain plain-text and HTML versions from a single source.
Thanks for the comment, John. You're absolutely right that a FAQ
maintaining system shouldn't require anything else than commonly
available software. I had thought to make it accessible for all common
browsers.
When it comes to updating HTML documents from one single source, I
thought of the following possibilities:
(1) If the owner of an interested website is willing to give
username/password (S/FTP), then the software at my end could
automatically replace the file on a daily base. This does not require
any extra tools, as I assume all websites are accessible by FTP one way
or another. Of course I can understand that not all website owners are
willing to share their FTP login data.
(2) Programmers familiar with PHP, ASP, Python, Perl, Ruby, Java, C++,
etc. might fetch the URL of my generated output file, and then replace
the file on their own website. You're right; this requires some effort
from the website owner and he needs to have access to those
technologies.
(3) Send out the content by mail. It's possible, but, same as (2), the
mail should be processed then using own tools.
(4) Web service. It's possible to set up a web service using socket
communication, or over HTTP. Maybe some would like to work with
javascript's XML HTTP Request object / AJAX, this would also be a
possibility. Maybe HTTP is easier here, as I'm not sure whether it's
possible to communicate to other ports than those from the web server
when using AJAX.
If anyone would have additional ideas for more possibilities, then I
can always consider those.
Points (1) to (4) are thougth as different possibilities that can all
exist together. Once a website has its daily FAQ-update (whether by
(1),(2),(3) or (4)), it just keeps running and there is no need to do
anything else; so one can focus on the content only.
It's not hard to generate an HTML file from SQL data. And maybe we
could eventually skip the HTML idea and just spread it as XML.
Now <URL:
http://www.merlyn.demon.co.uk/js-quick.htm> is available for
all to take and use (but not re-publish) a copy of; and it can take
paragraphs of arbitrarily-varying line-length and convert them to left-
justified at a given margin size.
ISTM that something vaguely similar, but with more javascript code
behind it, could possibly take simple marked-up text and produce both an
HTML version and one suited to News, perhaps in new windows.
Example :
H2 some heading
text /text/ ... <URL:... ...>
could convert to
<H2>some heading</H2>
<p>text <i>text</i> ... <a href="...">...</a>
and to
some heading
text text ... <URL:... ...>
This would of course be much simpler than a general text->HTML or HTML-
text converter as it does not need to deal with any construction that
the FAQ does not need to use. Being javascript, it would if prudently
written be usable and maintainable by any FAQ maintainer.
I've played around with this tool; yes, I think this would be an
excellent tool to generate XML/HTML before it's inserted into the
database. The stored data should contain all HTML/XML tags anyhow, but
it's a good idea to make the life of the FAQ-maintainer as easy as
possible.
Let's say that the basic CGI-2-SQL program works with a simple
<textarea></textarea> to maintain a chosen FAQ-entry. When the system
is running, this textarea can then be extended to contain any
"additional" client code, to reduce the manual 'hard'/'HTML' work as
much as possible.
But I would prefer that the CGI/MySQL is developed first; because your
tool can always be built upon the underlying mechanism (the other way
around is more difficult). In other words, the system can work with a
simple textarea, but this textarea can be extended to "virtually
whatever", as long as its posted content at the end is the same as it
would be as a simple textarea. It's like the Hotmail-system; all kinds
of features to insert the content as effective/user-friendly as
possible; but always post the resulting HTML/XML at the end. Are you
open or this idea ? I'm just trying to think of a suitable workflow
here
The storage of all data should be in structured format; that is,
preferrably a database. This is much easier for the developer. When
cron fires off its daily post, it's logical that it would take its
content from a database. At least in my experience this would be the
best approach for such scenarios. Of course it is always possible to
program an own relational system for the FAQ, but that would actually
be reinventing the wheel.
The Usenet article could then just consist of the FAQ-entry in question
without the markup tags (so, in plain text, with after <p></p> two EOLs
&& after <br> one EOL). These EOL regexes and strip-HTML regexes are a
oneliner in Perl, and can easily done by the cronjob just before it
sends out the Usenet-post. And then some practical stuff like start
text / entry title between hyphen ranges at the top / etc... it should
be no big deal.
I hope to have clarified more than confused.