473,387 Members | 1,619 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,387 software developers and data experts.

CLJ newsgroup FAQ


kelvlam <ke*****@gmail.composted :
>Sorry I haven't read through the FAQ. I will do so now.

The newsgroup FAQ has not been posted here for some considerable while.

The latest version I know of is 8.1 - 2005-11-05
but I think the Web site serves 8.0 - 2004-03-15

We cannot expect new readers, especially those entering via Web pages,
to know of the FAQ without a regular posting of something with a
suitable Subject, whether it be a FAQ or a FAQ pointer - and the Subject
must be such as they will understand ("Quick Answers" is OK; IMHO "META"
is not).
As far as I know, the existing technical content is correct; but the FAQ
could IMHO be improved by re-wording here and there. I don't know how
many <FAQENTRYitems remain outstanding.
Is it time for someone else, someone who (unlike me) has access to a
system which can post regularly, to take over the FAQ? ISTM that those
from smaller countries in mainland Europe, having been taught properly,
seem to write good straightforward clear English.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/>? JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.
Jul 18 '06 #1
19 1927
Dr John Stockton wrote:
ISTM that
those from smaller countries in mainland Europe, having been taught
properly, seem to write good straightforward clear English.
Your xenophobia is so blatant as to be amusing.

Do those from smaller countries in mainland Europe, having been taught to be
snobbish and elitist, also seem to write sentences using absurdly dense
abbreviations, references to obfuscated url's in signatures, and web pages
so bland and ugly as to be unreadable?
Just curious!

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Jul 18 '06 #2
Dr John Stockton said the following on 7/18/2006 1:00 PM:
kelvlam <ke*****@gmail.composted :
>Sorry I haven't read through the FAQ. I will do so now.


The newsgroup FAQ has not been posted here for some considerable while.
But links to it, and sub-articles of it, are posted at least daily. Many
times more than once a day.
The latest version I know of is 8.1 - 2005-11-05
That version is online, but not on jibbering.
<URL: http://members.aol.com/_ht_a/hikksnotathome/cljfaq/>

It was put there, from your version, just so the latest would be available.
but I think the Web site serves 8.0 - 2004-03-15
It does. And if nothing else it could be updated to a static file so
that at least the latest version is on the website.
We cannot expect new readers, especially those entering via Web pages,
to know of the FAQ without a regular posting of something with a
suitable Subject, whether it be a FAQ or a FAQ pointer - and the Subject
must be such as they will understand ("Quick Answers" is OK; IMHO "META"
is not).
Either/Or, people do not read that far into the subject line.
As far as I know, the existing technical content is correct; but the FAQ
could IMHO be improved by re-wording here and there. I don't know how
many <FAQ**TRYitems remain outstanding.
That shouldn't be hard to determine. Even using Google Groups and
searching for the phrase and then sorting by date and going to the date
of the last update.
Is it time for someone else, someone who (unlike me) has access to a
system which can post regularly, to take over the FAQ?
If nothing else, I can post it manually with an FAQ Poster name until it
can be automated again. It won't be at the same time, but I can post it
Monday Wednesday and Friday. I don't care to "take over" it for editing
purposes but I can post it until......
ISTM that those from smaller countries in mainland Europe, having been
taught properly, seem to write good straightforward clear English.
Ahh, couldn't even discuss the group FAQ without letting your
anti-American sentiments display?

Your ignorance is overwhelming at times.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Temporarily at: http://members.aol.com/_ht_a/hikksnotathome/cljfaq/
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Jul 19 '06 #3
Matt Kruse said the following on 7/18/2006 3:06 PM:
Dr John Stockton wrote:
>ISTM that
those from smaller countries in mainland Europe, having been taught
properly, seem to write good straightforward clear English.

Your xenophobia is so blatant as to be amusing.
Right idea, wrong term. John doesn't suffer from zenophobia, but
stupidity isn't a condition so he can't suffer from that either
(although he does).

It is not all foreign things, it is strictly anti-American and anything
to do with it. Irony is that he uses many many American inventions to
spout his anti-American bull crap.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Temporarily at: http://members.aol.com/_ht_a/hikksnotathome/cljfaq/
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Jul 19 '06 #4
On Tue, 18 Jul 2006 22:20:56 -0400, Randy Webb
<Hi************@aol.comwrote:
>Dr John Stockton said the f
>but I think the Web site serves 8.0 - 2004-03-15

