nms-cgi-devel — Developers discussion for NMS CGI programs

RE: [Nms-cgi-devel] WWWBoard2 - PLEASE RESPOND

[Simon W. <es...@ou...>]

On Tue, 2003-01-21 at 15:34, Wizard wrote:
> 
> >
> > Fair point but there is still an overhead in doing the regexes when my
> > format uses simple splits. Plus you need to factor in the recursiveness
> > of the format. Not that it won't work just fine but mine seems simpler
> > to implement and less resource hungry.
> 
> If you're saying that the index file will only contain the hierarchy (by
> ID?) and no message data, then I think I get what you're saying. That would
> be much faster for posting, but for viewing the index page we're then
> talking about open & close on each and every message file to get the
> subject, user, email and date. I'd guess that much disk access is going to
> be much slower than the benefit of speeding up edits. If you're talking
> about including everything but the message text, then I can see the split
> being a benefit over regexes. I think I would use an alternate delimiter,
> though (maybe '::' or '||').

Yes, I imagined that index would have just the hierarchy in it. I would
hope that most pages would be cached so that there isn't a large
overhead in returning a view. Only when updating a page (with a new
post) would there be much processing. Then the index is used to identify
which data files need to be pulled in to build a new view page.

I guess it depends a lot on how many viewing options there are, both
statically (different layout options defined in a configuration file
somewhere) and dynamically (search results, partial threads etc).

Simon.

RE: [Nms-cgi-devel] WWWBoard2 - PLEASE RESPOND

[Wizard <wi...@ne...>]

>
> Fair point but there is still an overhead in doing the regexes when my
> format uses simple splits. Plus you need to factor in the recursiveness
> of the format. Not that it won't work just fine but mine seems simpler
> to implement and less resource hungry.

If you're saying that the index file will only contain the hierarchy (by
ID?) and no message data, then I think I get what you're saying. That would
be much faster for posting, but for viewing the index page we're then
talking about open & close on each and every message file to get the
subject, user, email and date. I'd guess that much disk access is going to
be much slower than the benefit of speeding up edits. If you're talking
about including everything but the message text, then I can see the split
being a benefit over regexes. I think I would use an alternate delimiter,
though (maybe '::' or '||').


>
> I agree that looking to the future is good but since it will be a major
> upgrade to use a different backend or whatever I would suggest that as
> long as we have the file IO in a module that provides a standard
> interface, the implementation can be changed at any time.
>
> Munging the datastore to fit whatever new strategy you want to use
> should be straightforward.

I honestly could care less about XML, but I thought that being an in-use
standard might lead to greater acceptance over a proprietary format. It's
'Give the people what they want', as far as I'm concerned. What is it they
want?

> Did you see one big xml file ?

Yes, or one wwwindex.xml with everything but individual message text, which
would be separate files.

> If so, it will need to be locked while you write out a new one with the
> new post in it. This may have performance issues.

Yes, if it includes the message text. If it's just the index with an XML (or
whatever) thread similar to what we have now in wwwboard.html, then it
should be faster than what we have now due to lack of XHTML
formatting/header/form/footer output.
>
> I'll try and work up some examples of what I mean as soon as possible
> but I'm at work right now and I should be doing other things :)

Ok, when you have a moment. I don't believe this will be resolved today ;-).
Grant M.

RE: [Nms-cgi-devel] WWWBoard2 - PLEASE RESPOND

[Wizard <wi...@ne...>]

> How about having a 'send mail to admin when there's a post'
> feature (which people have asked for in wwwboard) and making the
> threading optional ?

