explaining it more (Re: [Lispweb] regarding a URL and IMHO (was re: IMHO + mod_lisp))

[Sean Champ]

I've found that some of my assumptions had been incorrect, about
why a browser-request to a URL with only a mount-point would be
resulting (somewhere in IMHO, and in mod_webapp) resulting in some
unexpected behaviors -- as addressed in the prior email, and the
thread prior to it (referenced in the prior email of this thread)


More than that my assumptions were incorrect, there is a minor change,
which may be made to the code, to eliminate the  occurrance of the
"Cannot switch to passive mode" message, in the browser, as Ng Pheng
Siong had indicated.


Regarding the URL http://localhost/testapp1/testapp1 (and in the
structure of it, that URL may be understood as containing (firstly)
the name of the mount-point testapp1 and (secondly) the name of the
applicaton testapp1.)


I had thought
> 
> Terminological summary: 
> 
> The second 'testapp1' in the URL there, it (might) identify the
> application, *within* the mount-point /testapp1/.
> 
> Technical summary:
> 
> In this case, the second 'testapp1'  is required, in order for
> PARSE-URI to have any useful side-effects -- like, enough for the
> request-response loop/cycle to get beyond the request with type,
> "request init uri".
> 

...and though I'm thinking that those are fine, as is, yet those were
not quite on the mark of the issue. The second summary nearly hits
it.



It appears that it is a matter of the DESTRUCTURING-BIND call in
PARSE-URI [ defined in application.lisp in IMHO ]


In a minor adjustment  of the destructuring-bind call in the body of
PARSE-URI, this, it works:

 (destructuring-bind (mount-point &optional app-id three four five six)
         path

In the adjusted form, the 'app-id' argument is moved to occur after
the &optional keyword.


There are cases when 'path' will contain only one element -- as when
IMHO would be answering a request to the URL
http://localhost/testapp1/ when 'testapp1' would name only the  mount
point. 

In the earlier form of the call, when there was no value,
complementary to the 'app-id' argument, and with this form of it:

  (destructuring-bind (mount-point app-id ... 

...then it was just silently failing (curious, possibly, if one might
expect an error message, there, about the destructuring-bind spec not
matching the value given for it). Yet, that minor thing of the
argument-pattern, in the adjusted form of the call, it serves to 
resolve the (above) indicated  matter of requests in IMHO.


Furthermore, with that moving of the &optional keyword, and with no
other changes, the browser will dispaly the "Application not found"
message, after making a request to a URL that represents only a
mount-point. It appears that this was intended.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Additional thoughts:

There could be a revision made, so that an application -- e.g. "the
NIL applicaton" -- may be bound, specificaly, exclusively, to a given
mount-point. "The NIL appliation" could be exectuted, whether or not
in exclusion of any other applications that might be bound /with
names/, upon the mount-point. 

(Certainly, the NIL applciation would have to not produce any URLs that
would conflict with any of the applications upon the mount-point;
otherwise, unexpected behaviors would occur, such that coud be hard
to track, as a consequence of name-collisions in URLs)


I do not mean to squash any proposals, by mentioning the following,
but just to disclose the matter, plainly:

I've reached a point, addressing how a SERVER class may be defined
for the support of multiple connector-socket connections in IMHO, and
some of how it would be applied. I've been documenting it, for
implementation -- collecting and organizing the notes  in a DocBook
document, as it's been. I  hope to address the matter of "the  NIL
application", when impementing the SERVER class.
 
The previous matter of some unexpected behavior has been fortuitous,
towards my own understanding of IMHO, towards some documentary notes,
and towards some additional proposals. So, even a quirk-digging
session can work out well.


Regarding how I have started addressing this, in the sofwtare of it:

Though my first concern has not been that I would make the code
public, for a branch being made of IMHO -- as of yesterday, somewhat 
foramlly -- and it is such that I would accept, and I hope to be clear
about this, if it might ever be merged back into  IMHO, though its'
being made, for now, as a branch. 

However, I look forward to sharing what patches that there will be,
for IMHO, when the branched code would be most notably "settled", into
a state of some done-ness, and removed of so many of my own comments
in the code -- brief things, all like simple notes, annotations about
"to-do items".



Anyhow, there's almost a patch, above.


Shotly, adios.


----
Sean Chamnp
schamp at commowerx.org