It does. And if nothing else it could be updated to a static file so
that at least the latest version is on the website.
An email highlighting that fact would've been great! I've updated the
faq site to that one, automated posting - I can provide a box with a
news.individual account, and if you're "known" to me then I can
provide a log on, I unfortunately simply don't have any obvious time
to get it updated to automated posting.

Help of course welcome.

Jim.
Jul 19 '06 #5
Dr John Stockton wrote:
[...]
We cannot expect new readers, especially those entering via Web pages,
to know of the FAQ without a regular posting of something with a
suitable Subject, whether it be a FAQ or a FAQ pointer - and the Subject
must be such as they will understand ("Quick Answers" is OK; IMHO "META"
is not).
As far as I know, the existing technical content is correct; but the FAQ
could IMHO be improved by re-wording here and there. I don't know how
many <FAQENTRYitems remain outstanding.
I think maintenance is one of the major challenges to guarantee a FAQ's
quality. One should ideally use some kind of system that constantly
reminds of the FAQ's content. Personally I like the idea of
comp.lang.perl.misc. An automated program posts one FAQ-entry a day to
the NG. If someone has a comment on that, it might be considered to add
it to, or rewrite, the FAQ entry in question. I think it's a great way
to keep things up-to-date (though I'm not saying that the Perl FAQ is
the ideal FAQ). Maybe http://faq.perl.org/ could be worth exploring to
see how things work there.
Is it time for someone else, someone who (unlike me) has access to a
system which can post regularly, to take over the FAQ?
I could make such a tool, that is, if you and the regulars of this
group wish to do so. It should consist of a logic and well-thought
structure. I think the current FAQ could be an excellent start, but I'm
convinced that it could cover much more topics. The great thing is that
there is much material available already, I think it would be great to
gather the information into one general list. I think it are the
unified contributions that make a FAQ strong.

One login/password could serve to maintain the FAQ. Probably it's a
good idea that everybody would keep his own topics; we'ld need a sort
of gentlemen's agreement for that. Or I could write a system with many
passwords so everyone has only access to his own FAQ entries.

Unfortunately, I don't have too much time on my hands to actively work
on and maintain the FAQ. Though the temptation to write an entry here
or there will probably pop up anyhow :-) I could provide in the
technical background though and guarantee its correct working. I've
worked on many MySQL/CGI software projects over the past 7 years and I
cannot imagine that this relatively simple program could ever be
problematic. I have good contacts within pair Networks
(www.pair.com/www.quickserve.com), they are one of USA's largest
non-adult hosting companies. I'm quite sure they will give free app
hosting without need to mention their name/link. If you want to make
money, we could consider to add their name/link on each automated post,
but personally I wouldn't do that.

Another thing that comes to mind is that each FAQ entry should be
rather concise, and of course to-the-point and coherent. I think it
could certainly become a useful and maybe even the "de-facto" standard
for common javascript problems.

Vanity is of humans, and I think we can use this aspect to improve the
FAQ. The author(s) of a contribution can be mentionned below each
entry. Contributors might be sensitive for that, and as long as it
serves the FAQ, I don't see any drawbacks here.

I think a first major issue would be to make a solid structure that (a)
is more-or-less complete, (b) leaves room for future extensions and (c)
is intuitive to navigate.

In the long run there are a few things to consider. Not all current
contributors will remain interested to maintain their entries. I think
that problem can be dealt with; "new" regulars will appear in CLJ and
they can be invited to take over FAQ-entries after they've proven their
qualities. Obviously, one should try to make each entry as timeless,
qualitative and complete as possible. Another point is the continuity
of the technical background. As pair Networks has a long-proven
tradition of quality hosting with many dedicated machines, I think that
this shouldn't be a problem at all. About myself: I'm in business since
1999 and I can say I've solid business for many years to come.

