<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br><br></div><div><br></div><div><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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 <a href="http://redis.io" target="_blank">redis.io</a> are making querying language simpler and are used in enterprise systems today.  Redis is used extensively by Discord for instance.</div></blockquote></div></div><div><br></div><div>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.</div><div>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).</div><div><br></div><div>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?  </div></div></div>
</blockquote></div></div>