[Ndn-interest] Repo vs aggregation queries

[Nick Briggs]

> On Jul 19, 2019, at 10:51 AM, Ernest McCracken via Ndn-interest <ndn-interest at lists.cs.ucla.edu> wrote:
> 
> 
> 
> 
> 
> From this discussion it almost seems like these repos should act as NDN adapters to existing storage and grid storage solutions providing a basic but extensible naming schema.  Of course developing that naming schema and mapping can be complex.  Lots of new storage solutions like redis.io <http://redis.io/> are making querying language simpler and are used in enterprise systems today.  Redis is used extensively by Discord for instance.
> 
> This describes an NDN frontend of a database, where the data schema is defined per application. I can certainly have a BLOB column that stores the original Data packets coming from the sensor, in addition to individual columns of temperature, humidity, etc, so that it can serve both original Data packets and aggregation queries.
> However, this would not be a repo, because a repo is supposedly general purpose and can store data from any application (as permitted by trust policy).
> 
> I agree with the notion that this would be a front end for a datastore and while redis (an inmemory data structure store) and noSQL db's require little to no schema they do require the application to conform to those structures. Is a requirement of repo to store application data in its original format?

In general, if a repository is going to serve the data it has stored it has to store the original wire-format packet because (most of) the packet is cryptographically signed and the repository has no access to the publisher's signing key(s).

>   
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20190719/b10567e0/attachment.html>