RoadMap » History » Version 4
Anonymous, 05/27/2015 11:07 AM
1 | 1 | Anonymous | Road Map |
---|---|---|---|
2 | ======== |
||
3 | |||
4 | Current Catalog Status |
||
5 | ----------------------- |
||
6 | |||
7 | - We have an initial catalog implementation that supports menu (component type) and auto-complete NDN name queries against a MySQL database. |
||
8 | 3 | Anonymous | - Chengyu will implement name synchronization with chronosync. |
9 | - Susmit will implement the data provider's publishing module. |
||
10 | 4 | Anonymous | - All available CMIP5 names have been published into their respective databases. |
11 | 1 | Anonymous | |
12 | Catalog Milestone Summary |
||
13 | -------------------------- |
||
14 | |||
15 | The catalog implementation should be prioritize to present increasingly interesting concepts. We've started off simple: we can query a single catalog without specifying any particular host. This starting point can be evolved to demonstrate synchronization, data publication/retrieval, and security. |
||
16 | |||
17 | Security is currently a low priority milestone because we can demonstrate synchronization and data movement without it. Provenance is an important topic for scientists, but adds little on its own in terms of demo value (i.e. something is accepted or rejected). In the meantime, we can use an "anything goes" security policy. |
||
18 | |||
19 | 2 | Anonymous | We also need to fit query protocol improvements (e.g. union support) into the current milestones to improve user interactions with the catalog. However, the current focus is completing the initial catalog design (query, sync, and publication). |
20 | |||
21 | Similarly, the database schema, and the corresponding catalog SQL query functionality, may also need to be changed to avoid any scalability problems from using regex searches for autocomplete queries. However, the current schema seems to be good enough for now. There may be a more immediate problem from signing and verifying query results. In particular, queries asking for all cmip5 names will produce hundreds of packets. The NDN Javascript library will only be able to verify between 300 - 1,000 signatures/second, depending on the signing algorithm, once verification is enabled. |
||
22 | |||
23 | 1 | Anonymous | Catalog Milestones by Priority |
24 | ------------------------------- |
||
25 | |||
26 | 1. Synchronize catalogs using ChronoSync |
||
27 | |||
28 | - Our last demo focused on querying and displaying results from a single catalog. |
||
29 | - Allows us to start talking about catalogs as a system with a consistent view rather than independent hosts/databases. |
||
30 | - Next demo could demonstrate NDN names being inserted from any catalog and the catalog system synchronizing. |
||
31 | |||
32 | 2. Add dataset publication |
||
33 | |||
34 | 2 | Anonymous | 3. Use manifests to improve dataset retrieval performance |
35 | - Manifests are needed to avoid performing expensive public key signature verification. |
||
36 | - Publishers will still need to use public key signatures on their data, unless we can justify moving to SHA256 digest "signatures". |
||
37 | |||
38 | 1 | Anonymous | 3. Validate data publication and synchronization messages |
39 | 2 | Anonymous | - Need to document trust model(s) and verification strategy for data publication. |
40 | 1 | Anonymous | |
41 | 4. Serve datasets directly from disk with a new NDN repo |