Constants as arguments

[Davin Church]

I would like to have a web request call an APL function with a constant value as part of the argument. This would be used when a single APL function is being called as a common interface point for multiple virtual paths and the constant argument being passed varies depending upon the virtual path being invoked.

For instance, a request to /goodpath/* would call APL function MyFn with an argument of 1, and a request to /badpath/* would call the same function with an argument of 0.

Is there some way to do this without writing a bunch of one-line cover functions to clutter up my workspace?

[joe_blaze]

The structure and features of a virtual path are not controlled by APL WebServices, but are defined more broadly by much larger entities, such as W3C.org. Essentially each virtual path, if it will perform different processing, needs to have a distinct server-side function associated with it.

In your case that means have some simple cover functions on the server side to handle your scenario or else the shared function needs to analyze the source request, including the virtual path, and based upon that virtual path select a processing option.

[Davin Church]

The structure and features of a virtual path are not controlled by APL WebServices, but are defined more broadly by much larger entities, such as W3C.org.

Really?!? As I understand it, the implementation of virtual paths is specific to APL Web Services which is only following the same general concepts that are used elsewhere in the web world. All I'm asking for is a way in the APLWS configuration interface to say "always pass this constant value to the called function". You already have so many different ways to pass in values, including some that I don't think are found anywhere else in the world, that it seems to me that a way to pass in a constant would be an obvious and simple enhancement.

In your case that means have some simple cover functions on the server side to handle your scenario or else the shared function needs to analyze the source request, including the virtual path, and based upon that virtual path select a processing option.

As I said, I don't want to have to clutter up my workspace with a bunch of one-line functions just to supply a constant argument to my main routine. This may not bother you, but it does me.

[joe_blaze]

Avoiding 'clutter in your workspace' would mean adding 'clutter' to the APL WebServices functionality for all users. Especially considering that a few simple cover functions will resolve your issue in a manner used by mainstream web services programmers.

Adding more unique-to-apl 'features' to APL WebServices would tend to draw the APL WebServices product further from the mainstream of web services functionality. This increases the risk that future mainstream web services changes would be potentially more difficult or impossible to support in APL WebServices.

[Davin Church]

Well, it can also mean that adding a little clutter to AWS could mean reducing clutter from everyone's workspaces, especially if I distribute my single-point-of-access code.

But if you think it's going to take significant effort to implement, then I guess it's not worth it and we can concentrate on my other "real" problems.