Actually, I was thinking it might be nice if we could have a subscription
sendmail, so that you could sign-up for specific message responses. I
actually already have something like this for NeonDB
(http://www.neonedge.com/neondb.html - which I still have to finish). Let me
know what you think, but first things first.

> Will it be fixed at one message per page, or will it be possible
> for this thing to render a whole thread (or several threads) on
> a single big HTML page ?

Do you mean message text also, or just per thread displays? Regardless, if
were using a script to parse and display, I guess we can pretty much do what
we want.

>
> If those are features that you're interested in putting in then
> it would be possible to configure this thing as a guestbook
> instead of using it as a wwwboard, which would be a bonus.  We
> get two advanced scripts for the price of one.
>
> > 1.> WWWBoard2 stores XML for the main page and all messages.
> > 2.> WWWBoard2 transforms this when requested using a header,
> footer and data
> > template, like this (pseudo-code):
> >    <List-View>
> >    a.> Request for virtual wwwboard.html (which is now wwwview.pl)
> >    b.> The wwwheader.html file is read and printed.
> >    c.> The XML is parsed into the wwwdata.html and printed
> >    d.> The wwwfooter.html file is read and printed.
> >
> > Note: Yes, I realize that a single template would be simpler
> for the user,
> > but it would require much more complex parsing, which would be
> much slower
> > (and more server load).
>
> If you're going to be using a template then you don't need header and
> footer files, since the users can just put the header HTML at the top
> of the template and the footer HTML at the bottom.
>
> I don't think that would be any slower than reading in the two extra
> files.

Maybe, but I don't have to parse the files at all if their just static. With
a Header/Footer combo file, I have to parse to where the data templates
should start and reparse or retain until all of the data has been output in
order to put the footer. I'll DProf both and we'll see.

> The existing wwwboard shows the thread as a message hierarchy at the top
> of the message view page, will wwwboard2 be able to do that ?

This is the idea. The XML hierarchy duplicates the message hierarchy.

> If you're rendering the index page then the user could define a template
> for the page as a whole:
<SNIP>

If I'm getting what you wrote, that's the whole idea.

Grant M.

RE: [Nms-cgi-devel] WWWBoard2 - PLEASE RESPOND

[Wizard <wi...@ne...>]

> The header and footer may be useful if done in XHTML, wouldn't
> that help the
> required admin script to process the page using similar XML based logic?

Sorry, I meant XHTML. If you mean would I use the same parser that I use on
the XML data to parse the XHTML templates, then 'No'. The parser for the
templates would be similar to the existing WWWBoard, by which I mean it will
use tags as placemarks. Something like:
<a href="EMAIL_TAG_DATAITEM" class="username">USER_TAG_DATAITEM</a>
<a href="MSGURL_TAG_DATAITEM" class="subject">SUBJECT_TAG_DATAITEM</a>
where the *_TAG_DATAITEM tags would be parsed into the appropriate data
fields.

> >         <email>de...@nu...</email>
>
> Wouldn't that @ need to be escaped as an XML entity?

Yes, I suppose it should.

> > Note the nesting. This would require recursive calls to the
> data templating
> > mechanism which I just realized and need to think about (suggestions
> > welcome).
>
> How about a dedicated tag that just takes care of the list of follow-up
> identifiers? Then the rest could just be a list of message tags.

Do you mean the ID? Maybe, but we'll need the id's for wwwviewing the
message by itself. Let me think on it.

>
> > I'm not sure if I should just go ahead and put the message body
> in here and
> > make the whole mess one file, only displaying the information requested
> > (mainview or messageview).
>
> I'd say not (but then my knowledge of Perl is sketchy), I use PHP
> for most
> site work and I tend to use references to large bodies of text instead of
> including the entire text. The only thing then is using some kind
> of blanking
> to stop people accessing the referenced file directly (again, PHP
> makes this
> easy using a redirect, how Perl can do this for files outside
> cgi-bin I'm not
> sure.)

I don't know that we care if someone wants to see the XML file directly. The
data wouldn't be in the view page if it wasn't suppose to be. For example a
moderated message wouldn't be parsed into output, and neither would the
message text if we were on the index page.

Grant M.

RE: [Nms-cgi-devel] WWWBoard2 - PLEASE RESPOND

[Simon W. <es...@ou...>]

On Tue, 2003-01-21 at 14:34, Wizard wrote:
> <SNIP>
> > Then the index looks like:
> > 
> > 12+: 14 17 18
> 
> I'm not sure that if we have an expected XML hierarchy, how this is any different. It's one thing to have a format with unexpected input (i.e, true XML), but I don't see that parsing a defined XML format is any different than parsing an HTML format, except that the hierarchy is more determinate. The plus is that should we decide to later include full XML parsing, then the formats is already there. I think that this would ease the implementation of future enhancements such as database backends, XSLT, and document conversion.
> 

Fair point but there is still an overhead in doing the regexes when my
format uses simple splits. Plus you need to factor in the recursiveness
of the format. Not that it won't work just fine but mine seems simpler
to implement and less resource hungry.

I agree that looking to the future is good but since it will be a major
upgrade to use a different backend or whatever I would suggest that as
long as we have the file IO in a module that provides a standard
interface, the implementation can be changed at any time.

Munging the datastore to fit whatever new strategy you want to use
should be straightforward.

> > 
> > and contains a list of messages and the responses to it. The + indicates
> > that the message is the head of a thread.
> > 
> > A script would be provided to rebuild the index from the data files.
> > 
> > In use, html pages would be generated for each thread and cached, either
> > on request or on change.
> > 
> > If the data set got very large then it could be extended by adding a
> > threadhead: field to the data format and extending the index to store
> > *all* the responses in that thread which would cut down the amount of
> > data that would need to be read in any one go.
> 
> I'm not sure that I'm really grasping all of this (read 'my brain hurts'), but perhaps you could patch together some example files with comments, and I'll trying to get a better understanding. I'm thinking 'singly-linked list', but it's just not working out in my head.
> Thanks!

Did you see one big xml file ?

If so, it will need to be locked while you write out a new one with the
new post in it. This may have performance issues.

I'll try and work up some examples of what I mean as soon as possible
but I'm at work right now and I should be doing other things :)

S.

Re: [Nms-cgi-devel] WWWBoard2 - PLEASE RESPOND

[Nick C. <ni...@cl...>]

On Tue, Jan 21, 2003 at 07:08:20AM -0500, Wizard wrote:
> Here's what I have in mind for WWWBoard2, along the lines of TFMail:

[SNIP]

How about having a 'send mail to admin when there's a post'
feature (which people have asked for in wwwboard) and making the
threading optional ?

Will it be fixed at one message per page, or will it be possible
for this thing to render a whole thread (or several threads) on
a single big HTML page ?

If those are features that you're interested in putting in then
it would be possible to configure this thing as a guestbook
instead of using it as a wwwboard, which would be a bonus.  We
get two advanced scripts for the price of one.

> 1.> WWWBoard2 stores XML for the main page and all messages.
> 2.> WWWBoard2 transforms this when requested using a header, footer and data
> template, like this (pseudo-code):
>    <List-View>
>    a.> Request for virtual wwwboard.html (which is now wwwview.pl)
>    b.> The wwwheader.html file is read and printed.
>    c.> The XML is parsed into the wwwdata.html and printed
>    d.> The wwwfooter.html file is read and printed.
>
> Note: Yes, I realize that a single template would be simpler for the user,
> but it would require much more complex parsing, which would be much slower
> (and more server load).

If you're going to be using a template then you don't need header and
footer files, since the users can just put the header HTML at the top
of the template and the footer HTML at the bottom.

I don't think that would be any slower than reading in the two extra
files.

> Perhaps I could include a utility to pre-parse a
> full HTML template? I am not using XSLT for the simple reason that it would
> be much more complex, parsing-wise, and as we're not using CPAN modules, I'm
> not going to reinvent the wheel. This may happen sometime later when we've
> converted the masses.
> 
>    <Message-View>
>    a.> A particular message is selected (wwwview.pl?message=419)
>    b.> If exist wwwmheader.html else wwwheader.html is parsed w/title &
> printed.
>    c.> The XML message is parsed into the wwwmessage.html and printed
>    d.> If exist wwwmfooter.html else wwwfooter.html is parsed w/thread &
> printed.

The existing wwwboard shows the thread as a message hierarchy at the top
of the message view page, will wwwboard2 be able to do that ?

> I suspect that the XML for the main page will look like this:
> 
> <MessID name="14">
>     <subject>NMS scripts are great!</subject>
>     <user>The Professor</user>
>     <email>fr...@fs...</email>
>     <date>20/01/03</date>
>     <moderate>0</moderate>
>     <MessID name="17">
>         <subject>Re: NMS scripts are great!</subject>
>         <user>The Wizard</user>
>         <email>de...@nu...</email>
>         <date>22/01/03</date>
>         <moderate>0</moderate>
>     </MessID>
> </MessID>
> 
> Note the nesting. This would require recursive calls to the data templating
> mechanism which I just realized and need to think about (suggestions
> welcome).

If you're rendering the index page then the user could define a template
for the page as a whole:

  <html>
  <head><title>wwwboard</title></head>
  <body>
   <h1>Thread Index</h1> 
   <hr />
   <ul>
    [% messages %]
   </ul>
  </body>
 </html>

... and they would define a separate template that tells the script how
to render the index line for a particular message:

  <li>
   <b>[% user %]</b> ([% email %]) ([% date %])
   [% IF there_are_followups %]
   <ul>
    [% messages %]
   </ul>
   [% END %]
  </li>

... and the template code would apply the second template recursively
when it hit the [% messages %] directive in the main template, and
you'd get the tree structure appearing.

--
Nick

RE: [Nms-cgi-devel] WWWBoard2 - PLEASE RESPOND

[Wizard <wi...@ne...>]

<SNIP>
> Then the index looks like:
>=20
> 12+: 14 17 18

I'm not sure that if we have an expected XML hierarchy, how this is any =
different. It's one thing to have a format with unexpected input (i.e, =
true XML), but I don't see that parsing a defined XML format is any =
different than parsing an HTML format, except that the hierarchy is more =
determinate. The plus is that should we decide to later include full XML =
parsing, then the formats is already there. I think that this would ease =
the implementation of future enhancements such as database backends, =
XSLT, and document conversion.

