[GitHub] [accumulo] ctubbsii commented on pull request #2639: Add debug page on Monitor

[GitBox <gi...@apache.org>]

ctubbsii commented on PR #2639:
URL: https://github.com/apache/accumulo/pull/2639#issuecomment-1104199829

   > Isn't everything on the Monitor subject to change from version to version?
   
   Yes, but we do try to keep the XML/JSON compatible and at a well-known location, because it can be used by automation.
   
   > > I'm not sure who this listing of endpoints is expected to help, because the site is already pretty intuitive to navigate.
   > 
   > Anyone? The one endpoint is broken and I don't even think anyone knew it was there. I added this to help with debugging.
   
   If it's only for debugging, then should this be off by default?
   
   The main concern I had here is "Implied reliability":
   
   Advertisements of information generally come with the implication that people can rely on the information in the advertisement. As an analogy, a flyer with a notice that an item is on sale at a store comes with the implication that a consumer can rely on getting the sale price when they visit the store to purchase the item. Similarly, a telephone/address directory listening comes with the implication that a person/business can be contacted at that telephone/address. -- This new page feels to me like it's a kind of advertisement of information, in that it seems to imply to me that those pages will exist and contain the expected information. Conversely, this implication does not seem present to me in the normal user experience of navigating menus on the site because our menus and other hyperlinks are more navigational, whereas this is more of an advertisement of information. In other words, with our current links, the information can be expected to be found only because the link is 
 clickable... not because the information's address has been published in a listening, as is the case with this new page.
   
   Secondarily, I'm also concerned about addition of new navigation on the site that doesn't substantially add information for users.  It's an extra link with extraneous information. Extraneous information, and extra paths to the same information, can increase confusion and decrease usability. To maximize user experience and minimize potential confusion, we need to balance between convenience and conciseness. Imagine having a button to take you to some piece of information. Now, imagine adding a second button "for convenience" that takes you to the same information. Perhaps this second button displays the information very slightly differently (FWIW, Vanguard.com's website does this right now, and it's very frustrating), or perhaps it takes you to the exact same information. In either case, it can be confusing to users. They may ask "what's the difference between these two?" or "do I need to visit both links to avoid missing out on important information?" or "these look the same, but 
 are they actually the same?". Even the most well-intentioned changes for convenience can make a site slightly more confusing overall, even if it is an improvement for the use case it was intended.
   
   > > I'd be concerned about users relying on these endpoints as fixed. They have the JSON/XML endpoints to rely on for information that the monitor knows... they should not rely on these endpoints for any kind of automation, permanent bookmarks, etc., since they are subject to change.
   > 
   > They are fixed. It isn't easy to change them without breaking the monitor. I would argue that we should treat the endpoints better so users can rely on them for stuff like that.
   
   They aren't fixed. We've already changed them a few times during 2.1's development. We renamed master to manager (granted that was a special case), we changed a numeric type from integer to long, we added external compaction stuff, we added an endpoint to append log events and renamed the one to clear logs, we separated the garbage collection information into a separate endpoint and removed the old endpoints, and possibly breaking formatting changes to several of the String-based values as well.
   
   While it's probably a good idea to have fixed endpoints at some point, it's difficult to do this when these need drive the monitor. They will need to change as our needs for the monitor change. Their primary task is to empower the views, not to provide automation to users. That's what the dedicated JSON/XML endpoints are for.
   
   These were also not designed to be consumed by end users. If they had been, I think we should have spent more time on deciding what these should look like... we probably wouldn't have 10 of 23 endpoints dedicated to separate `/rest/statistics/time` values, and then also had a `/rest/tservers/serverStats`, but then aggregated everything about the manager into a single `/rest/manager` endpoint. These are what you get when you are trying to solve an immediate problem of getting data to the page... they are not what you get when you design them for end-user automated consumption.
   
   I'm not opposed to having fixed rest endpoints at some point, well documented and ready for automated consumption by users... but I don't think what we have now are anywhere close to what those should look like. Maybe with a bit of design effort, they could be, but not right now.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org