[metrics-bugs] #22476 [Metrics/metrics-lib]: Replace ImplementationNotAccessibleException with RuntimeException

[Tor Bug Tracker & Wiki]

#22476: Replace ImplementationNotAccessibleException with RuntimeException
---------------------------------+-----------------------------------
 Reporter:  karsten              |          Owner:  metrics-team
     Type:  enhancement          |         Status:  needs_review
 Priority:  Medium               |      Milestone:  metrics-lib 1.9.0
Component:  Metrics/metrics-lib  |        Version:
 Severity:  Normal               |     Resolution:
 Keywords:                       |  Actual Points:
Parent ID:                       |         Points:
 Reviewer:                       |        Sponsor:
---------------------------------+-----------------------------------
Changes (by karsten):

 * status:  new => needs_review
 * milestone:   => metrics-lib 1.9.0


Comment:

 Replying to [comment:2 karsten]:
 > Ah, I think I never considered that distinction between API and
 implementation important.  Realistically, we'll provide the only
 implementation of this API.
 >
 > (Maybe this also explains why you care about keeping the info log line
 `"Serving implementation {} for {}."` whereas I'd still prefer toning that
 down to a debug message.)
 >
 > Let's take this ticket out of the 1.8.0 milestone and discuss later
 whether we really need this abstraction layer or not.

 We briefly discussed this topic when wondering what to put in the
 announcement of 2.0.0 next week.  I'm adding here what I wrote there:

 > But let's also discuss whether we even want to make that distinction for
 others to write their own metrics-lib implementations.  (We have over a
 week to finalize this blog post, so we're not in a big rush.)
 >
 > The main reason for having separate packages for interfaces and
 implementation was that application developers should not even bother
 about implementation details, they should not even see them.  Basically,
 if they import an impl class in their code, they're doing it wrong.  Just
 like Java developers shouldn't depend on sun.* classes.
 >
 > But when I created those two packages, I never thought about developers
 implementing our interfaces and providing them as their own impl classes.
 That's certainly possible and I wouldn't want to make this unnecessarily
 difficult.  But is that also realistic, and is that something we want to
 sell as feature?  It's not like the Java Security API with a reference
 implementation.
 >
 > Going one step back and looking at the big Metrics picture, I see how
 we're providing quite a few interfaces: we're providing raw descriptors in
 CollecTor, we're providing a descriptor-parsing library with metrics-lib,
 we're providing aggregated CSV files, and we're providing the Onionoo API.
 Is that not enough?
 >
 > Again, I'm not trying to change anything.  I'm just a bit careful,
 because I wouldn't want to promise yet another interface, tied to the
 guarantee of not messing up this interface without sufficient prior
 notice.
 >
 > But maybe I'm just overcautious.  Curious to hear your thoughts!

 You agreed with these concerns and added two related aspects that I'm
 paraphrasing here: If we really want to provide an API, we'll also have to
 provide an API test framework, and we'll have to establish a process for
 accepting or rejecting implementations.

 So, I think we agree here.  Does that mean we should move forward with the
 suggestion above?  In theory, it's a trivial change that could still go
 into 1.9.0.  Adding to that milestone just so that we consider it.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22476#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online