>=20
> and contains a list of messages and the responses to it. The + =
indicates
> that the message is the head of a thread.
>=20
> A script would be provided to rebuild the index from the data files.
>=20
> In use, html pages would be generated for each thread and cached, =
either
> on request or on change.
>=20
> If the data set got very large then it could be extended by adding a
> threadhead: field to the data format and extending the index to store
> *all* the responses in that thread which would cut down the amount of
> data that would need to be read in any one go.

I'm not sure that I'm really grasping all of this (read 'my brain =
hurts'), but perhaps you could patch together some example files with =
comments, and I'll trying to get a better understanding. I'm thinking =
'singly-linked list', but it's just not working out in my head.
Thanks!
Grant M.

Re: [Nms-cgi-devel] WWWBoard2 - PLEASE RESPOND

[Simon W. <es...@ou...>]

On Tue, 2003-01-21 at 13:56, Nicholas Clark wrote:
> On Tue, Jan 21, 2003 at 01:44:18PM +0000, Simon Wilcox wrote:
> > and contains a list of messages and the responses to it. The + indicates
> > that the message is the head of a thread.
> 
> Might this create lots of small files very quickly?
> If so, this would be a pain. (Although it reduces the problem of locking
> files - you only need to lock whichever file holds the next message
> number to use)

Yes, it might. I hadn't actually thought of the locking issue but that's
another plus point in it's favour.

> If so, either create subdirectories on demand and put some maximum number of
> files per subdirectory (eg 100, 256, 1000)

Good approach. Perhaps a message id in the form of 001001 which can be
broken out easily into directory and file.

What's the limit where linux swaps from a tree search to a linear search
algorithm ? we should stick below that.

> Alternatively store more than one message per file, and extend the index
> format to store message number, file start offset and length for each
> message. (And binmode the file, so that seeks work nicely on Windows
> servers)

Could work but maybe more complicated than we need.

> Just a thought, and possibly going down completely the wrong track.

No, I think it is a good point.

S.

Re: [Nms-cgi-devel] WWWBoard2 - PLEASE RESPOND

[Nicholas C. <ni...@cc...>]

On Tue, Jan 21, 2003 at 01:44:18PM +0000, Simon Wilcox wrote:
> On Tue, 2003-01-21 at 12:08, Wizard wrote:
> > Here's what I have in mind for WWWBoard2, along the lines of TFMail:
> 
> XML is a bitch to parse without using modules that we don't want to have
> people install. It's also slooooow. I'd suggest a format that has one

<AOL/>

:-)

