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
(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