<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 13, 2012 at 7:51 PM, Chris Cunnington <span dir="ltr">&lt;<a href="mailto:smalltalktelevision@gmail.com" target="_blank">smalltalktelevision@gmail.com</a>&gt;</span> wrote:<br>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">1. ALRestfulLocator&gt;&gt;paths &quot;Vat does dis do?&quot; I don&#39;t see anything accessing this dictionary.<br>
</blockquote><div><br></div><div>It&#39;s mainly used in <font face="courier new, monospace">#urlForResource:</font>. It&#39;s badly named, though, so I&#39;ve just committed a fix. It&#39;s now called &quot;urls&quot;.</div>
<div><br></div><div>The job of a locator is to map URLs to resources and the reverse, resources to URLs. <font face="courier new, monospace">ALRestfulLocator</font> does this in such a way that the urls can be arbitrary, and you&#39;ll always get the same URL for semantically equivalent resources. (Consistent urls are required for REST.)</div>
<div><br></div><div>When the locator receives <font face="courier new, monospace">#urlForResource:</font> it calculates a &quot;key&quot; for that resource, by serializing it and hashing the bytes. </div><div>Then it checks to see if a url has already been assigned to that key. If so, great, answer it. If not, it asks its url strategy to create one. Since this is a resource we haven&#39;t seen before, we store the url-&gt; mapping. The <font face="courier new, monospace">resources</font> instance variable maps urls to resources, and the <font face="courier new, monospace">urls</font> instance variable (formerly called <font face="courier new, monospace">paths</font>) maps keys to URLs. Once the mapping is stored, <font face="courier new, monospace">#urlForResource:</font> and <font face="courier new, monospace">#resourceForUrl:</font> just do dictionary lookups.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. An auth/storage relay example, please.<br></blockquote><div><br></div><div>Yeah, working on it. AL-Storage contains <font face="courier new, monospace">ALStorageRelay</font>, which is mostly working now and generates <font face="courier new, monospace">ETag</font> headers for resources based on domain model objects stored in an <font face="courier new, monospace">ALRepository</font>. Auth isn&#39;t implemented yet. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. ALNotFound:/favicon.ico now shows up with every click.<br></blockquote><div><br></div><div>Are you getting 404 responses? If so, you just need to create a resource at that url. If not, it&#39;s a bug in Altitude.</div>
<div><br></div><div>Something like in your #initializeLocator method:</div><div><br></div><div><font face="courier new, monospace">locator </font></div><div><font face="courier new, monospace">    at: (ALPath / &#39;favicon.ico&#39;) </font></div>
<div><font face="courier new, monospace">    put: (ALFileResource on: (FSLocator imageDirectory / &#39;favicon.ico&#39;))</font></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

4. Why there are random urls?<br></blockquote><div><br></div><div>As I mentioned above, the urls that <font face="courier new, monospace">ALRestfulLocator</font><font face="arial, helvetica, sans-serif"> generates can be anything. This is why we can set up an image a file resource at /favicon.ico, which is hardcoded into browsers. It also means that when we generate urls automatically, we can use whatever scheme we want. This is what </font><font face="courier new, monospace">ALUrlStategy</font><font face="arial, helvetica, sans-serif"> subclasses are for:</font></div>
<div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="courier new, monospace">ALSequentialUrlStrategy</font><font face="arial, helvetica, sans-serif"> generates urls in a predicable sequence: /1, /2, /3 etc. This is handy for testing. It might also be good for something like a URL shortening service where the shortest possible URLs are desirable. </font></div>
<div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="courier new, monospace">ALRandomUrlStrategy</font><font face="arial, helvetica, sans-serif"> does the opposite. It generates pseudo-random unguessable URLs. That makes a web application more secure.</font></div>
<div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="courier new, monospace">ALDigestUrlStrategy</font><font face="arial, helvetica, sans-serif"> provides a middle path between predictability and unpredictability. It creates urls that are difficult to guess, but consistent. So, for example, two different images running the same application would generate the same urls for equivalent resources. (This wouldn&#39;t be the case with random urls).</font></div>
<div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Colin</font></div></div></div>