> message per file and an index of related messages, perhaps something
> like this:
> 
> id: 14
> respondsto:12
> subject:NMS scripts are great!
> user:The Professor
> email:fr...@fs...
> date:20/01/03
> moderate:0
> body:
> Some body text on multiple
> lines up to the end of
> the file
> 
> Then the index looks like:
> 
> 12+: 14 17 18
> 
> and contains a list of messages and the responses to it. The + indicates
> that the message is the head of a thread.

Might this create lots of small files very quickly?
If so, this would be a pain. (Although it reduces the problem of locking
files - you only need to lock whichever file holds the next message
number to use)
If so, either create subdirectories on demand and put some maximum number of
files per subdirectory (eg 100, 256, 1000)
Alternatively store more than one message per file, and extend the index
format to store message number, file start offset and length for each
message. (And binmode the file, so that seeks work nicely on Windows
servers)


Just a thought, and possibly going down completely the wrong track.

Nicholas Clark

Re: [Nms-cgi-devel] more moving somewhere...

[Nick C. <ni...@cl...>]

On Tue, Jan 21, 2003 at 05:57:05AM -0500, Wizard wrote:
> 1.> per Nick's modules, why do we have to inline modules? why not create a
> local /lib/dir and use libs? This way, if modules end up being shared
> between NMS scripts, were not duplicating efforts/installs (and you only
> have to update them once). We'll probably want a separate CVS tree, though.

The local /lib/dir approach is better, for all the reasons you state.

However, we're aiming to provide plugin replacements for Matt's scripts,
and some users can't or won't upload a load of .pm files to a web
server, so we need standalone scripts.

Here's a plan to get the best of both worlds:

In CVS, we will use the local lib dir approach.  We will think in terms
of a local lib dir when writing the scripts and modules.  At release
time, we will release a package of the script with all its modules as
separate files, to go in a local lib dir.  That's almost done for
FormMail, see /v2/packages/formmail_modules/ in CVS.

To accommodate those users who insist that they want to upload a
standalone script (and take the efficiency and maintenance hit), at
every release a perl script will generate a version of the package with
all the modules it needs inlined into the CGI.  I've just started on
this for FormMail in /v2/packages/formmail_compat/ in CVS.
 
