JENA-979: add a fuseki admin service to list all existing backups

[yyz1989]

No description provided.

[rvesse]

+1 to the idea

The implementation seems to violate REST principles though

POST should be used for changing data so should not be supported for a service that only provides information

HEAD should be used only to determine what the resource supports so should not return a body and should only return information about supported methods and content-types

[afs]

I disagree a bit about POST - yes, it's not nice REST but it is pragmatically useful to ensure up-to-date information (the client can force it even if the server or proxies decide to cache).

HEAD - completely agree. I think the body may be chopped anyway but I'd need to check.

[afs]

/documentation/fuseki2/fuseki-server-protocol.html will need updating but it is quite a small change.

[ajs6f]

Given Java 8, this is a little briefer as fileNames.forEach(builder::value).

[yyz1989]

I think we are based on Java 7, no?

[ajs6f]

No, I believe we are now officially at Java 8 for the main line of development. We use Java 8-only idioms elsewhere. In any case, it's nothing to worry about. I just have a vicious yen for brevity. :)

[ajs6f]

POST is one way to enable a "force up-to-date`, but it should also be possible to supply an ETag, which is a little more to the exact need. Perhaps Fuseki has helpers for this?

[afs]

Indeed - etags are one example of a server driven mechanism. They need more machinery than this PR has though. HTTP headers are not always easy to deal with in client libraries, either access or setting the conditional GET headers. (And not all developers are aware of or are interested in details (burden) of all HTTP features.)

POST is the easy way for a client to force a live view. I think we should leave it in because it is near zero cost. Fuseki has the same elsewhere.

[ajs6f]

Okay-- do you think it's worth a separate ticket and PR for some helpers for ETags, so that future new Fuseki HTTP functions could offer them at low cost? I don't mean block this PR, I mean a totally separate ticket.

[afs]

Here, the client browser is an admin interface.The read-information operations are not a performance pain-point.

Helpers presume how they are being used in Fuseki is defined and it's not. Each use may be quite different. It's not just how to use E-Tags but deciding what they represent so look at in context.

e.g. JENA-626 (query caching) is a case where they would be useful. And how would even Jena's own client library deal with them.

[ajs6f]

I meant something as simple as a method that accepts an identifier and response and adds the correctly-formatted tag.

[afs]

We are agreed that it's not related to this PR. Let's discuss it on dev@ and not tangle this PR with that discussion.

[ajs6f]

Okay, sorry to cloud the waters.

[yyz1989]

Yeah, I agree with Rob and Andy. I do think accepting POST is necessary, but I apologize for my negligence for HEAD. That is due to my laziness because I took the main structure from another service directly :D

[afs]

WIP: I'm incorporating this by integrating into the admin action framework (i.e. extends ActionCtl)

Currently:

• The URL is /$/backup-list Camel-case is less common for URL API naming (YMMV).
• Returns the file names, not the full path names. The server does not reveal its absolute path setup.
• Returns non-hidden files : Filters on !file.isHidden() && file.isFile()
• Response is Content-Type: application/json