`ResourceService::getIdentifierSupplier` vs. `IdentifierService` about trellis HOT 5 CLOSED

This is a good question. It is also a part of the ResourceService interface that I am least happy with. If you have a suggestion for improving this, I will be quite interested.

For some context: the HTTP layer needs a mechanism for generating identifiers both for resources (e.g. POST w/o a Slug header) and for the internal identifiers for Binaries (LDP-NR). The public-facing resource identifiers may very well be structured differently than the internal binary identifiers. (For example, a file-based binary service might need to add intermediate path hierarchies in order to get around limitations of a POSIX filesystem). So, I wanted both the ResourceService and the BinaryService each to be able to "configure" a single IdentifierService object, which is why both ResourceService and BinaryService have this sort of getIdentifierSupplier method.

I can think of at least two (possibly better) approaches -- you may have some other ideas:

1. Change the method name to generateIdentifier in both interfaces, each just returning a String rather than a full Supplier<String>. This seems straight-forward and pretty easy. It also allows a particular Binary|ResourceService to specialize the identifier generation as needed (since those layers should know how those identifiers ought to be structured).

2. Remove this method entirely from both, and instead isolate the identifier generation entirely in the HTTP layer. This might involve creating specializations of the IdentifierService interface (e.g. BinaryIdentifierService), but it may also make it possible to use simple ServiceLoader injection of these implementations.

The current design is definitely an example of expediency over clear design, and I would be very interested to think about different ways to structure this.

from trellis.

I think we may have a confusion between two different functions: supplying identifiers, and supplying different types of identifiers. That's how I translate:

the HTTP layer needs a mechanism for generating identifiers both for resources (e.g. POST w/o a Slug header) and for the internal identifiers for Binaries (LDP-NR)…

So I would suggest a type-based solution (to add to the list you already have!): a single identifier service for the whole architecture that looks something like:

IdentifierService extends Supplier<String>, Function<IRI,String> {}

and one uses ::get when one doesn't care about whatever translation semantics might apply and one uses .apply(type) to get an identifier that is meet and fit for a certain type of resource, e.g. binaries.

Or, if you want to disconnect supply from service, something like:

IdentifierService {

    Supplier<String> getIdentifierSupplier();

    Supplier<String> getIdentifierSupplier(IRI type);
}

which is also less concise and easier to read and understand. Do you see what I mean about separating (a little bit) "generating" and "generating different types"? As long as the HTTP layer addresses only the interface, all is well. Then the integrator (who knows all about the different needs of different component impls) selects an appropriate IdentifierService impl when she wires everything up into a deployable(s).

from trellis.

A type-based solution would be excellent. The suggestion to use:

IdentifierService extends Supplier<String>, Function<IRI,String> {}

seems very promising.

from trellis.

Well, that would be very concise. Honestly, though, I wonder if it is too concise...

from trellis.

I'd like to experiment with this (and your other suggestion) a bit. If one of them seems to fit well with the needs of the HTTP layer, then the choice should be pretty clear.

from trellis.