
Andre Merzky wrote:
Hi all,
Cerial came upon an ugly problem with the current spec: the wildcards used in the namespace package collide with the introduction of URLs, as several characters used for wildcards lead to not-well formed URLs. That problem was not present back then when we used strings instead of the saga::url class.
Below is an email exchange describing the problem with examples. Opinions on how to solve that _nicely_ are very welcome.
One "solution" is to explicitly add methods where you are allowed to use wildcards, for instance in namespace.ns_directory: copy (in string source, in saga::url target, in int flags = None); This, in addition to the methods that are already there (and which then don't allow for wildcard expansion anymore). These methods could throw NotImplemented when wildcards are not supported. An advantage of this approach is that it is made explicit where wildcard expansion is to be expected. This is left in the dark now. Problem is that the characters used in wildcards are now part of the "path" part of the source "url", which a.o. means that query parts are not possible here, and implementations will have to provide their own url decoder. Or, the source could be specified as being only a "path" part, which is to be resolved with respect to the directory on which the method operates. This was a problem with the earlier saga specs as well. How does the current C++ implementation deal with this? (This one is based on the earlier saga specs, is it not?). Another disadvantage is that this adds bulk: four extra methods (copy, link, move, remove) plus their async versions. I don't think it makes sense to allow wildcards in the other methods (except maybe the permissions methods). Another approach would be to have an explicit method to do wildcard expansion. For instance, in namespace.ns_directory: expand (in string pattern, out array<saga::url> urls); Here, the pattern only specifies the "path" part, but with wildcards (the directory implicitly specifies the rest of the url). I am not sure whether the resulting urls should be resolved with respect to the directory or not. I think not. Anyway, just a couple of thoughts. Ceriel