> 4.> What the hell am I supposed to be doing with WWWBoard (so far the only
> thing that I've done is add a stylesheet and a no-cache pragma)? I would
> like to modularize it, but I find myself asking 'why?' if we are just
> inlining it.

Well, I'd leave the existing wwwboard as it is apart from bug fixes,
and maybe look at starting on a de-inlined version under /v2.

--
Nick

Re: [Nms-cgi-devel] WWWBoard2 - PLEASE RESPOND

[Simon W. <es...@ou...>]

On Tue, 2003-01-21 at 12:08, Wizard wrote:
> Here's what I have in mind for WWWBoard2, along the lines of TFMail:

XML is a bitch to parse without using modules that we don't want to have
people install. It's also slooooow. I'd suggest a format that has one
message per file and an index of related messages, perhaps something
like this:

id: 14
respondsto:12
subject:NMS scripts are great!
user:The Professor
email:fr...@fs...
date:20/01/03
moderate:0
body:
Some body text on multiple
lines up to the end of
the file

Then the index looks like:

12+: 14 17 18

and contains a list of messages and the responses to it. The + indicates
that the message is the head of a thread.

A script would be provided to rebuild the index from the data files.

In use, html pages would be generated for each thread and cached, either
on request or on change.

If the data set got very large then it could be extended by adding a
threadhead: field to the data format and extending the index to store
*all* the responses in that thread which would cut down the amount of
data that would need to be read in any one go.

Just my =C2=A30.02.

Simon.

[Nms-cgi-devel] WWWBoard2 - PLEASE RESPOND

[Wizard <wi...@ne...>]

Here's what I have in mind for WWWBoard2, along the lines of TFMail:

1.> WWWBoard2 stores XML for the main page and all messages.
2.> WWWBoard2 transforms this when requested using a header, footer and data
template, like this (pseudo-code):
   <List-View>
   a.> Request for virtual wwwboard.html (which is now wwwview.pl)
   b.> The wwwheader.html file is read and printed.
   c.> The XML is parsed into the wwwdata.html and printed
   d.> The wwwfooter.html file is read and printed.

Note: Yes, I realize that a single template would be simpler for the user,
but it would require much more complex parsing, which would be much slower
(and more server load). Perhaps I could include a utility to pre-parse a
full HTML template? I am not using XSLT for the simple reason that it would
be much more complex, parsing-wise, and as we're not using CPAN modules, I'm
not going to reinvent the wheel. This may happen sometime later when we've
converted the masses.

   <Message-View>
   a.> A particular message is selected (wwwview.pl?message=419)
   b.> If exist wwwmheader.html else wwwheader.html is parsed w/title &
printed.
   c.> The XML message is parsed into the wwwmessage.html and printed
   d.> If exist wwwmfooter.html else wwwfooter.html is parsed w/thread &
printed.

I suspect that the XML for the main page will look like this:

<MessID name="14">
    <subject>NMS scripts are great!</subject>
    <user>The Professor</user>
    <email>fr...@fs...</email>
    <date>20/01/03</date>
    <moderate>0</moderate>
    <MessID name="17">
        <subject>Re: NMS scripts are great!</subject>
        <user>The Wizard</user>
        <email>de...@nu...</email>
        <date>22/01/03</date>
        <moderate>0</moderate>
    </MessID>
</MessID>

Note the nesting. This would require recursive calls to the data templating
mechanism which I just realized and need to think about (suggestions
welcome).

I'm not sure if I should just go ahead and put the message body in here and
make the whole mess one file, only displaying the information requested
(mainview or messageview).

The 'moderated' tag allows for the moderation of messages by the admin,
meaning if set to '1', the messages are not displayed to the user, except
during submittal. This could be set as the default, meaning that all new
messages are moderated until reviewed by the admin (or maybe only certain
users/ips/domains?).

This version could include a script to convert an existing WWWBoard to
WWWBoard2, although it'd require some extensive testing (due to the message
formats, not the wwwboard.html itself).

Let me know what you think,
Grant M.
wi...@ne...

[Nms-cgi-devel] more moving somewhere...

[Wizard <wi...@ne...>]

1.> per Nick's modules, why do we have to inline modules? why not create a
local /lib/dir and use libs? This way, if modules end up being shared
between NMS scripts, were not duplicating efforts/installs (and you only
have to update them once). We'll probably want a separate CVS tree, though.

2.> After going over the web pages on sourceforge, I have some questions:
    a.> on /projects/nms-cgi/, why is it that there appear to be so many
        different mailing lists? (4 Forums, Support, Bugs, and the mail
lists)
    b.> why is there not one for feature requests?
    c.> is there any way to add a 'view' that is script-specific (wwwboard,
formail, etc.,)?

3.> We need to create a testers list. As I suggested earlier, we might want
to try to get some of the ISPs in on this, as they have the most to
gain/lose.

4.> What the hell am I supposed to be doing with WWWBoard (so far the only
thing that I've done is add a stylesheet and a no-cache pragma)? I would
like to modularize it, but I find myself asking 'why?' if we are just
inlining it.

5.> I don't have an account to ci/co. Account please? Dave?

Damn, I need more coffee,
Grant M.
wi...@ne...

[Nms-cgi-devel] Re: Moving Ahead

[Bill W <ww...@b4...>]

Greetings All,

My suggestion on moving ahead is to either include a program
named perldiver.cgi with the scripts or offer the download on
the script download page.

A lot of people have trouble finding or understanding what their
paths are and where some programs are located and which
modules they have installed on their server.

Just my humble opinion
Thank you
Bill W 

[Nms-cgi-devel] Re: Moving Ahead

[info <in...@b4...>]

Greetings All,

My suggestion on moving ahead is to either include a program
named perldiver.cgi with the scripts or offer the download on
the script download page.

A lot of people have trouble finding or understanding what their
paths are and where some programs are located and which
modules they have installed on their server.

Just my humble opinion
Thank you
Bill W

Re: [Nms-cgi-devel] Re: [Nms-cgi-support] Random Image Displayer Documentation ...

[Nick C. <ni...@cl...>]

On Wed, Jan 15, 2003 at 03:16:31PM -0500, Jason LaMar wrote:
> Olivier,
> 
> Thanks for following up on this.
> 
> Also, I wanted to point out a potential problem with the SSI Random Image
> Displayer documentation. In the "INSTALLATION" section, the HTML executable
> code suggests that you can call this script remotely (or locally) by simply
> putting in an absolute URL. I've just attempted this with two physically
> separate servers with different Linux/Apache configurations -- calling the
> script in one server's cgi-bin from an HTML page on the other server, and
> vice versa -- without success. I always get the "[an error occurred while
> processing this directive]" message.
> 
> In fact, I couldn't even get it to work after trying to execute the script
> on the SAME server using the URL method ... on BOTH servers. But as soon as
> I replaced this (example) code ...
> 
> <!--#exec cgi="http://your.host.com/cgi-bin/ssi_rand_image.pl"-->
> 
> ... with this (example) code ...
> 
> <!--#exec cgi="/server/path/to/cgi-bin/ssi_rand_image.pl"-->
> 
> ... the script worked fine on both servers. My only conclusion is that a
> relative system path is required in the HTML executable, rather than a URL.
> 
> Am I missing something here, or are cgi-bin directories typically supposed
> to allow remote calls when SSI is involved ... and these particular two
> servers are an exception to the rule?

