<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle18
{mso-style-type:personal;
font-family:Calibri;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:Calibri;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">The CCNx 0.x repo sync protocol allowed a wildcard filter in the definition of a ‘slice’. I’ve copied the old relevant docs below.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">One could create multiple slices with different filters and those would create different views on the same underlying data. I don’t remember what actually got implemented along these lines,
but I think of it along the lines of a SQL view (a virtual table). The repo only needs to store an object once and can index its name in different slices as their filters dictate.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">I believe one shortcoming of this was in a multi-hop sync, one would only see the data traverse the sync that fits the intersection of the slice filters. We had done some other design
work to allow for the transitive propagation of slice filters (where allowed) so one could ‘tunnel’ that data without it showing up in the repos without those filters. Kind of like a slice filter subscription.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Marc<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><a href="https://github.com/ProjectCCNx/ccnx/blob/master/doc/technical/CreateCollectionProtocol.txt">https://github.com/ProjectCCNx/ccnx/blob/master/doc/technical/CreateCollectionProtocol.txt</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">==== Name<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">The *+Name+* in a filter clause is a name prefix that restricts the names in the Collection, and may contain wild card components.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">* Each wild card component in a filter clause name matches a single component in a name.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">* The encoding of a wild card component is the single byte 255 (+0xFF+). To enable byte 255 to start a literal component, any pattern component that starts with byte 255 and has more than
1 byte is treated as the literal component consisting of the bytes following the initial byte.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">* A name matches a filter if it matches any of the filter clauses. (All components are required.) Components of a name longer than the name in the filter clause are accepted as matching.
For example, using CCN URI syntax, +/X/%FF/Z+ matches the names +/X/Y/Z+ and +/X/Y/Z/W+, but does not match the name +/X/Z+.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-family:Calibri;color:black">From: </span>
</b><span style="font-family:Calibri;color:black">Nfd-dev <nfd-dev-bounces@lists.cs.ucla.edu> on behalf of "Burke, Jeff" <jburke@remap.UCLA.EDU><br>
<b>Date: </b>Saturday, September 10, 2016 at 9:36 PM<br>
<b>To: </b>"Zhang, Lixia" <lixia@CS.UCLA.EDU><br>
<b>Cc: </b>"nfd-dev@lists.cs.ucla.edu" <nfd-dev@lists.cs.ucla.edu><br>
<b>Subject: </b>Re: [Nfd-dev] Clarification of 'repo' definition<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">I think I figured out how to put this in a more straightforward way:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">It <i>seems
</i>to me that is may be common (or at least reasonable) that apps will be configured and deployed such that it is desirable that repos store data for name patterns that do not correspond to “all data in a given branch”.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">i.e., it might be desirable to have a repo for
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> /ucla/bms/*/electrical/*</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">but we seem pushed towards naming such that the repo must be for </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> /ucla/bms/electrical/*</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">What are the implications of this? </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">A use case seems to be precisely the mini-bms hierarchical aggregator example implemented this year, except split by subsystem – i.e., a vertical solution vendor (Siemens for electrical,
say) provides gathering and storage for one complete data type, another vendor supports another data type (Honeywell for HVAC, for example). Leveraging NDN they can all contribute to
<i>the same coherent namespace of BMS data</i> and participate in aggregation across data types, but in practice, different data types are published/stored by different vendors’ systems that cover different portions of the tree... It’s not realistic here
to either 1) require one vendors’ repo store anothers data, in such a system; 2) have manufacturer-specific names when it is not relevant.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">I understand this may all seem basic – one just needs to organize the data such that Interests can get directed to the right place. But, I think the subtlety here in this use case, and
probably in others, is that the topology of the nodes providing the ‘live’ data may not match that of the repos. So these may place competing requirements on the namespace design. (There’s more to it than that – also security requirements further drive namespace
considerations, etc)</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Also, one thing that I mean by “brittleness” is that the “repos must store the complete branch they register” requirement seems to require a lot of advance knowledge of the namespace, such
that namespace/repo design can be coordinated in this way. I’m doubt this is realistic.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">For example, what if in the BMS case, the app developers/deployers figure out a scheme that organizes repos by rooms – so each room has a repo that stores
<i>all data </i>for the room (or set of rooms) it registers - supporting</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> /ucla/bms/melnitz/room=1403/electrical</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> /ucla/bms/melnitz/room=2910/hvac, etc.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">So there is a ‘room=2910’ repo and/or a melnitz repo, and a campus bms repo, etc.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">What if then, the system operators acquire a
<i>new, </i>high bandwidth sensor type and install it in all the rooms a year later:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> /ucla/bms/melnitz/room=2910/hd-equipment-room-camera</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">For administrative reasons, I want this under the /ucla/bms hierarchy, as is simplifies the trust management.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">And I can afford to put one new box in each building to act as a repo for the data.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">I’m not sure what to do about this:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">1) Sure, maybe I misconfigured the namespace, but it wasn’t unreasonable when I deployed originally, and it’s hard to change now.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">2) Maybe I really should put the cameras under some other namespace, but that has other implications for configuring trust management and/or interaction with other subsystems in the room</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">3) I can update all of the repos to register all their available child prefixes, perhaps... (so I touch all application configuration?)</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">4) I can customize the forwarding somehow to get the camera interests to the appropriate place</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">I *<b>think</b>* what I’d like to be able to do in deployment is to be able to start up the new build-level camera repos and have them register their prefixes, using commands signed appropriately,
and just <i>work</i>. (I think it is not so far off to achieve this, if strategy does LPM to forward.
<i>But unless I am missing something, it does require the pre-existing repos, which don’t have the resources or desire to hold the new data, don’t have to</i>.)
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Perhaps we tend to think about namespace design as if it can always be done in advance, but it seems like it will grow more messily, and that resources will be added deep in a given namespace
sometimes, and it would be nice if that “adding storage” to a namespace can be done without causing cascading responsibilities to be placed on repos already ‘covering’ the affected branches. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Jeff</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-family:Calibri;color:black">From: </span>
</b><span style="font-family:Calibri;color:black">Lixia Zhang <lixia@cs.ucla.edu><br>
<b>Date: </b>Saturday, September 10, 2016 at 8:46 PM<br>
<b>To: </b>Jeff Burke <jburke@remap.ucla.edu><br>
<b>Cc: </b>"nfd-dev@lists.cs.ucla.edu" <nfd-dev@lists.cs.ucla.edu><br>
<b>Subject: </b>Re: [Nfd-dev] Clarification of 'repo' definition</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Sep 10, 2016, at 2:57 PM, Burke, Jeff <<a href="mailto:jburke@remap.ucla.edu">jburke@remap.ucla.edu</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="background:white">On Sep 8, 2016, at 7:18 AM, Burke, Jeff <<a href="mailto:jburke@remap.ucla.edu"><span style="color:purple">jburke@remap.ucla.edu</span></a>> wrote:<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:Calibri">Hi,</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:Calibri">(Sorry for these messages all at once, and let me know if this should go to ndn-interest.)</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:Calibri">Through an earlier conversation with Lixia this week, I realized that the definition / expectations of a ‘repo’ may be more specific than I previously understood.
In particular, she mentioned that repos storing and registering the same namespace should (eventually) have the same data for that namespace, presumably via sync.</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white">I'll start by saying that this is all researchy: we are walking into a new territory that we are yet to fully explore.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white">So what I said, before or here, is just to share ideas with others.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b> </b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b>[jb] Yes, of course. :)<span class="apple-converted-space"> </span></b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white"><br>
<br>
<br>
<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white">It is easy to see why a desire of all repos for the same name prefix being sync'ed up: an interest for that prefix may be forwarded to any of the repos, if all repos have the same data, anyone can answer it; otherwise
routers have to handle NACKs and reroute the interest to try other repos.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b>[jb] Right, but this is a forwarding-centric view. If I am an app that has some (sparse) knowledge of a namespace, perhaps I just want to make it available to the network, without having to worry about forwarding?
I thought we are not supposed to have to think about forwarding! (At least this is what I get told when I ask about publisher mobility... What about a mobile repo? :) </b><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal">a publisher mobility is a different story than a partial repo.<br>
<br>
<br>
<o:p></o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div>
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:Calibri">A few related questions:</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:Calibri"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:Calibri">1) Is this attempt at eventual consistency of what’s stored for a given namespace a requirement to be called a ‘repo’? </span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="background:white">see the above explanation.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="background:white">I wont call it a requirement, but desirable for performance concerns.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:Calibri"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b>[jb] As I alluded to above, I am having trouble reconciling this with the “share what you know” approach of sync-based communication. If I am a repo storing the thousand most popular netflix titles for the local
geographic region (<i>persistently, for a month, let’s say</i>), do I register a thousand prefixes, or do I need a namespace for popular content (hope not), or knowledge of other names to NACK the content I don’t have? I’m just not sure of the implications
of what it means to know about all content for a prefix you are, as a repo, publishing... So I am wondering still if I’m missing a connotation of exactly what a repo is vs. some other publisher.</b><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal">Jeff, how about we look at *each* of different cases, one at a time, to understand its design tradeoffs.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">If we believe this is the beginning of research on repo usage: we are yet to find general solutions.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:Calibri"> </span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div>
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:Calibri">2) Practically, if such sync is ultimately required behavior for a repo, will/should repo-ng itself incorporate some basic synchronization features? </span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="background:white">as I mentioned, there was a piece of work done on repo sync 2 years back (but I dont know its implementation status)<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:Calibri;background:white"> </span><br>
<b>[jb] Yes, I remember this somewhat too. But it seems that 1) persistent storage is fundamental to apps; 2) interaction with storage happens near/right above the network layer in the case of repo; and 3) there are some performance and conceptual concerns
with providing consistency between nodes providing storage in the same namespace, so this should be important to support? (Or, at least to we need to inform users of the existing repo-ng the probably trajectory of development that is expected but not happening
yet, in the repo documentation on the wiki? I think this type of getting our implicit plans out there is important to supporting community effort.)</b><o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal">1/ I agree with everything said above.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2/ One should not read nothing more from repo-ng than a best-effort trial piece of code.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">3/ Yes we all know we need documentation. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Sadly there is a simple issue of manpower shortage.<o:p></o:p></p>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div>
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:Calibri">3) Does opportunistic caching behavior (without sync) mean that the storage is not a ‘repo’?</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="background:white">My own view: no.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white">my explanation to others:<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white">- caching: opportunistic <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white">- (managed) repo: managed storage<br>
<br>
<br>
<br>
<o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:Calibri"> </span><b>[jb] Ok. (I will go back to the chilled water example, though... what about a publisher that naturally only has knowledge of part of a tree..? Is that
not really a repo if it’s knowledge isn’t complete for the branch it stores? What about if it doesn’t store depth all the way down)</b><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal">When one only has knowledge of a tree, one can/should only announce that specific branch of the tree.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:Calibri">4) Would, for example, network-attached storage that stores everything for a prefix but only up to a given depth in the tree not qualify as a repo? </span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="background:white">everything is attached to the network :)<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white">so I am not sure what "network-attached storage" really means.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:Calibri"> </span><b>[jb] Sorry, the adjective probably wasn’t that relevant. :)</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="background:white">if your question is "what if a managed repo for a name prefix only contains incomplete data under that prefix" -- that still works, and *may* even work OK if one understands the traffic
patterns so that most of the Interests forwarded to that repo can be satisfied, without having to zigzagging to other places seeking for data.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:Calibri"> </span><b>[jb] Not sure I understand who the “one” is and how they control Interest forwarding? </b><o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal">One in "if one understands the traffic patterns" means the app developer.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I do not mean that he controls interest forwarding, but just saying if he has a good understanding on app behavior. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"><b>I’m trying to think in terms of scenarios where app developers don’t really have the ability to manage network forwarding any more than they do today. (Yes, of course, some people deploying large apps control
their network infrastructure to that level of detail but many don’t.)</b><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white"><br>
<br>
<br>
<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:Calibri">5) Or, for example, in the BMS case, if I use a repo to store all of the electrical current samples for the UCLA campus, but not chilled water, it will have only
have some of the tree for the campus bms prefix. Is the storage not a repo? Should it not be registering the root bms prefix? Should I have / what do I call storage that is filling in part of the tree but don’t need to or can’t store all of it? </span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white">1/ if chilled water has its own prefix announcement, maybe one can find a way to attract all interests for chilled water data to the place for chilled water.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
<div style="margin-left:12.0pt">
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:Calibri"> </span><b>[jb] Yes, I think I understand that approach, but that’s not really the deployment that I’m thinking of... the scenario I have in mind is this.</b><o:p></o:p></p>
</div>
<div style="margin-left:12.0pt">
<p class="MsoNormal" style="background:white"><b> </b><o:p></o:p></p>
</div>
<div style="margin-left:12.0pt">
<p class="MsoNormal" style="background:white"><b>Two buildings, with data described like this:</b><o:p></o:p></p>
</div>
<div style="margin-left:12.0pt">
<p class="MsoNormal" style="background:white"><b> </b><o:p></o:p></p>
</div>
<div style="margin-left:12.0pt">
<p class="MsoNormal" style="background:white"><b>/building-1/electrical/power/<time></b><o:p></o:p></p>
</div>
<div style="margin-left:12.0pt">
<p class="MsoNormal" style="background:white"><b>which aggregates</b><o:p></o:p></p>
</div>
<div style="margin-left:12.0pt">
<p class="MsoNormal" style="background:white"><b>/building-1/room-7/electrical/power/<time></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b> /building-1/room-8/electrical/power/<time></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"> <span class="apple-converted-space"> </span><b>but there is also</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b> /building-1/hvac/chilled_water_in/<time></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b> etc.<span class="apple-converted-space"> </span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b> </b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b>then, let’s say we want a root level repo that stores electrical data but not HVAC. It provides some secondary advantage by being “close” to some processes that want to run analytics on all of the electrical
data but don’t care about anything else. It’s also run by the electrical folks and they don’t want to worry about anyone else’s data being in their system. It also provides persistence or access scalability for that electrical data beyond what can be offered
by the panels in the field.<span class="apple-converted-space"> </span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b> </b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b>So, to follow what I understand of your comments:</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b> </b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b>1) we need the repo to register every prefix with electrical data that it wishes to serve (which could be very long list of names at different granularity), or</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b>2) we need the data names to start with /electrical (which has other implications for forwarding interests based on building/campus layout), or</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b>3) we need NACK support in strategy(?) so that the repo could NACK prefixes it knows it’s not going to store,</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b>or?<span class="apple-converted-space"> </span></b><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">1) No I did not say that; how many things are feasible to announce is an engineering design issue. For things one does not announce, one needs other means to get the Interests move toward data.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal">3) NFD does handle NACKs.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="background:white"> </span><br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white">3/ again one needs to think not just what one wants to put where, but also how forwarding can work well.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b>[jb] Yes, I understand this. But I think that we are entering territory where what we are asking of people developing and deploying apps can be very sophisticated consideration of multiple intersecting requirements
on namespaces....</b><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal">Now given NDN made apps and network share the same namespace, app people need to work with network people to figure out what is the best way to achieve apps goals.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">No one dictates one solution or another, we simply need to figure things out, and do trials and errors. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">There is no ready solution at this time. <br>
<br>
<br>
<o:p></o:p></p>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"><b> </b><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"><b>so when picking data names we have to consider:</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b> 1. what makes sense for the app internally (and the data itself)</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b> 2. how trust schema are embodied in the namespace</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b> 3. how access granularity / permissions may be embodied in the namespace</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b> 4. global / Internet / enterprise forwarding implications (e.g., forward interests for /building-1 towards building 1)</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b> 5. what requests we want to make fast/efficient with simple interests (e.g., where to put time in the namespace for time series)</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b> 6. AND persistency/storage implications should the data at some point be stored persistently</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b> </b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b>You’ve convinced me before to stop worrying about #4 and allow mechanisms to evolve in the network to take care of this, for the most part.</b><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal">because app people need to first tell what apps need first, then we can see what may be the best way to handle it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">for things that do not seem feasible to be directly supported by network forwarding, one can always add a layer of indirection.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Having app people to start with worrying about network layer problems does not seem to me the best starting point.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"><b> And that for #5, maybe apps should just publish in multiple namespaces, or use sync. But #6 seems to be in the same category... should we really have to worry about what node is making what data persistent
in designing the namespace? Can we do that a priori in real networks with lots of interacting nodes under the control of different developers, deployers, and users?<span class="apple-converted-space"> </span></b><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal">1/ again, app designs should start with app needs first<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2/ then we can see how well that can be supported, then maybe we need to iterate the design.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"><b>Here’s another example – Consider the smart home, where each subsystem that people buy from home depot (ala Phillips Hue) could have its own persistent storage that really doesn’t want to be involved in storage
and publishing of data that’s not relevant to it.. but might (naively?) be thought to publish in the same prefix as each other...</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b> </b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b>For example, let’s say that you buy a few bulbs of the Phillips Hue system and you buy a few bulbs from another manufacturer. Both register /<my-home-prefix>/usage/energy/lights because it’s a well-known convention,
and use name discovery/sync techniques to pick non-conflicting names that make sense to users and apps. <span class="apple-converted-space"> </span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b> </b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b>Let’s say from each manufacturer, you</b><span class="apple-converted-space"> </span><b>also get a wall-wart-sized repo that stores a year’s worth of energy consumption data for any device from Phillips (evaluated
through some data signing/verification scheme)... and another from the other manufacturer. </b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b> </b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b>So here, if we want those repos to have efficient forwarding of appropriate interests to them, the data (from the<span class="apple-converted-space"> </span><i>lights</i>) should have the manufacturer-specific
subprefixes Phillips/ and Foo/ for the respective repos because we don’t want them to publish persistent data in a prefix they don’t have complete information for? Even though we might not really want to enforce this manufacturer-centric data model on the
energy consumption data of our lights necessarily? (In fact the names exposed to the user / their apps for other purposes should ideally not have this at all.)</b><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal">my brain is slow tonight so I didn't figure out exactly what is the ideal solution you wanted from the above.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Once we know that, then we can see what would be the best way to achieve it.<br>
<br>
<br>
<o:p></o:p></p>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:11.0pt;font-family:Calibri">6) What are other requirements to be a ‘repo’? (Alternatively, is there a canonical reference in the literature for the type of storage that constitutes a repo?)</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white">it does not really matter what we want to call something.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white">there is no arbitrary requirement. <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white">as I said already, this is research, we have not done much playing with repo up to now. It is all about figuring out how to make the system work in the best way it can.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="background:white"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><b>[jb] I’d argue that it’s just as important to figure out whether we can keep<u>brittleness</u><span class="apple-converted-space"> </span>and<span class="apple-converted-space"> </span><u>hidden dependencies</u><span class="apple-converted-space"> </span>out
of app design and deployment that emerge from interdependencies between things ostensibly in the control of app developers (names) and those that are not (forwarding configuration, knowing whether ‘my’ repo knows everything in the tree it’s publishing in)....<span class="apple-converted-space"> </span></b><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I do not believe there is any brittleness or hidden dependencies to worry about at this time, as no design has been done yet. I do believe the need for better communications to help everyone see the problem clearly and avoid misunderstandings.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Lixia<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>