[Nfd-dev] do we need "application store"?

[Jiewen Tan]

Hi Alex and Yingdi,

 

I do agree with Alex that it might be more useful to make the save/load
interfaces as virtual interfaces to provide more flexibility to the app
developers. Yet I think it would be necessary to provide such interfaces, as
some apps might need to save states when they exit and resume when they
start. Although app developers can surely inherit the base in-memory storage
class and do whatever they want in the derived one, it would be good to
provide a base helper for lazy app developers and demonstrate an example to
do serialization.

 

Regards,

Jiewen Tan

 

From: Alexander Afanasyev [mailto:cawka1 at gmail.com] On Behalf Of Alex
Afanasyev
Sent: Monday, September 15, 2014 10:53 AM
To: nfd-dev
Cc: Yingdi Yu; Steve DiBenedetto; Lixia Zhang; Beichuan Zhang; Junxiao Shi;
Jiewen Tan
Subject: Re: do we need "application store"?

 

Hi Yingdi,

 

I like the design.  I would only suggest a couple of quick changes:

 

- there is too much description about freshness.  I think it would be enough
to say that a primary objective of freshness is to guard producer from
receiving too many interests.

 

- I would avoid putting PIB service as a first example.  Start with the
existing and relatively known apps (chat/sync/nlsr).  For PIB service, I
wouldn't talk about "system default key", rather "current certificate for
the key"  and optionally "current key for the identity".

 

- for the design goal, you should start with emphasizing that "common
pattern" is to keep produced data packet for a while, so it can be served
later.  You already have all the description, I would just start with the
"common pattern" statement and then go into more details.

 

- "... packets  are not backed up ..."  this thing is commonly called
serialization.  Either "storage" is serialized on disk or each data packet
in the storage is serialized on disk.

 

- don't add save/load to the interface.  This is completely unrelated to
storage and, as you mentioned before, there could be tons of different ways
to do it.  If you simply provide `begin() const', `end() const' methods, I
thing it would be enough to implement any kind of serialization.  We can
make a serialization helper, but it is still outside the scope of
InMemoryStorage class.

 

- Can you add a diagram/description on how applications would use this
storage?  I mean, description on how storage is connected within the
application:  app registers prefix, sets interest filter, receives interest,
calls in memory storage, etc.

 

---

Alex

 

On Sep 13, 2014, at 10:57 PM, Yingdi Yu <yingdi at cs.ucla.edu> wrote:





Hi all,

 

I have updated the design document of InMemoryStorage:
http://redmine.named-data.net/projects/ndn-cxx/wiki/InMemoryStorage. I would
like to get feedback from you, so that we can nail down the design details,
and Jiewen Tan can keep working on it. Thanks!

 

Yingdi

 





 

On Sep 10, 2014, at 11:17 AM, Yingdi Yu <yingdi at cs.ucla.edu> wrote:





On Sep 10, 2014, at 9:47 AM, Steve DiBenedetto <dibenede at cs.colostate.edu>
wrote:





As for using the CS for an application's data storage: I want understand the
role of the CS in the special, but common, case of end hosts/local
nodes/whatever-you-want to-call-them where we have vastly more storage
capabilities, both memory and disk, than a router. Is the CS still just the
store-and-forwarder buffer or is it something else?

 

Yes, I also hope we can clarify the role of CS.





I'm trying to view the end host CS as master storage controller (probably a
bad term) that conceptually holds everything on the system and presents a
API for interacting with named data.

 

In this case, why not just run a repo on the system. It can provide more
persistent storage than CS.





In other words, something that evolves from just our "store-and-forward
buffer with named data" mentioned in the original paper towards NDNFS'
idea(s) (unfortunately not familiar with the details). 

 

I am not sure about NDNFS, maybe repo is a better one to describe your idea?





Then, all data storage is using shared resources between the forwarder and
applications. 

 

This is the thing I did not get through the whole discussion: what is the
benefit of sharing resources?





That said, is the InMemoryStorage proposal just a temporary solution or are
we also making a statement about what we anticipate non-duplicating data
storage on end hosts to look like?

 

I would not take InMemoryStorage as a temporary solution. It represents one
of the data management models, that is, apps should take care of their data,
rather than relying on forwarder. I am not saying this is only model,
therefore apps can make their own choice whether to adopt this model or not.
This is also why I always take the in-app storage as a helper class in the
library.





I took Lixia's initial prompt to be a discussion of the latter, but it's
very possible that I'm dragging the discussion to somewhere it was never
intended to go.

 

I was hoping to discuss the design a new/alternative CS residing within NFD
that communicates with applications through a library API (hopefully similar
to InMemoryStorage). The idea being to provide unified named data storage
across the NDN app ecosystem that emulates some of the OS' storage
functionality. This would obviously be *a lot* of work, but it makes a
statement of "how things should be".

 

One thing I do not agree with Lixia's argument is that this is not about
resources, this is also about management. If there is enough resources, it
does not matter where the data is stored. If there is not enough resources,
neither putting data in CS nor in app cannot help. 

 

However, no matter where the data is stored, the holder should manage the
data. The cost of managing apps' data in CS is much higher than asking apps
to do it by themselves.

 

Yingdi

 

 

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