I'ld be happy to know what you think about this :-)
ISTM that those from smaller countries in mainland Europe, having
been taught properly, seem to write good straightforward clear English.
The issue is that non-native English speakers don't have much choice if
they want to express a software problem in a language that's not their
own. Especially in the beginning, you are forced to write as clear and
straightforward as possible, just because you don't understand the
exact finetunings and the connotations that words, sentences or
language constructions might have, while they are mostly immediately
obvious for native speakers. You can't translate Shakespeare to
Schwarzenegger-English, but you can describe a technical problem in
Terminator-language. I even think non-native English speakers have an
advantage here; they can't easily hide behind vague blah-blah or
unreadable terminology.

--
Bart

Jul 19 '06 #6
JRS: In article <e9********@news4.newsguy.com>, dated Tue, 18 Jul 2006
14:06:07 remote, seen in news:comp.lang.javascript, Matt Kruse
<ne********@mattkruse.composted :
>Dr John Stockton wrote:
>ISTM that
those from smaller countries in mainland Europe, having been taught
properly, seem to write good straightforward clear English.

Your xenophobia is so blatant as to be amusing.
Either you do not understand the difference between xenophobia and
xenophilia, or you are unaware of (a) what countries are, and are not,
basically in mainland Europe, (b) the relative sizes of European
countries. Or, of course, both.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/>? JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.
Jul 19 '06 #7
Dr John Stockton wrote:
Either you do not understand the difference between xenophobia and
xenophilia
Possibly.
or you are unaware of (a) what countries are, and are not,
basically in mainland Europe
Possibly.
(b) the relative sizes of European
countries.
Possibly.

What I do know for sure is that your assumptions and generalizations about
people based on their physical location and country of origin make you look
foolish.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Jul 19 '06 #8
Ivo
"Matt Kruse" wrote:
Dr John Stockton wrote
>what countries are, and are not
What I do know for sure is
death and taxes, all else is theory. Aren't we getting a bit off topic,
guys? Isn't that what this group suffers from most? I am from Holland, the
largest of the little countries, and the smallest of the big brothers on the
European block. The Javascript language transcends all that, as Bart Van der
Donck pointed out in another branch of this thread.
If this or any FAQ is to be of any value, it needs to change when
circumstances change, which they do continuously. What is the plan to get it
on the road again then, where lies the ultimate responsibility? Hadn't the
brave new anarchistic internet done with all that? Gentleman's agreements,
like others, rely not on vanity alone.
It is obvious that many people care about c.l.j. passionately, and plenty of
others also, but less, we all want the one and only FAQ to be perfect, but
what is to the point at one point in the web will never be so again, history
learns. Wouldn't a wikipedialike structure, where all may contribute on the
spot, with or without password, be conceivable?
hth
ivo
Jul 19 '06 #9
JRS: In article <44***********************@news.wanadoo.nl>, dated Wed,
19 Jul 2006 20:47:13 remote, seen in news:comp.lang.javascript, Ivo
<no@thank.youposted :
>It is obvious that many people care about c.l.j. passionately, and plenty of
others also, but less, we all want the one and only FAQ to be perfect, but
what is to the point at one point in the web will never be so again, history
learns. Wouldn't a wikipedialike structure, where all may contribute on the
spot, with or without password, be conceivable?
It would be conceivable - indeed, I don't know what's on Wiki itself.

It could be a useful adjunct, but it could not rightly replace a
properly maintained newsgroup FAQ.

A proper newsgroup FAQ is maintained by a chosen individual; but, when
it is posted regularly in the group, the regulars can take joint
responsibility for reviewing it and ensuring that it is free of error.

One can see, from the alleged answers posted in this group by newcomers
whose estimate of their own ability greatly exceeds their experience,
knowledge, and sagacity (and also from the quality of topic-FAQ sites
that contain code collected from or provided by multiple sources), how
bad a result could come from unrestricted Wiki editing. ISTR that the
absent but unlamented one was proposing to alter true Wiki's news-
etiquette materials to agree with his own national practices.

So, if someone wants such, let it be created; and let it be cited and
reviewed for quality in the true newsgroup FAQ.

Note : we have already in this thread two fine examples of the
comprehensibility of English written by those in the smaller countries
of Europe in which English is properly taught.
ISTM that BVdD's proposal of posting parts-for-comment is an excellent
scheme; the individual parts X.Y are mostly not too large. Section 1
could be split into two or three; Section 2.3 could be split into, say,
General, Questions, Responses; Section 3.2 could be subdivided.

