[sword-devel] CrossWire mirroring

Mon Jan 7 13:19:08 MST 2013

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 <dmsmith at crosswire.org> wrote:

>
> On Jan 7, 2013, at 2:04 PM, Andrew Thule <thulester at gmail.com> 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 <dmsmith at crosswire.org> 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 <thulester at 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 <dmsmith at 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 <thulester at 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 <dmsmith at 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 <dmsmith at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20130107/fb3d75cc/attachment.html>