Changes between Version 63 and Version 64 of FCS-Specification-ScrapBook

Timestamp:

02/18/14 08:44:05 (10 years ago)

Author:

oschonef

Comment:

--

FCS-Specification-ScrapBook

@@ -816 +816 @@
  * [[oschonef|Oliver (IDS)]]: True, but the old approach is overly complex. If the response is large (> 100MB), so be it. An efficient Endpoint implementation should do an streaming approach when serializing the response and the Client should not assume, that the response to this information will fit in, let's say,1MB of memory. If it's is hard for the endpoint to compile this list (e.g. it requires complex database queries), it's IMHO again, a matter of the endpoint to cache this information (in memory or disk) and just stream it into the explain response.
 * [[teckart|Thomas (ASV)]]: For endpoints that support many collections it can be a problem to force them to allow unrestricted queries regarding resource selection. In these cases every query would lead to a high load on the local search engine. Instead I would prefer to at least allow using a default collection if no restrictions are provided by the client.
-  * [[oschonef|Oliver (IDS)]]: This has already been the case with then old specification. That's more more in line with the ''searchRetrieve'' semantics of SRU. We should discuss this within the Taskforce.
+  * [[oschonef|Oliver (IDS)]]: This has already been the case with then old specification. That's more more in line with the ''searchRetrieve'' semantics of SRU. We should discuss this within the Taskforce.\\
+    How about the following solution: By default, Endpoint should query all resources, if no `x-clarin-fcs-context` parameter is supplied by the Client (like already in the spec). If that is for some reason ''not feasible/possible'' for an Endpoint, it MAY restrict the search to whatever scope it thinks it can handle ''and'' MUST issue a non-fatal diagnostics (uri tbd), like "collection set too large. query context automatically adjusted" (and include the PIDs of the collections comma seperated in the details field. Furthermore, we should introduce a fatal diagnostic "collection set too large. cannot perform query" (uri tdb)to be issued by the Endpoint, if it feels the Client requested too many collections with `x-clarin-fcs-context`. \\ I would like to avoid a situation, where an Endpoint needs special treatment (e.g. by unconditionally requireing `x-clarin-fcs-context`) to return any results. With the solution above, we could get at least some results and the Endpoint can indicate, that users need to "do more" to search broader.