Re: [icnrg] icnrg Digest, Vol 101, Issue 8

[Ken Calvert <[e-mail]>]

Responding to a couple of points:

DaveO said:

> I’m still digesting this. Consider my comments more as questions, although all of you who know me also are aware of my predilection to couch questions as objections.
> 
> I also admit to not really understanding it completely after a couple of read-throughs. Some of this may be due to having to purge my translation cache of my usual understanding of some of the terms you have chosen. Feel free to respond, ponder for why the explanation isn’t getting through well to me, or just ignore.

I won't try to respond to your points (I'm already way behind), but I think maybe you and Christian are closer together than your reactions might indicate.
For example, I interpreted his "virtual blob" in exactly the way you suggest.

Marc said:

> FLIC describes a single file.  No.  By definition, FLIC must always describe two files: the manifest and the data.

I think you mean to say "FLIC specification must always describe two types" here, right?

> ...


> Inlining: Yes!  One use case we had for this was when someone wants to re-publish a manifest object (e.g. a content distributor wants to point its subscribers to local caches via locators), it would encapsulate the original root manifest in its re-written one so the consumer can verify in one step that they (a) got the thing they were asking for (from the interior manifest) and that someone they trust for such things (e.g. their ISP) tells them a good place to fetch it from.

Hmmm. This is different from my understanding of the "inlining" discussion.  As I said in my previous message, I interpreted it like what some filesystems do for inodes of small files: put application data directly in the inode/manifest structure.  I think the latter is a bad idea, for reasons I mentioned earlier.  OTOH, what you describe here, encapsulating metadata in other metadata, seems like just a normal thing you might do with a metadata-in-manifest facility.

Ken