<div class="gmail_quote">On Mon, Nov 8, 2010 at 6:37 AM, Karl Kleinpaste <span dir="ltr"><<a href="mailto:karl@kleinpaste.org">karl@kleinpaste.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On the one hand, I appreciate a desire for a combined all-repos view of<br>
what's available. It would be useful in some ways. On the other hand,<br>
I find it problematic for several reasons.<br>
<br>
- It depends on finding all repos operating. Like it or not, repos go<br>
away for short or long periods, and the first time we hang the user's<br>
module manager because one repo has gone dead for an extended period, we<br>
will cause huge PR problems. Especially as we gain more small<br>
publishers' references in the master repo list, to me the likelihood<br>
that one of these will disappear (if for no other reason than that small<br>
entities will not be good at administering such access) seems high.<br>
Consider the trouble we had some months ago when <a href="http://crosswire.org" target="_blank">crosswire.org</a> itself<br>
was firewalled by its ISP to access from all of South Africa and Brazil.<br>
How do we educate users, that they should either manually remove a dead<br>
repo, or must re-sync against the master list when we remove the dead<br>
entry from that? In our one-repo-at-a-time format, as module managers<br>
operate today, at least it's clear which single repo is gone at the<br>
moment, and we don't/can't give an erroneous view that the entire space<br>
of module retrieval has gone dead.<br></blockquote><div><br>Good point: Didn't even occur to me. And I was only reading "The Seven Fallacies of Distributed Computing" last week :(.<br><br>I don't think it's an insuperable obstacle, though. It would be necessary to make sure that all these error cases have a solution which does not hang the program, but I don't think that means not doing a combined view.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
- People know that different stores carry different merchandise. Why is<br>
it any stretch that different repositories have different modules? I<br>
don't expect to find the widest selection of dead-tree Bibles in a<br>
Barnes&Noble, but rather in my local Christian bookstore. Home<br>
construction manuals are best found at Home Depot, not the local<br>
megamall's Borders. (Sure, you'll find some at Borders. The selection<br>
won't be great. B&N and Borders provide "wide but not deep.")<br>
<br>
- Jon asks why one would go looking at the Xiphos repo when searching<br>
for modules. It's a good question, but it's just the question of why<br>
one looks in more than one bookstore. The Xiphos repo exists because<br>
(as instantiated some years ago on my home system) I had modules I<br>
wanted to distribute and was not able to get them into the CrossWire<br>
repo. The Xiphos repo distributes approximately 130G/month these days.<br>
Other entities' distribution of modules will be very similar: They have<br>
content that is not appropriate for CrossWire itself. It makes sense to<br>
me that, to find certain publishers' content, one has to go to that<br>
publisher.<br></blockquote><div><br>Bookstores have physical limitations in what they can carry. We do not necessarily need to have these limitations.<br><br>I still suggest that most people's goals are either:<br>a. Discover what books are available.<br>
b. Discover if book X is available (or maybe books by author Y or on subject Z?)<br><br>If faced with a current Install Manager, I would definitely open repositories one after another to try and answer these questions, but if there is a better way to meet that goal (such as showing a combined view) why not?<br>
<br>I tend to dislike software that forces me to search in certain ways: whether it's "You must select the language before we show you what's available" or "You must select the type of book" or "You must select the publisher's repository", there will be some times when this matches the way I want to search and what I'm looking for, and some times when it does not.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
This overall multi-store scenario has been perverted (and I mean that in<br>
a proper technical sense) by Amazon. Now everyone expects to find every<br>
book in the world at one place. But at least Amazon is, literally, one<br>
place on the web. Our potentially-many repos are all over, the master<br>
repo list is just our local MapQuest equivalent to find them all, and<br>
each will have widely-varying network support and administrative support.<br></blockquote><div><br>Interesting thoughts. However, my expectation comes not from Amazon, but from other Bible software I have used. If I want to know which books are available for e-Sword, I go to the e-Sword website. If I want to know which books are available for Logos, I go to the Logos website. If I want to know which books are available for CrossWire, I go to the CrossWire website. It doesn't list Dore Woodcuts, so I know it doesn't support it. [I do actually know that both e-Sword and Logos have resources which aren't sold by the respective company, but with Logos it's a minority and with e-Sword my impression is that they are mostly breaking copyright so I don't bother looking]. Because I'm interested in Bible software, I'm usually willing to spend the time looking. I'm not sure that everyone is.<br>
<br>Jon<br></div></div>