I appreciate your point about method duplication/decentralization. In this particular case, though, (I think) I'm willing to tolerate it for two reasons:

1) I don't want to fragment the UDS API. I don't think what's going on with this "alt ID" would be enough to justify an all-new interface in a green-field system and many people (many == { James R, David H, me, others? }) seem to default to thinking that the UDS is where findUserByX() APIs live. Doesn't necessarily mean they're/I'm right, but I'd rather satisfy these people's implicit assumptions than worry about the maintenance cost to me or the impact to Jokers Who Implemented Their Own UDS.

2) Although there is not currently a finder method for displayId and there's actually only one XxxAdvisorUDP that I'm aware of, I think the patch's decision to separate the finder from the advice matches people's received understanding of how user APIs split up responsibilities, i.e. finders go on UDS, attribute accessors go on User, localizable attribute accessor overrides go on XxxAdvisorUDP mixins.

So it sounds like we're just down to a good old-fashioned difference of opinion.

I'm not entirely sure of the best path forward, and none of this addresses the ID contextualization issue being discussed in parallel. Perhaps James R will have some feedback that will de-fog things, or perhaps Paris will clear everything up. For now, though, I am not planning to hack on this patch in the immediate future unless new opinions/information emerge.

By the way, I don't consider myself the owner of the UDS API. (FWIW, I'd trust you with that responsibility more than I would myself.) I'm just trying to lay out a case for a more hands-off approach.

The confusion about authenticating a user was due to what looked like the same method being implemented by multiple services. I see no point in that – as far as I'm concerned it's an unfortunate bit of history. So now we have a user directory service "authenticate" and an authentication service "authenticate" and a user directory provider "authenticate", and Joe gets the pleasure of deciding which one needs to be called, customized, cached, etc., and we get the pleasure of maintaining them all.

You're basically adding two new methods: "getUserByUrlEmbeddableId" and "getUrlEmbeddableId(user)". And you can either have them show up in one service or you can have them show up in two services.... I figure you can see where I'm going here.

Ray,

I completely understand where you're coming from, and your point about the lack of shared data concerns between the UDS and these new methods is a good one. However.... I remember another recent discussion in which it seemed that there had been confusion about which interface a client should invoke when authenticating a user. In that case the wrong (but perfectly reasonable) choice had been made, leading to much cache-related teeth gnashing. The decision that decoupled authN services into two separate interfaces was a valid one, I think: coordinating and executing authN are discrete concerns. But, b/c the distinction is subtle, it left the door open to reasonable mistakes. I think a new interface for "alternate ID" retrieval/finders creates a similar opportunity for mistakes or at least head-scratching. If I have UserDirectoryService and User interfaces, which seem to know all about user attributes, and which expose displayId properties which look an awful lot like what I, Joe Tool Developer, am interested in processing, why do I need to remember that for this one special case of "lookupable alternate displayable IDs" I need to go look for another interface altogether? Joe will probably eventually figure out that he's not actually interested in displayIds and there's this other way over here to find users by non-eid tokens, but it's my guess that Joe would appreciate having all his user finder methods in one "place" such that he has at least somewhat greater chance of figuring out that "displayId" might not be exactly what he thinks he needs.

All of this is a round-about way of saying that I prefer the aesthetics of a consolidated API who's business it is to find users, particularly if it can be done in a way that isn't actually disruptive to deployed customizations, which I believe to be limited to UDPs.

I am not immovable on this point though, and my sense is that I am in the minority in general. So, Ray, if you tell me that extending the UDS API is simply not acceptable, fine. I will alter the patch.

If I'm reading the patch correctly, it looks as though the UserDirectoryService portions actually don't rely on any data that's private to the UserDirectoryService code. If you're game, I think this could let you avoid any changes to existing interfaces:

1. Rather than hiding UrlEmbeddableIdAdvisorUDP inside UDS, expose it as a service with an overrideable default implementation. Inject the UDS into it to do user lookup.
2. Have the couple of clients that need the new capability use the new service rather than the UDS.