[Nfd-dev] Clarification of 'repo' definition

Burke, Jeff jburke at remap.ucla.edu
Thu Sep 8 07:18:01 PDT 2016


Hi,

(Sorry for these messages all at once, and let me know if this should go to ndn-interest.)

Through an earlier conversation with Lixia this week, I realized that the definition / expectations of a ‘repo’ may be more specific than I previously understood.  In particular, she mentioned that repos storing and registering the same namespace should (eventually) have the same data for that namespace, presumably via sync.

A few related questions:

1) Is this attempt at eventual consistency of what’s stored for a given namespace a requirement to be called a ‘repo’?

2) Practically, if such sync is ultimately required behavior for a repo, will/should repo-ng itself incorporate some basic synchronization features?

3) Does opportunistic caching behavior (without sync) mean that the storage is not a ‘repo’?

4) Would, for example, network-attached storage that stores everything for a prefix but only up to a given depth in the tree not qualify as a repo?

5) Or, for example, in the BMS case, if I use a repo to store all of the electrical current samples for the UCLA campus, but not chilled water, it will have only have some of the tree for the campus bms prefix.  Is the storage not a repo?  Should it not be registering the root bms prefix?   Should I have / what do I call storage that is filling in part of the tree but don’t need to or can’t store all of it?

6) What are other requirements to be a ‘repo’?  (Alternatively, is there a canonical reference in the literature for the type of storage that constitutes a repo?)

Thanks for any clarification... Maybe I am reading too much into this?

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160908/b2c7eb16/attachment.html>


More information about the Nfd-dev mailing list