No, SSI exec only works on the local server.  If you want to embed
random images from one server on a page on another server then you'll
have to use rand_image rather than ssi_rand_image.

--
Nick

Re: [Nms-cgi-devel] Moving Ahead - pt 2

[Nick C. <ni...@cl...>]

On Tue, Jan 14, 2003 at 07:25:09PM +0000, Dave Cross wrote:
> 
> I think I saw people volunteering to get more involved with simple 
> search and wwwboard - which is great. Thanks people :) We also need
> someone to volunteer to take on guestbook. Anyone fancy it?
> 

If there are no takers, we could lump guestbook in with FormMail and
TFmail, which makes sense since those three are the only scripts that
send email IIRC.

--
Nick

RE: [Nms-cgi-devel] Re: [Nms-cgi-support] Random Image Displayer Documentation ...

[Wizard <wi...@ne...>]

exec cgi (from the Apache Book) -
The value specifies a %encoded URL relative path to the CGI script.

That's your answer. I don't know of any SSI that takes a full path. The
other method of doing this is <!--#include virtual="/cgi-bin/script.pl"-->.

Grant M.

> -----Original Message-----
> From: nms...@li...
> [mailto:nms...@li...]On Behalf Of Jason
> LaMar
> Sent: Wednesday, January 15, 2003 3:17 PM
> To: Olivier Dragon
> Cc: NMS-devel
> Subject: [Nms-cgi-devel] Re: [Nms-cgi-support] Random Image Displayer
> Documentation ...
>
>
> Olivier,
>
> Thanks for following up on this.
>
> Also, I wanted to point out a potential problem with the SSI Random Image
> Displayer documentation. In the "INSTALLATION" section, the HTML
> executable
> code suggests that you can call this script remotely (or locally)
> by simply
> putting in an absolute URL. I've just attempted this with two physically
> separate servers with different Linux/Apache configurations -- calling the
> script in one server's cgi-bin from an HTML page on the other server, and
> vice versa -- without success. I always get the "[an error occurred while
> processing this directive]" message.
>
> In fact, I couldn't even get it to work after trying to execute the script
> on the SAME server using the URL method ... on BOTH servers. But
> as soon as
> I replaced this (example) code ...
>
> <!--#exec cgi="http://your.host.com/cgi-bin/ssi_rand_image.pl"-->
>
> ... with this (example) code ...
>
> <!--#exec cgi="/server/path/to/cgi-bin/ssi_rand_image.pl"-->
>
> ... the script worked fine on both servers. My only conclusion is that a
> relative system path is required in the HTML executable, rather
> than a URL.
>
> Am I missing something here, or are cgi-bin directories typically supposed
> to allow remote calls when SSI is involved ... and these particular two
> servers are an exception to the rule?
>
> Jason
>
> __________________________________________________________
>
> Jason LaMar                  tel >> 740-368-3307
> Director of Web Services     fax >> 740-368-3328
> Ohio Wesleyan University     e-mail >> jr...@ow...
> Delaware, OH 43015           online >> http://web.owu.edu/
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: A Thawte Code Signing Certificate
> is essential in establishing user confidence by providing assurance of
> authenticity and code integrity. Download our Free Code Signing guide:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
> _______________________________________________
> Nms-cgi-devel mailing list
> Nms...@li...
> https://lists.sourceforge.net/lists/listinfo/nms-cgi-devel
>

[Nms-cgi-devel] Re: [Nms-cgi-support] Random Image Displayer Documentation ...

[Jason L. <jr...@ow...>]

Olivier,

Thanks for following up on this.