Some parts of 2.3 could be reworded more positively, on psychological
grounds - e.g.
CURRENT : 'Help!' or 'I hate Netscape!' are not nearly as useful to
contributors who do not read every post as 'parseInt("09")!=9'.
ALTERED : Subject lines such as "parseInt('09') != 9" or "Javascript
formatter?" are much more useful than ones such as "Help!" or "I hate
Netscape!".

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/>? JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.
Jul 20 '06 #10

Ivo wrote:
[...]
It is obvious that many people care about c.l.j. passionately, and plenty of
others also, but less, we all want the one and only FAQ to be perfect, but
what is to the point at one point in the web will never be so again, history
learns. Wouldn't a wikipedialike structure, where all may contribute on the
spot, with or without password, be conceivable?
If you wish to contribute to a wiki, then feel free to help with:

DOM
<URL:http://developer.mozilla.org/en/docs/Gecko_DOM_Reference>

JavaScript
<URL:http://developer.mozilla.org/en/docs/JavaScript>

You can also help out on wikipedia, however that is an encyclopedia and
will therefore never be a comprehensive JavaScript reference.
--
Rob

Jul 20 '06 #11
JRS: In article <11*********************@m79g2000cwm.googlegroups. com>,
dated Wed, 19 Jul 2006 02:48:26 remote, seen in
news:comp.lang.javascript, Bart Van der Donck <ba**@nijlen.composted :
>
I think a first major issue would be to make a solid structure that (a)
is more-or-less complete, (b) leaves room for future extensions and (c)
is intuitive to navigate.
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.

Now <URL:http://www.merlyn.demon.co.uk/js-quick.htmis 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.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/>? JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.
Jul 22 '06 #12
Dr John Stockton wrote:
[...]
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.htmis 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></textareato 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></ptwo EOLs
&& after <brone 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.

--
Bart

