I guess I need more information on mirrors. Let's say that there are to mirrors X and Y. For what ever reason, X has A, B, C, D and Y has A, D, E. Software is configured to use Y. When it goes to get a list of files, what does it get? If it requests B, what does it get? Same questions for software configured for X and request for E.
-- DM On Jan 7, 2013, at 1:06 PM, Andrew Thule <thules...@gmail.com> wrote: > My experience with mirrors is that mirrors are done at the level of the > Operating Systems. Tools like 'rsync', 'lsync', 'chron' etc manage the > integrity and distribution of these things. > > That said, I think what you're saying is that you believe the Sword client > needs some additional support to support mirrors, and I don't think that's > entirely true. It may be that support for mirrors would be better > accomplished through additional patches, but as it stands now I get all of > Crosswire's modules as a proxy through either my public or private repo for > the very simply reason it's safer for me to do so. > > I have no trouble getting Sword/Crosswire modules from a 'mirror' (as a > proxy), technically which means most clients (though perhaps not all) can > manage this. > > So I'm speaking specifically about Bibletime, Xiphos, Alkitab, PocketSword, > and Eloquent. If there are other clients out there, and Crosswire pursues > 'mirrors', that decision will influence development. > > ~A > > > On Mon, Jan 7, 2013 at 12:55 PM, DM Smith <dmsm...@crosswire.org> wrote: > Mirror management is a moot issue if the software doesn't support mirrors. I > have no plans to add such to JSword, unless it is added to SWORD first. I > highly doubt that it will be added to SWORD until a problem with resiliency > creates a real need. Even then, I'm not sure that that will be used as a > solution. > > In His Service, > DM > > On Jan 7, 2013, at 12:39 PM, Andrew Thule <thules...@gmail.com> wrote: > >> DM, I agree that not having thought through mirror management procedurally >> (policy and best backpractice) is reason enough to hold off on such a >> venture, but those problems are typically trivial to solve given effective >> communication. >> >> Since technology is subordinat to intent, what needs to be worked out to >> move forward along these lines is the clarification of intent. >> >> If I were to look back on this recent discussion, I'd suggest a number of >> principles are already clear: >> -CrossWire resevers the right to approve or deny mirrors >> -CrossWire reserves the right to define which repositorories are considered >> "root" repositories (so authoritive) >> -Distribution of modules exclusively licensed to CrossWire should be >> retained by Crosswire >> -All Mirrors should take no longer than x (period of time) to accurately >> reflect 'root repositories' >> >> Etc. >> This issues have already (to some extent) been hashed through in debate, >> however discussion on the matter was limited, unproductive and unclear >> simply because of the degree of hostility the 'idea' of mirrors alone >> produced. >> >> If there had been an attitude of 'open but undecided' reservation about the >> matter, rather than outright 'hostility' its likely the issues you are >> raising now could have been dealt with more readily. >> >> ~A >> >> >> On Sun, Jan 6, 2013 at 2:17 PM, DM Smith <dmsm...@crosswire.org> wrote: >> A few more reasons we discourage mirroring: >> SWORD and JSword have no means for managing mirrors. They expect each >> repository to be a unique collection of modules. >> >> A mirror that is partial, not containing all that is in the master >> repository, probably will be confusing to users. >> >> A mirror that is hosted along with questionable modules probably will give >> the appearance that CrossWire condones those modules. Especially when the >> modules are in the same repository. >> >> In Him, >> DM >> >> On Jan 4, 2013, at 9:09 AM, DM Smith <dmsm...@crosswire.org> wrote: >> >>> From time to time, interest has been expressed in mirroring CrossWire's >>> SWORD modules. I thought I'd reiterate our policy. >>> >>> We strongly, very strongly, discourage mirroring of the SWORD module >>> repository. >>> >>> Those modules for which CrossWire has obtained distribution permission from >>> copyright holders must not be mirrored. These have >>> "DistributionLicense=Copyrighted; Permission to distribute granted to >>> CrossWire" in their conf. CrossWire maintains correspondence for each of >>> these modules. >>> >>> Mirrors are seldom current/correct, despite intentions. >>> >>> On occasion we have unintentionally hosted modules for which we did not >>> have permission. When presented with an ownership claim, we typically will >>> take the module offline immediately and validate the claim. If the claim is >>> false, we will put the module back up. If the claim is true, we obtain >>> permission before putting the module back online or we don't put it back. >>> This is an important part of our stewardship. >>> >>> If or when CrossWire has problems with distribution, we'll tackle the >>> problem at that time. Probably with a "Content Delivery Network" of >>> CrossWire owned servers. >>> >>> This or some variation of this probably should be in the wiki. >>> >>> In His Service, >>> DM >>> >>> _______________________________________________ >>> sword-devel mailing list: sword-devel@crosswire.org >>> http://www.crosswire.org/mailman/listinfo/sword-devel >>> Instructions to unsubscribe/change your settings at above page >> >> >> _______________________________________________ >> sword-devel mailing list: sword-devel@crosswire.org >> http://www.crosswire.org/mailman/listinfo/sword-devel >> Instructions to unsubscribe/change your settings at above page >> >> _______________________________________________ >> sword-devel mailing list: sword-devel@crosswire.org >> http://www.crosswire.org/mailman/listinfo/sword-devel >> Instructions to unsubscribe/change your settings at above page > > > _______________________________________________ > sword-devel mailing list: sword-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page > > _______________________________________________ > sword-devel mailing list: sword-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page
_______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page