Project

General

Profile

Actions

Task #1862

closed

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

Added by Alex Afanasyev over 9 years ago. Updated over 9 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 over 9 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 over 9 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 over 9 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 over 9 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 over 9 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 over 9 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 over 9 years ago

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

Updated by Chengyu Fan over 9 years ago

  • Status changed from Code review to Closed
Actions

Also available in: Atom PDF