[xquery-talk] xquery library design

[Jakob Fix]

Eric,

right now, the configuration data would simply contain a number of
details such as
- endpoint_url
- api_key
- secret
- user_id

the question really is whether one would want to use the library in
the same application with different configuration details. I hadn't
originally envisaged this, but Michael Kay makes this point in a
future message, so I'll think about this.

thanks,
Jakob.



On Wed, Dec 28, 2011 at 00:25, Eric Bloch <Eric.Bloch at marklogic.com> wrote:
> I presume persistent state (like configuration) is managed and specified differently for each xquery processor - as such, whatever you do may have some processor dependent code.
>
> E
>
> Eric Bloch
> eric.bloch at marklogic.com
>
>
>
> On Dec 27, 2011, at 3:13 PM, Jakob Fix wrote:
>
>> Hello,
>>
>> I'm about to write an xquery library and I'm curious whether there are
>> best practices around regarding the inclusion of other library modules
>> (a quick Google search didn't turn up anything useful).
>>
>> In particular, I'm interested in how one would implement this:
>>
>> - a library module (out of several)
>>  that uses configuration data specific for each application it is used in, and
>>  that itself makes use of lower-level functions.
>>
>> for example, a library module with a number of publicly exposed api
>> functions that each would take an "api_key" argument that is specific
>> to the application and probably stored in a separated configuration
>> file. Itself, it may make use of an http-get function defined in yet
>> another library module.
>>
>> I would like to avoid the case where each function signature needs to
>> have a required argument (the api_key and maybe others too) that could
>> be added much more elegantly by looking up a global variable read from
>> the configuration file.  For example, for the functions documented
>> here (http://developer.marklogic.com/pubs/5.0/apidocs/ec2-2009-11-30.html)
>> each function has always the same three arguments that serve to
>> identify the caller. In my case, there can be three such arguments,
>> but only one is required.
>>
>> instead of this
>> d:get-data($api_key as xs:string, $secret as xs:string?, $from as
>> xs:string, $to as xs:string) as element(result) {};
>>
>> I'd like this
>> d:get-data($from as xs:string, $to as xs:string) as element(result) {
>> http:get($config:url, $config:api_key, $config:secret, $from, $to) };
>>
>> where the authentication arguments would be retrieved from the
>> configuration file when necessary and added to the http get request
>> inside the function body.
>>
>>
>> so, would it be advisable to have this (where only application.xqy has
>> all information necessary, but minimal inclusion takes place)
>>
>> - application.xqy that includes
>>  - configuration.xqy
>>  - library1.xqy
>>  - library2.xqy
>>  - lowlevelfunctions.xqy
>>
>> or rather this (where each library module is independent as it
>> includes what's needed)
>>
>> - application.xqy that includes
>>  - library1.xqy which includes
>>    - configuration.xqy
>>    - lowlevelfunctions.xqy
>>  - library2.xqy which includes
>>    - configuration.xqy
>>    - lowlevelfunctions.xqy
>>
>> or still another scenario?
>>
>> sorry if that sounds confusing,
>> Jakob.
>> _______________________________________________
>> talk at x-query.com
>> http://x-query.com/mailman/listinfo/talk
>