Hi All,
 
The way I see it, the URIs for an appmod, .yaws page or .cgi/.php etc page are of the same basic structure
 
e.g
http://someserver.xyz/folder/appmod/a/b/c
http://someserver.xyz/folder/x.yaws/a/b/c
http://someserver.xyz/folder/run.cgi/a/b/c
 
(all also optionally have querystrings of course)
 
In all cases, we have one path segment representing the 'script' or 'appmod' that splits the  URI into prepath, script/appmod, pathinfo (though prepath and/or pathinfo may also be empty)
where in the above cases:
prepath = /folder
pathinfo = /a/b/c
 
The appmod case however is currently handled a bit differently in the ARG record
 
For the appmod case we have:
 
arg.appmoddata = a/b/c
arg.pathinfo = undefined
 
for the .yaws / .cgi (etc ) case we have:
 
arg.appmoddata = undefined
arg.pathinfo = /a/b/c
 
ie - essentially the same information - but appmoddata is missing a leading slash.
 
This asymmetric behaviour disturbs me..
I'd like to set arg.pathinfo  to /a/b/c in both cases.  (corresponds to cgi PATH_INFO variable)
 
I guess arg.appmoddata should stay as it is for backward compatibility
- but can presumably be marked as deprecated in the docs at least.(?)
 
Why do we need the appmoddata field in the ARG record?
 
I'm also suspicious of the appmod_prepath member.
Again - the prepath is a concept that can apply to URIs that aren't related to appmods - so it should just be arg.prepath and always set when we have some sort of path-split for a dynamic URI.
 
Whilst I'm about to make a change in Yaws that requires a change to the ARG record anyway (additional vdir field).. should I also deprecate appmod_prepath by adding
in another field of just 'prepath' which just holds the same info for now?  (then for neatness the docs could state that all ARG fields  'appmod*'  are deprecated)
 
Comments anyone?
 
Julian Noble