<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">I know that it mostly a cost and reconfiguration thing, but has there been any thought to maybe make multiple servers? With the front end doing a round robin to distribute the load? I’m saying this without knowing what kind of loads the server is experiencing, or whether there are log files that record the activity. <br><br><div id="AppleMailSignature" dir="ltr">Sent from my iPhone<div><a href="https://boincstats.com/signature/-1/user/51616339056/sig.png">https://boincstats.com/signature/-1/user/51616339056/sig.png</a></div><div><span style="background-color: rgba(255, 255, 255, 0);">See <a href="https://objectnets.net">https://objectnets.net</a> and <a href="https://objectnets.org">https://objectnets.org</a></span></div></div><div dir="ltr"><br>On Jan 27, 2019, at 18:45, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><span>Hi Levente,</span><br><span></span><br><blockquote type="cite"><span>On Jan 27, 2019, at 5:40 PM, Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu">leves@caesar.elte.hu</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>On Sun, 27 Jan 2019, Chris Muller wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Hi,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Yes, the SqueakMap server image is one part of the dynamic, but I</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>think another is a bug in the trunk image. I think the reason Tim is</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>not seeing 45 seconds before error is because the timeout setting of</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>the high-up client is not being passed all the way down to the</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>lowest-level layers -- e.g., from HTTPSocket --> WebClient --></span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>SocketStream --> Socket. By the time it gets down to Socket which</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>does the actual work, it's operating on its own 30 second timeout.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I would expect subsecond reponse times. 30 seconds is just unacceptably</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>long.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Well, it depends on if, for example, you're in the middle of</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Antarctica with a slow internet connection in an office with a fast</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>connection. A 30 second timeout is just the maximum amount of time</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>the client will wait for the entire process before presenting a</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>debugger, that's all it can do.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>We can be sure that Tim should get subsecond response times instead of</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>timeouts after 30 seconds.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Right, but timeout settings are a necessary tool sometimes, my point</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>was that we should fix client code in trunk to make timeouts work</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>properly.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Incidentally, 99% of SqueakMap requests ARE subsecond -- just go to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="http://map.squeak.org">map.squeak.org</a> and click around and see. For the remaining 1% that</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>aren't, the issue is known and we're working on a new server to fix</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>that.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Great! That was my point: the image needs to be fixed.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>It is a fixed amount of time, I *think* still between 30 and 45</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>seconds, that it takes the SqueakMap server to save its model after an</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>and so if in the meantime it can simply be made to wait 45s instead of</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>30s, then current SqueakMap will only be that occasional delay at</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>worst, instead of the annoying debugger we currently get.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I don't see why that would make a difference: the user would get a debugger anyway, but only 15 seconds later.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>You would save seconds, not milliseconds by not downloading files again.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>IIUC, you're saying we would save one hope in the "download" --</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>instead of client <--> alan <--> andreas, it would just be client <--></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>alan. Is that right?</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>No. If the client doesn't have the mcz in the package cache but nginx has</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>it in its cache, then we save the transfer of data between alan and</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>andreas.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Are alan and andreas co-located?</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>They are cloud servers in the same data center.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>The file doesn't have to be read from the disk either.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I assume you mean "read from disk" on alan? What about after it's</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>cached so many mcz's in RAM that its paging out to swap file? To me,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>wasing precious RAM (of any server) to cache old MCZ file contents</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>that no one will ever download (because they become old very quickly)</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>feels wasteful. Dragster cars are wasteful too, but yes, they are</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>"faster"... on a dragstrip. :) I guess there'd have to be some kind</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>of application-specific smart management of the cache...</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Nginx's proxy_cache can handle that all automatically. Also, we don't need a large cache. A small, memory-only cache would do it.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Levente, what about the trunk directory listing, can it cache that?</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Sure.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>That is the _#1 thing_ <a href="http://source.squeak.org">source.squeak.org</a> is accessing and sending back</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>over, and over, and over again -- every time that MC progress box that</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>says, "Updating [repository name]".</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Right, unless you update an older image.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>If the client does have the mcz, then we save the complete file transfer.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I don't know what the speed between alan <---> andreas is, but I doubt</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>it's much slower than client <---> alan in most cases, so the savings</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>would seem to be minimal..?</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>The image wouldn't have to open a file, read its content from the disk and</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>send that through a socket.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>By "the image" I assume you mean the SqueakSource server image. But</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>opening the file takes very little time. Original web-sites were</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>.html files, remember how fast those were? Plus, filesystems "cache"</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>file contents into their own internal caches anyway...</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Each file uses one external semaphore, each socket uses three. If you use a default image, there can be no more than 256 external semaphores which is ridiculous for a server, and it'll just grind to a halt when some load arrives. Every time the external semaphore table is full, a GC is triggered to try clear it up via the finalization process.</span><br></blockquote><blockquote type="cite"><span>Reading a file into memory is slow, writing it to a socket is slow.</span><br></blockquote><blockquote type="cite"><span>(Compared to nginx which uses sendfile to let the kernel handle that).</span><br></blockquote><blockquote type="cite"><span>And Squeak can only use a single process to handle everything.</span><br></blockquote><span></span><br><span>That’s configurable. Alas because writing lock-free table growth is not easy the external semaphore table doesn’t grow automatically. But the vm does allow its size to be specified in a value cached in the image header and read at startup (IIRC). So we could easily have a 4K entry external semaphore table.</span><br><span></span><br><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Yes, it still has to return back through alan but I assume alan does</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>not wait for a "full download" received from andreas before its</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>already pipeing back to the Squeak client. If true, then it seems</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>like it only amounts to saving one hop, which would hardly be</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>noticeable over what we have now.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The goal of caching is not about saving a hop, but to avoid handling files in Squeak.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Nginx does that thing magnitudes faster than</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Squeak.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>The UX would not be magnitudes faster though, right?</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Directly by letting nginx serving the file, no, but the server image would be less likely to get stalled (return 5xx responses).</span><br></blockquote><blockquote type="cite"><span>But the caching scheme I described in this thread would make the UX a lot quicker too, because data would not have to be transferred when you already have it.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>That would also let us save bandwidth by not downloading files already</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>sitting in the client's package cache.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>How so? Isn't the package-cache checked before hitting the server at</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>all? It certainly should be.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>No, it's not. Currently that's not possible, because different files can</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>have the same name. And currently we have no way to tell them apart.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>No. No two MCZ's may have the same name, certainly not withiin the</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>same repository, because MCRepository cannot support that. So maybe</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Not at the same time, but it's possible, and it just happened recently</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>with Chronology-ul.21.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>It is perfectly possible that a client has a version in its package cache</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>with the same name as a different version on the server.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>But we don't want to restrict what's possible in our software design</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>because of that. That situation is already a headache anyway. Same</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>name theoretically can come only from the same person (if we ensure</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>unique initials) and so this is avoidable / fixable by resaving one of</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>them as a different name...</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>It wasn't me who created the duplicate. If your suggestion had been in place, some images out there, including mine, would have been broken by the update process.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>we need project subdirectories under package-cache to properly</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>simulate each cached Repository. I had no idea we were neutering 90%</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>of the benefits of our package-cache because of this too, and just</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>sitting here, I can't help wonder whether this is why MCProxy doesn't</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>work properly either!</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>The primary purpose of a cache is to *check it first* to speed up</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>access to something, right? What you say about package-cache sounds</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I don't know. It wasn't me who designed it. :)</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I meant ANY "cache".</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> <a href="https://en.wikipedia.org/wiki/Cache_(computing)">https://en.wikipedia.org/wiki/Cache_(computing)</a></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>It still depends on the purpose of the cache. It's possible that package-cache is just a misnomer or it was just a plan to use it as a cache which hasn't happened yet.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>For Monticello, package-cache's other use-case is when an</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>authentication issue occurs when trying to save to a HTTP repository.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>At that point the Version object with the new ancestry was already</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>constructed in memory, so rather than worry about trying to "undo" all</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>that, it was simpler and better to save it to a package-cache, persist</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>it safely so the client can simply move forward from there (get access</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>to the HTTP and copy it or whatever).</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The package-cache is also handy as a default repository and as an offline storage.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Levente</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>- Chris</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>really bad we should fix that, not surrender to it.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Yes, that should be fixed, but it needs changes on the server side.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>What I always had in mind was to extend the repository listing with</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>hashes/uuids so that the client could figure out if it needs to download a</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>specific version. But care must be taken not to break the code for</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>non-ss repositories (e.g. simple directory listings).</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Levente</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>- Chris</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><span></span><br></div></blockquote></body></html>