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

[Alex Afanasyev]

I did not say virtual class or method.  These methods don't belong to the InMemoryStorage.   What I meant is that this function is completely outside the scope of InMemoryStorage.  There should be separate serialization hierarchy (there is boost serialization library, though I haven't used it at all).

---
Alex

On Sep 15, 2014, at 9:39 PM, Jiewen Tan <alanwake at ucla.edu> wrote:

> 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/1b7fb43b/attachment.html>