Jul 23 '06 #13
On 23 Jul 2006 01:48:30 -0700, "Bart Van der Donck" <ba**@nijlen.com>
wrote:
>(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.
I certainly wouldn't make a website available to FTP, and I see no
reason to provide FTP simply to have SFTP when there are much better
methods.

The bigger problem with automatic updating of content generated from
an unknown webapp that allows html input, is avoiding insertion
attacks, or even simply avoiding spam - web versions of FAQ's tend to
be high ranked so well worth getting links on.

As I've said many times, any known person who wants a log in on my box
to manage the FAQ is welcome to one.
>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.
wiki like markup are well understood and solved problem, don't invent
new syntaxes.

Jim.
Jul 23 '06 #14
Jim Ley wrote:
On 23 Jul 2006 01:48:30 -0700, "Bart Van der Donck" <ba**@nijlen.com>
wrote:
(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.

I certainly wouldn't make a website available to FTP, and I see no
reason to provide FTP simply to have SFTP when there are much better
methods.
The possibilities I mentionned are those that I've experience with, and
of which I know they work well. I'm open to any other methods that are
programmable in CGI/Perl.
The bigger problem with automatic updating of content generated from
an unknown webapp that allows html input, is avoiding insertion
attacks, or even simply avoiding spam - web versions of FAQ's tend to
be high ranked so well worth getting links on.
Yes, that risk would always exist. Perhaps it would be best to have 1
password and 1 person to manage the FAQ. If the password is kept safe,
I don't think the application would be insecure.
As I've said many times, any known person who wants a log in on my box
to manage the FAQ is welcome to one.
Sorry, it was not my personal intention to actually manage the FAQ. I
don't have enough time to do it well, and there are posters in this
group who have much more javascript knowledge than I.

I might help in writing the software that I proposed, as my 'historic'
knowledge is roughly UNIX/CGI/databases. IMO the software could make
things more maintainable, efficient, and easier adaptable; but it's up
to you guys to decide, of course.
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.

wiki like markup are well understood and solved problem, don't invent
new syntaxes.
Actually the markup syntax in a textarea wouldn't matter. This might be
Dr John's tool (which would be a excellent choice, IMO), or a wiki-like
tool, or none, or ... The only requirement from my point of view is
that the content is POST-ed as HTML/XML that is ready to insert in
database with its full markup.

--
Bart

Jul 23 '06 #15
Jim Ley wrote:
On 23 Jul 2006 01:48:30 -0700, "Bart Van der Donck" <ba**@nijlen.com>
wrote:
(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.

I certainly wouldn't make a website available to FTP, and I see no
reason to provide FTP simply to have SFTP when there are much better
methods.

The bigger problem with automatic updating of content generated from
an unknown webapp that allows html input, is avoiding insertion
attacks, or even simply avoiding spam - web versions of FAQ's tend to
be high ranked so well worth getting links on.
[...]
Another (better?) project description could maybe consist of the
following:

- Crontab file starts up Perl program once a day
- Perl program grabs http://www.jibbering.com/faq/index.xml
- Checks on successful GET-request, valid XML, well-formed XML,
security, etc.
- Determine which FAQ-entry is to send to Usenet
- Parse XML and extract the part we need
- Format message towards Usenet and fire it off
- Keep track of which FAQ is to be sent next time (number)
- Exit

Of course, this scenario is simpler as my initial proposal. It doesn't
touch anything about the way the current FAQ (or its
maintainance/structure/contents) works. It's just an add-on that is
responsible for the sending of one-FAQ-entry-a-day, and that's it.

I investigated the structure of http://www.jibbering.com/faq/index.xml,
this should be suitable; some questions:

- What does the "hash"-argument of the <URLtag mean ?

- As Richard said, the code examples should be adapted in the data so
that it doesn't exceed 68 characters per line.

- It should be logical that each FAQ-entry would have its number in the
XML-data as well. This would be easier for Perl to remember which
FAQ-entry is to send the next day. Now Perl needs to invent its own
counting mechanism to determine which FAQ-entry is to send out. (which
shouldn't be a problem technically though, so generally this point is
only a side-remark). But when new entries are added in the future, this
might at some point result in a jump/reverse in the counting mechanism.
I don't know about the possibilities of something like
<FAQNR>4.22</FAQNRor <CONTENT FAQNR="4.22">.

- As a professional pedantrist, it would be better practice to start
with <?xml version="1.0" encoding="UTF-8"? , use some DTD/schema
info and do
<CHAPTER TITLE="Quick Answers" CHAPNR="4">
in stead of
<CONTENT TITLE="Quick Answers">
and perhaps
<FAQENTRY TITLE="What is ECMAScript?" ENTRYNR="7">
in stead of
<CONTENT TITLE="What is ECMAScript?">
to get the touch of real XML-ish structurisation. If you want to, I
could adapt the XML file that way. But the current XML structure is
suitable as well (these are optimisation issues only).

--
Bart

Jul 24 '06 #16
Bart Van der Donck wrote:
<snip>
- Determine which FAQ-entry is to send to Usenet
- Parse XML and extract the part we need
- Format message towards Usenet and fire it off
- Keep track of which FAQ is to be sent next time (number)
- Exit
Where did this notion of posting one entry a day come from? At that
rate it would take a month and a half to cycle trough the existing
entries (longer is many get added) and it does not appear that section
2 would be getting posted at all, when section 2 is probably of more
practical significance to people trying to get answers from the group
than anything in section 4.

The previous approach of posting half the FAQ at a time once a week,
while not meting with universal approval, may be the better basis for
an improved system.

<snip>
I investigated the structure of http://www.jibbering.com/faq/index.xml,
this should be suitable; some questions:

- What does the "hash"-argument of the <URLtag mean ?
It was automatic monitoring for changes in linked pages. It went; load
the page with an XML HTTP request, if the HTTP status is 200 hash the
source text and compare the source text with the existing hash, if they
differ the page has changed. It has not been being used for some time,
but the 'hash' attribute has not been removed.
- As Richard said, the code examples should be adapted in the data so
that it doesn't exceed 68 characters per line.
I did not say that. The existing entries are formatted so that their
line length (in the text output format) is less than 72 characters.
Remember that a set of characters may not appear in non-CDATA XML
contents and so need to be transformed into apparently longer entities,
that similar considerations apply to HTML (and so are introduced by the
need to present the contents as HTML), and that characters commonly
used in javascript fall into that category.
- It should be logical that each FAQ-entry would have its number
in the XML-data as well.
A sensible move if anything were to be changed would be to stop
thinking of these as numbers at all and only use then as instances of
arbitrary identifiers to be used as fragment identifiers). They would
need to go in the actual XML, and become a required attribute for all
the conceptual units to which they currently apply, though the values
for future additions could then be non-numeric, and at least
semi-meaningful in some cases.
This would be easier for Perl to remember which
FAQ-entry is to send the next day. Now Perl needs to invent its own
counting mechanism to determine which FAQ-entry is to send out. (which
shouldn't be a problem technically though, so generally this point is
only a side-remark). But when new entries are added in the future, this
might at some point result in a jump/reverse in the counting mechanism.
I don't know about the possibilities of something like
<FAQNR>4.22</FAQNRor <CONTENT FAQNR="4.22">.

- As a professional pedantrist, it would be better practice to start
with <?xml version="1.0" encoding="UTF-8"? , use some DTD/schema
info and do
<CHAPTER TITLE="Quick Answers" CHAPNR="4">
in stead of
<CONTENT TITLE="Quick Answers">
No. Quick answers is section 4 only because there are 3 preceding
sections. Starting to hard code numbers intended to be presentation
sequences is just re-introducing the problem caused by automatically
generating numeric fragment identifiers from the existing sequence, but
in a different guise. The XML element that represents 'quick answers'
can contain and identify its contents without any need for it to be
'chapter 4'.
and perhaps
<FAQENTRY TITLE="What is ECMAScript?" ENTRYNR="7">
in stead of
<CONTENT TITLE="What is ECMAScript?">
to get the touch of real XML-ish structurisation.
Again, numbering is too presentational and ridged. I can understand
attributes that describe categorisation/classifications for individual
entries (for presentation grouped into related subjects), but sequenced
numbers are something that needs to be moved away from.
If you want to, I could adapt the XML file that way.
<snip>
Requests for presentational changes include a reoccurring desire to
have parts of section 2 presented as an ordered list (so individual
paragraphs can be references) and to be able to present links, which
must be text URLs in plain text format, as meaningful text that is a
hyperlink in HTML. The former is probably easily achieved in the
transformation from XML to content, but the latter will require an XML
representation containing enough information to generate sensible
content in either (any?) context of use.

Richard.

Jul 24 '06 #17
Richard Cornford wrote:
Bart Van der Donck wrote:
- Determine which FAQ-entry is to send to Usenet
- Parse XML and extract the part we need
- Format message towards Usenet and fire it off
- Keep track of which FAQ is to be sent next time (number)
- Exit

Where did this notion of posting one entry a day come from? At that
rate it would take a month and a half to cycle trough the existing
entries (longer is many get added) and it does not appear that section
2 would be getting posted at all, when section 2 is probably of more
practical significance to people trying to get answers from the group
than anything in section 4.
I think it was I who came up with it; it was inspired by
comp.lang.perl.misc. Posting one entry a time might be more efficient
for continuous evaluation/improval, rather than posting a large
document. Plus, I think a concise && well-defined message is more
inviting to respond to. I think it would also become easier to Google
for specific js questions.
>From the rest of your post I can conclude there are no practical
problems from CGI point of view. So, okay with that. But I get a
feeling that my code proposal is about burnt to ashes by now :-)
[...]
- As a professional pedantrist, it would be better practice to start
with <?xml version="1.0" encoding="UTF-8"? , use some DTD/schema
info and do
<CHAPTER TITLE="Quick Answers" CHAPNR="4">
in stead of
<CONTENT TITLE="Quick Answers">

No. Quick answers is section 4 only because there are 3 preceding
sections. Starting to hard code numbers intended to be presentation
sequences is just re-introducing the problem caused by automatically
generating numeric fragment identifiers from the existing sequence, but
in a different guise. The XML element that represents 'quick answers'
can contain and identify its contents without any need for it to be
'chapter 4'.
No problem; leaving out numberings could be worked around - the (small)
risk here is that Perl could be mistaken when the FAQ is updated.

Oh yes, when re-reading my joke above, I only referred to myself as the
"professional pedantrist"; I'm not sure it was read that way. You see
Dr John, that happens to non-native English speakers :-)

