Github user joshelser commented on the issue:
https://github.com/apache/accumulo/pull/242
> One of the design changes I made was to remove the footer (makes it for a
cleaner look on large tables) and move it to the "About" section. However, we
could add the Accumulo logo later on to the header (maybe even set a link to
the Accumulo website?).
I don't have a good suggestion here, just that my gut-reaction was that it
was very light on "apache accumulo". I think we should do more here, but I
don't have concrete suggestions at the moment. We should definitely make sure
it's clearly branded and something we're proud of.
> I believe the 13 calls happen only on the overview (since we are getting
all the information for the plots), but in other pages we also do multiple
calls (like in the master page).
Yes, I was talking about index (with the graphs).
> "default" != "accumulo". The "default" namespace is the one where created
tables get "assigned" to if the user didn't specify a namespace, the "accumulo"
namespace I believe is just for the Replication, Root, and Metadata tables
(could be mistaken?).
My point was that I selected "All", and I got an extra two filters (default
and accumulo). All should encompass everything -- it was confusing that I had
those extra filters which were meaningless (because I already said "give me all
the tables").
> I tried to write some Java documentation that would be useful for
generating the JavaDocs, but it might be good for someone with more knowledge
of Accumulo (and Java) to check that the wording is good for it.
Docs for the java objects is fine, but I meant REST API docs. As I
understand it, Swagger is pretty common
(https://jakubstas.com/spring-jersey-swagger-create-documentation/). Describes
what REST endpoints exist, what options they accept and the responses they
return.
For context: a big knock against the "old" monitor is that the XML/json
endpoints did not return all of the information that the Monitor had
available/used. Ensuring that endpoints for all of the data we're using to
render HTML was also available to administrators was a big design goal of this
approach. Thus, organizations how have custom monitoring/dashboards can scrape
these endpoints and integrate the data with whatever solution(s) they use.
> we should revisit the summaries in the future to clean them up (I didn't
change the wording from the original Monitor).
Agreed. This is a pretty clear-cut one that needs revisiting before release.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