Also, I wanted to point out a potential problem with the SSI Random Image
Displayer documentation. In the "INSTALLATION" section, the HTML executable
code suggests that you can call this script remotely (or locally) by simply
putting in an absolute URL. I've just attempted this with two physically
separate servers with different Linux/Apache configurations -- calling the
script in one server's cgi-bin from an HTML page on the other server, and
vice versa -- without success. I always get the "[an error occurred while
processing this directive]" message.

In fact, I couldn't even get it to work after trying to execute the script
on the SAME server using the URL method ... on BOTH servers. But as soon as
I replaced this (example) code ...

<!--#exec cgi="http://your.host.com/cgi-bin/ssi_rand_image.pl"-->

... with this (example) code ...

<!--#exec cgi="/server/path/to/cgi-bin/ssi_rand_image.pl"-->

... the script worked fine on both servers. My only conclusion is that a
relative system path is required in the HTML executable, rather than a URL.

Am I missing something here, or are cgi-bin directories typically supposed
to allow remote calls when SSI is involved ... and these particular two
servers are an exception to the rule?

Jason

__________________________________________________________

Jason LaMar                  tel >> 740-368-3307
Director of Web Services     fax >> 740-368-3328
Ohio Wesleyan University     e-mail >> jr...@ow...
Delaware, OH 43015           online >> http://web.owu.edu/

[Nms-cgi-devel] Re: [Nms-cgi-support] Random Image Displayer Documentation ...

[Olivier D. <dr...@sh...>]

Thank you very much Jason for pointing this out. I'm forwarding this
email to the developer's mailing list so that it can be fixed.

Glad to see you like the scripts!

-Olivier