--
Bart

Jul 24 '06 #18
JRS: In article <11**********************@m79g2000cwm.googlegroups .com>
, dated Mon, 24 Jul 2006 03:08:52 remote, seen in
news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.ukposted :
>Bart Van der Donck wrote:
<snip>
>- Determine which FAQ-entry is to send to Usenet
- Parse XML and extract the part we need
- Format message towards Usenet and fire it off
- Keep track of which FAQ is to be sent next time (number)
- Exit

Where did this notion of posting one entry a day come from? At that
rate it would take a month and a half to cycle trough the existing
entries (longer is many get added) and it does not appear that section
2 would be getting posted at all, when section 2 is probably of more
practical significance to people trying to get answers from the group
than anything in section 4.

It should be (whatever the intention was), that one entry a day would be
posted, for purposes of specific review by the regulars against
staleness; but that the existing weekly posting of the whole FAQ, to
enlighten the ignorant, would be maintained though possibly modified
into three distinct parts.
The whole material, apart for the index, should be covered by the review
process; and to improve this Sections 2.3 and 3.2 should be subdivided.

FAQ 5.1 paragraph 2 sentence 2 could be made unimportant if the
<FAQ!!TRY>-seeking process were to ignore lines starting ">". However,
such replies ought to be considered.

<FAQENTRY5.1 para 1 :-
?? If a poster feels that a topic should be covered by the FAQ, placing
<FAQENTRYin the article will let the FAQ robot collect the article for
easy review and inclusion. A draft response, if possible, will be
welcome. ??

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/>? JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.
Jul 24 '06 #19
Dr John Stockton wrote:
[...]
It should be (whatever the intention was), that one entry a day would be
posted, for purposes of specific review by the regulars against
staleness; but that the existing weekly posting of the whole FAQ, to
enlighten the ignorant, would be maintained though possibly modified
into three distinct parts.

