solid
globbing need to be follow your nose
Currently the globbing feature is not advertised. A client cannot know that a server supports it. There should either be a Link header of type ldp:globed or the LDPC should have that link following the patterns set by the LDP spec.
Agreed. I probably wouldn't call it "glob" though. Outside a very small niche, it's called a wildcard, right? And is it (or should it be) a wildcard like http://foo.example/a*/b*/cd/e ? or is it only to be used like http://foo.example/a/b/c/ ? If that's all it is, it should be called container inlining.
More questions I have:
- What is the return format of this feature? I imagine it would be something like tar.gz, but I can imagine some would argue for a multi-part mime type.
- Do the tarred resource include the acls? ( ie the http headers that point to the acls for example or specify an LDPR as LDPR, returned in the tared file ) Come to think of it, the multi-part format makes that easier.
- Should the rdf resources contain relative urls or absolute ones? Is that settable? ( I suppose multi-part would settle that )
- Is there such a feature available in HTTP2, or something one could use to improve the feature set.
Globbing is just a pattern matching feature of Unix-like systems. It does not return a tar.gz file, or any type of archive. I've added a couple of examples to show how globbing works in SoLiD. I hope this clears the confusion.
While there is currently no "follow your nose" mechanism to advertise globbing support, I hope that the proposed server preferences feature of LDP Next will fix this issue.
@deiu , you can't just close an issue without asking the person who opened it if they agree with your answer. Currently your answer suffers from the following problems:
- It does not address the problem of how a client can know that he can use globbing on the particular server
- You are returning a merge of all the graphs, which is not at all satisfactory as:
- it assumes that all the graphs are coherent. I can easily imagine putting on a server graphs that are incompatbile
- It does not tell one how to deal with image resources.
Can you please re-open the issue.
Globbing only applies to RDF resources (now properly reflected in the spec text).
Why is that restriction a reasonable one? It would help if you started out with use cases for globbing. Furthermore the merging of all content requires the graphs to be returned to all be coherent, which I think is much to strong a requirement, meaning it will rarely be satisfiable, and rarely in an automatic way. Ie. What you'd have to specify is the requirements on consistency that you assume before you can specify it.
That is why I suggested multipart results.
@sandhawke it is actually called glob: https://en.wikipedia.org/wiki/Glob_(programming)
@sandhawke Container inlining is a nice name.
I use ldpc/* a lot and is a huge optimization for apps. It's something I cant imagine living without.
The other types of wild cards I dont use and cant imagine using.
There's also the issue of escaping * in a URI ... tho I wonder was it a reserved character already?
I'd suggest using it just on ldpc/* right now. Implementation experience is going to be a good guide here too, imho.
@bblfish multipart results is a reasonable improvement over the current way of doing globbing. I'll try to implement it to see how well (easy) it is to work with.
@deiu unix shells do a particular kind of wildcarding called globbing. This is not that kind of wildcarding, in either syntax (no support for ?? or {} or [] etc) or in semantics (globbing simply replaces the pattern string with its expansion list, so it only makes sense in contexts which support multiple arguments). I suppose to people who've only used unix, this isn't an important distinction.