Project

General

Profile

Actions

Task #1862

closed

nfd-status-http-server: display face flags and expiration

Added by Alex Afanasyev almost 10 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Tools
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
1.50 h

Description

In XSLT stylesheet, in Faces section, display face flags and remaining time to expiration.

These fields should appear after FaceUris, and before counter fields.

Actions #1

Updated by Junxiao Shi almost 10 years ago

  • Subject changed from nfd-status-http-server: XSLT does not process/display face flags and expiration (for on-demand faces) to nfd-status-http-server: display face flags and expiration
  • Description updated (diff)
  • Assignee changed from Vince Lehman to Chengyu Fan
  • Start date deleted (08/14/2014)
  • Estimated time set to 1.50 h

I'm unsure whether "Expires In" field is useful right now.

On-demand UDP unicast faces have this field, but the value is on the order of 10 seconds, and Face Dataset is generated at most once per 5 seconds, so the displayed value is mostly inaccurate.

But it's good to have them, because they will become more useful after #1285.

UPDATE 2014-08-15 16:02 UTC: The default configuration file sets UDP idle timeout as 600 seconds, so "Expires In" is useful.

Actions #2

Updated by Junxiao Shi almost 10 years ago

  • Description updated (diff)

There is also a choice on how to display flags:

  • display the flags field as one hexadecimal number
    • benefit: less space on webpage
    • drawback: user must lookup code table in order to understand a flag
  • display the flags field as one decimal number
    • benefit: less space on webpage
    • drawback: user must convert decimal to binary, which is more difficult than converting hexadecimal to binary
    • drawback: user must lookup code table in order to understand a flag
  • display each flag by its name
    • benefit: it's easier to see what the flags mean without using a code table
    • drawback: more space on webpage
  • give each flag a column, and show the flag as "Y/N" "X/(empty)" or similar
    • benefit: it's easier to see what the flags mean without using a code table
    • benefit: if webpage is extended to support client-side sorting/filtering, the flag fields can be sorted/filtered
    • drawback: more space on webpage
    • note: the header cell doesn't have to display the full flag name; it can be an abbreviation, with the full name displayed on a tooltip

Currently, RIB Route flags are displayed using the second choice, which I think is a bad idea.

I prefer to display flag fields as the fourth method.

Actions #3

Updated by Chengyu Fan almost 10 years ago

I don't get the meaning of "Y/N" "X/(empty)"...

According to the FaceMgmt page, I only see two bits defined:

1: face is local

2: face is on demand - accepted incoming connection, instead of initiated outgoing connection

Seems not what you mean... Please give me a pointer to the flags description.

Actions #4

Updated by Alex Afanasyev almost 10 years ago

I don't think 4th option is useful. My vote would be to have combination of 2nd and 3rd approach: display flag by name and hex value. In addition to that, all "unrecognized" flags can be left out as just numbers (this is to allow any future/user-defined extension).

Actions #5

Updated by Junxiao Shi almost 10 years ago

Why would there be any unrecognized flag? Whenever a new flag is defined, both mgmt and tools must change.

Actions #6

Updated by Chengyu Fan almost 10 years ago

Just understand the forth option ...
For now I'll choose it as to show the flags. Then let's see if we need another option.

Actions #7

Updated by Chengyu Fan almost 10 years ago

  • Status changed from New to Code review
  • % Done changed from 0 to 100
Actions #8

Updated by Chengyu Fan almost 10 years ago

  • Status changed from Code review to Closed
Actions

Also available in: Atom PDF