The whole material, apart for the index, should be covered by the review
process; and to improve this Sections 2.3 and 3.2 should be subdivided.
[...]
Okay, I'll leave the actual divisions/content up to the FAQ maintainer.
This stands apart from the technology that is used for the daily Usenet
message anyhow.

Thanks for the explanations Jonh/Richard/Jim; I have enough information
now. I'll develop the code:

- Crontab file starts up Perl program once a day
- Perl program grabs http://www.jibbering.com/faq/index.xml
- Checks on successful GET-request, valid XML, well-formed XML,
security, etc.
- Determine which FAQ-entry is to send to Usenet
- Parse XML and extract the part we need
- Format message towards Usenet and fire it off
- Keep track of which FAQ is to be sent next time
- Exit

Because the XML doesn't work with FAQ entry numbers, I'll deal with
this as follows:
- see how many FAQ entries are in the XML file
- read out stored value that says which entry was sent the previous
time (e.g. it was the fourth entry then)
- parse XML and extract (in this case) the fifth entry. If fifth entry
doesn't exist, take back the first.

See you after some time when I'm ready.

--
Bart

Jul 25 '06 #20

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Jan Roland Eriksson | last post by:
Archive-name: www/stylesheets/newsgroup-faq Posting-Frequency: once a week Last-modified: 2004-07-26 Version: 2.00 URL: <http://css.nu/faq/ciwas-mFAQ.html> Maintainer: Jan Roland Eriksson...
0
by: Jan Roland Eriksson | last post by:
Archive-name: www/stylesheets/newsgroup-faq Posting-Frequency: once a week Last-modified: 2004-07-26 Version: 2.00 URL: <http://css.nu/faq/ciwas-mFAQ.html> Maintainer: Jan Roland Eriksson...
0
by: Jan Roland Eriksson | last post by:
Archive-name: www/stylesheets/newsgroup-faq Posting-Frequency: once a week Last-modified: 2004-07-26 Version: 2.00 URL: <http://css.nu/faq/ciwas-mFAQ.html> Maintainer: Jan Roland Eriksson...
5
by: Jan Roland Eriksson | last post by:
Archive-name: www/stylesheets/newsgroup-faq Posting-Frequency: once a week Last-modified: 2004-07-26 Version: 2.00 URL: <http://css.nu/faq/ciwas-mFAQ.html> Maintainer: Jan Roland Eriksson...
0
by: Jan Roland Eriksson | last post by:
Archive-name: www/stylesheets/newsgroup-faq Posting-Frequency: once a week Last-modified: 2004-07-26 Version: 2.00 URL: <http://css.nu/faq/ciwas-mFAQ.html> Maintainer: Jan Roland Eriksson...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.