On 16/01/12 08:14, Paolo Castagna wrote:
Thanks Andy.
Andy Seaborne wrote:
1/ Service.java code could look in the Context for additional parameters
- but how might the code know which endpoints need which parameters?
(there may be several SERVICE calls to different places in one query -
don't want APi keys exposed to the wrong places!)
Indeed, parameters need to be kept and grouped by SERVICE endpoint.
We can use a Map<String, Map<String,List<String>>> to map SERVICE
endpoint URLs to a map of parameter-->values.
Service.java can then get the Map from the Context and add the
parameters to HttpQuery if there are any.
If we do just 1/, OpService probably needs to change (to keep the
parameters separate from the SERVICE endpoint URL).
2/ Just not checking for "?" doesn't quite work (need to know there is a
"?" allowed and swap to"&") but API keys probably shouldn't be in
SERVICE URIs. Is there any other query string parameters that might
reasonably and sensibly be in the service URI? If it's just keys, then
(1) looks better. Or both.
I can see how this could work and it can be general enough to leave all
the parameters specified by users in their SERVICE<...> call. It needs
to add query=... using either '?' or '&'.
The specific use case I've seen did not any other query string parameter,
however other SPARQL endpoints might have other additional (and/or
optional) parameters.
What might a general design look like?
We allow users to specify one or more query parameters when they use
SERVICE<...?name=value>.
Don't follow this part.
The use of the context is because the query and service IRI (and so the
algebra, which is just "the query") then don't need to know about
additional, potentially private, parameters.
Even if the params/value are passed in the query or URI, the only
difference in Params.httpString() as to whether the "first" flag is set
or unset initially?
Andy
We do 1/ keeping all SERVICE endpoint parameters separate from each others.
IIRC someone was looking to rework HttpQuery and see JENA-56.
Ack.
Time for a JIRA issue (i.e. improvement).
Paolo
Andy
