I concur with DM, the Sword/JSword/UIs would have to change. I've had that issue with having modules in both the normal repo and the (old?) beta repository. The frontends give a false impression as to which module came from which repository.
On 7 January 2013 19:50, DM Smith <[email protected]> wrote: > > On Jan 7, 2013, at 2:04 PM, Andrew Thule <[email protected]> wrote: > > Ok. In your example you have two levels of mirrors, root and banch. > > If we assume all mirrors are synced (exactly the same), the client (if it > supports more than a preferred mirror) will check its mirrors in the order > they are specified. > > > This is precisely my point: Client software has to change. > > > So in your case, Y will check A. D. and E. in that order (assuming it > checks all of its configured mirrors) > If all mirrors are exactly the same however, it doesn't need to check A. > D. and E. It only needs to check A. If A is down, it will check D. etc. > > If a change is made at the top level however, say an ESV update, there is > a propigation time it takes for the mirrors to catch up. With high volume > Linux mirrors this is minutes. If Crosswire were to have mirrors, it might > have a policy that says something like mirrors are to syncronise no more > than 24 hours no less than 6. > > That means in your demonstration it may take A. D. and E. upto 24 hours to > reflect the change. Unlike Linux distributions however, its likely there > can be some tollerance for such propigation effects. > > > In my case, B is licensed only to CrossWire for distribution. E is the a > module which has been added to one mirror but not on the master, say the > DSS. These two are not true mirrors. > > SWORD and JSword can be configured with multiple repositories. They handle > them differently. But suffice it to say that they expect that a module is > in one and only one repository. The behavior is undefined if it occurs in > more than one. > > > ~A > > > > > On Mon, Jan 7, 2013 at 1:52 PM, DM Smith <[email protected]> wrote: > >> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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: [email protected] >>>> http://www.crosswire.org/mailman/listinfo/sword-devel >>>> Instructions to unsubscribe/change your settings at above page >>>> >>>> >>>> >>>> _______________________________________________ >>>> sword-devel mailing list: [email protected] >>>> http://www.crosswire.org/mailman/listinfo/sword-devel >>>> Instructions to unsubscribe/change your settings at above page >>>> >>> >>> _______________________________________________ >>> sword-devel mailing list: [email protected] >>> http://www.crosswire.org/mailman/listinfo/sword-devel >>> Instructions to unsubscribe/change your settings at above page >>> >>> >>> >>> _______________________________________________ >>> sword-devel mailing list: [email protected] >>> http://www.crosswire.org/mailman/listinfo/sword-devel >>> Instructions to unsubscribe/change your settings at above page >>> >> >> _______________________________________________ >> sword-devel mailing list: [email protected] >> http://www.crosswire.org/mailman/listinfo/sword-devel >> Instructions to unsubscribe/change your settings at above page >> >> >> >> _______________________________________________ >> sword-devel mailing list: [email protected] >> http://www.crosswire.org/mailman/listinfo/sword-devel >> Instructions to unsubscribe/change your settings at above page >> > > _______________________________________________ > sword-devel mailing list: [email protected] > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page > > > > _______________________________________________ > sword-devel mailing list: [email protected] > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page >
_______________________________________________ sword-devel mailing list: [email protected] http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