On Wed, Jan 15, 2003 at 10:01:20AM -0500, Jason LaMar wrote:
> Hi. I've started using many NMS scripts on our university's main Web server,
> and I've been very pleased with the results.
> 
> In reviewing the README file for Random Image Displayer, however, I think I
> found some confusing instructions. Under the "CONFIGURATION" section, only
> $basedir is listed as a variable ... yet $baseurl is also included in the
> script itself. Also, it appears that the $basedir instructions actually
> apply to the $baseurl variable. (You must use a relative system path with
> $basedir ... not a URL, yes?)
> 
> Although the in-script comments about which variable to set and why (based
> on a redirect or a direct server call) make sense to me, I wonder if
> less-experienced script users might get confused with the README file.
> 
> One other typo, while I'm looking at it: There's no period at the end of the
> first paragraph under the "INSTALLATION" section (after "system
> administrator").
> 
> 
> 
> Just FYI ... and thanks for creating such great scripts,
> 
> Jason
> 
> __________________________________________________________
> 
> Jason LaMar                  tel >> 740-368-3307
> Director of Web Services     fax >> 740-368-3328
> Ohio Wesleyan University     e-mail >> jr...@ow...
> Delaware, OH 43015           online >> http://web.owu.edu/
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: Take your first step towards giving 
> your online business a competitive advantage. Test-drive a Thawte SSL 
> certificate - our easy online guide will show you how. Click here to get 
> started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
> _______________________________________________
> IMPORTANT NOTE:
> 
> Please use mail software's "Reply-All" or "Reply Group" feature
> when replying to this mail.
> Just using "Reply" _won't_ send the mail to the mailing list.

-- 
                  __-/|    ? ?     |\-__
             __--/  /  \   (^^)   /  \  \--__
          _-/   /   /   \ / ( )  /   \   \   \-_
         /  /   /  /     ~(  ^^ ~     \  \   \  \
         / Oli Dragon    dr...@sh... \
        /  Sfwr Eng III  (  McMaster University  \
        /  /  /     __--_ (   ) __--__     \  \  \
        |  /  /  _/        \_ \_       \_  \  \  |
         \/  / _/            \_ \_       \_ \  \/
          \_/ /                -\_\        \ \_/
            \/                   -)         \/
                                *~
 ___--<******************************************************>--___
[http://pgp.mit.edu:11371/pks/lookup?search=olivier+dragon&op=index]
 ~~~--<******************************************************>--~~~

RE: [Nms-cgi-devel] Re: [Nms-cgi-support] form could not be received

[Wizard <wi...@ne...>]

Matbe it's just me, but I can't even get the contact.html form.
Grant M.

<snip>

> > > > On my website www.mehtaonline.com/contact.html
> > > >
> > > > After filling the form t"the page could not found" message 
> is displayed
> > > >
> > > > Please let me know how to correct the error.
> > >
> > > Your form is configured to use the formmail script at:
> > >
> > > http://www.mehtaonline.com/cgi-sys/formmail.pl
> > >
> > > This address doesn't exist. Are you sure it's right? The 'cgi-sys'
> > > part seems unusual. 'cgi-bin' would be more usual.
> 
> -- 
>   And crawling on the planet's face, some insects called the human race
>   Lost in time, and lost in space. And meaning.
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: Take your first step towards giving 
> your online business a competitive advantage. Test-drive a Thawte SSL 
> certificate - our easy online guide will show you how. Click here to get 
> started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
> _______________________________________________
> Nms-cgi-devel mailing list
> Nms...@li...
> https://lists.sourceforge.net/lists/listinfo/nms-cgi-devel
> 

Re: [Nms-cgi-devel] Moving Ahead - pt 2

[Nick C. <ni...@cl...>]

On Wed, Jan 15, 2003 at 09:27:16AM +0000, Nicholas Clark wrote:
> > 
> > So now is the time to spot methods that could be better named and areas
> > where code could be better divided into methods.
> > 
> > Once there's a release from this branch, it will be too late.
> 
> Could you remind us (well, me at least) how and where to get the correct
> branch?

In the NMS CVS tree, under a /v2 prefix.

  /v2/lib/CGI/NMS/Script/FormMail.pm
  /v2/lib/CGI/NMS/Script.pm
  /v2/lib/CGI/NMS/Validator.pm
  /v2/lib/CGI/NMS/Charset.pm
  /v2/lib/CGI/NMS/Mailer.pm
  /v2/lib/CGI/NMS/Mailer/Sendmail.pm
  /v2/lib/CGI/NMS/Mailer/SMTP.pm

--
Nick

Re: [Nms-cgi-devel] Moving Ahead - pt 2

[Nicholas C. <ni...@cc...>]

On Wed, Jan 15, 2003 at 08:24:26AM +0000, Nick Cleaton wrote:
> That reminds me: the user customisation scheme for these modules makes
> it impossible for us to rename the methods in the modules without the
> risk of breaking scripts that include customisations.
> 
> So now is the time to spot methods that could be better named and areas
> where code could be better divided into methods.
> 
> Once there's a release from this branch, it will be too late.

Could you remind us (well, me at least) how and where to get the correct
branch?

[As a quantitative example of how lowering the entry condition from
"lift your backside" to "lift a finger" I notice that
http://www.stand.org.uk/ have got >3600 submissions to the Home Office
in 4 days, while the Home Office itself could only get 1500 in 6 months.

Impressive. I hope Mr Blunkett's speech writers are enjoying working out
how to boast about the much increased interested. :-)]

Nicholas Clark

Re: [Nms-cgi-devel] Moving Ahead - pt 2

[Nick C. <ni...@cl...>]

On Tue, Jan 14, 2003 at 07:25:09PM +0000, Dave Cross wrote:
> Thanks for all your comments. Rather than reply to each point individually
> here's an idea of what I'm now thinking.
> 
> I'd hate to lose people like Nick Clark from the devel list. He might not
> say much, but when he does it's always worth listening to :) So I agree
> that closing the devel list is a bad idea.
> 
> Support - I still like the idea of having people whose responsibility
> it is to answer support emails on a rota system, but I do agree with 
> what Nick and Simon said about even our worst efforts being better than
> Matt's current level of support. So how about this:
> 
> 1/ Some sort of SLA on the web site saying that we intend to respond to
> all emails within 24 hours.

Sounds fair.

> 2/ The individual script owners still assign a support rota within their
> group, but that person has the job of "mopping up" - that is checking
> for emails that haven't been answered in 18 hours and posting a reply
> (even if that reply is "the expert on that problem will be back online
> in 12 hours".

Sounds reasonable.  The same 18 hour timeout could be used for the
person coming onto rota to take over ongoing conversations between users
and the person previously on rota, if the previous person doesn't reply.

> 3/ The script owners need to ensure that more people in their group
> are skilled enough to answer support emails.

Yes, definitely.

> 4/ The script owners can decide on their own rules about how to avoid
> the multiple reply problem for the scripts they are responsible for.
> For example Nick Cleaton might say, "no-one should answer a question
> on formmail or tfmail in the morning (uk time) until I've got to work
> and posted all they replies I drafted on the train".

Surely that won't be an issue if there's a rota, because the person
on front line support that $timeperiod will be the only one to reply
anyway.

[SNIP] 

> And Nick, I think your modular ideas are great. Once we've assigned all
> of the "team leader" roles, can you please start to talk with them about
> how the other scripts can use your ideas.

Yes, OK.

That reminds me: the user customisation scheme for these modules makes
it impossible for us to rename the methods in the modules without the
risk of breaking scripts that include customisations.

So now is the time to spot methods that could be better named and areas
where code could be better divided into methods.

Once there's a release from this branch, it will be too late.

--
Nick

Re: [Nms-cgi-devel] Re: [Nms-cgi-support] FFA tweaklet

[Dave C. <da...@da...>]

On Tue, Jan 14, 2003 at 09:46:18PM +0000, Nick Cleaton (ni...@cl...) wrote:
> On Tue, Jan 14, 2003 at 08:45:50AM -0800, Angus Scott-Fleming wrote:
> > 
> > Suggest you change the line: 
> >  
> > Sorry, this link is already in the Free For All Link Page 
> >  
> > to read  
> >  
> > Sorry, this link is already in the $linkstitle 
> 
> This seems reasonable to me - objections anyone ?

None from me.

Dave...

-- 
  Love is a fire of flaming brandy
  Upon a crepe suzette