Last time this issue came up, it was made very clear that surrounding
the issue of FTP mirrors were sensitivities around the distribution of
Sword modules because of licensing encumbrances. So this purpose of
this email is seek clarification about this given that InstallMgr
appears to be moving in
On Wed, Jul 25, 2012 at 11:10 AM, Andrew Thule wrote:
> Last time this issue came up, it was made very clear that surrounding
> the issue of FTP mirrors were sensitivities around the distribution of
> Sword modules because of licensing encumbrances. So this purpose of
> this email is seek clarifi
Greg, thanks for your response
On Wed, Jul 25, 2012 at 12:27 PM, Greg Hellings wrote:
> I has, since at least the time I started with SWORD in 2004, always
> supported multiple install locations. The only difficulty I'm aware of
> comes with automatic updating if module ABC exists in Repository
On Wed, Jul 25, 2012 at 12:29 PM, Andrew Thule wrote:
> Greg, thanks for your response
>
> On Wed, Jul 25, 2012 at 12:27 PM, Greg Hellings
> wrote:
>
>> I has, since at least the time I started with SWORD in 2004, always
>> supported multiple install locations. The only difficulty I'm aware of
>
On 07/25/2012 09:27 AM, Greg Hellings wrote:
On Wed, Jul 25, 2012 at 11:10 AM, Andrew Thule wrote:
Since Crosswire freely allows modules to be downloaded and governs the
use of these modules afterwards through the each modules' licensing
rights, is there something else that precludes their do
>> On Wed, Jul 25, 2012 at 12:27 PM, Greg Hellings
>> wrote:
> It should. It does not. AFAIK it currently maintains no status
> information on whether ABC came from site X, site Y, a local install
> file, or was manually inserted into the install location. Since
> modules are just a collection o
Andrew,
Not all front-ends use the SWORD-based InstallMgr whose behaviour you just
observed.
For a start, JSword based front-ends have their own JSword-based module
manager.
So it would be unfair to generalize from what happens with one SWORD-based
front-end such as Xiphos.
And, from what I can
David, I suspected as much and don't deny the decision to support one
or more installation sites resides with the client developer. That
said, InstallMgr appears to be moving in that direction, which I think
is a wonderful feature. I suspect different client developers
influence each other featur
On Wed, Jul 25, 2012 at 8:24 PM, Andrew Thule wrote:
>>> On Wed, Jul 25, 2012 at 12:27 PM, Greg Hellings
>>> wrote:
>
>> It should. It does not. AFAIK it currently maintains no status
>> information on whether ABC came from site X, site Y, a local install
>> file, or was manually inserted into t
Greg Hellings writes:
> there is a path underneath modules/ that corresponds with where kjv
> would have been downloaded to (modules/texts/ztext) but the kjv
> directory under that is gone.
...because it was mv'd to the normal location after retrieval.
> Thus, we just ensure that the module name
On Thu, Jul 26, 2012 at 5:53 PM, Karl Kleinpaste wrote:
> Greg Hellings writes:
>> there is a path underneath modules/ that corresponds with where kjv
>> would have been downloaded to (modules/texts/ztext) but the kjv
>> directory under that is gone.
>
> ...because it was mv'd to the normal locat
Greg Hellings writes:
> if I had electronic copies of the "Student's Bible" in KJV and my
> Defender's Study Bible also in KJV, both of them might want to just
> name their module the "KJV". The application should be able to discern
> between "Zondervan's KJV" and "ICR's KJV".
Even in such a case
On Thu, Jul 26, 2012 at 6:51 PM, Karl Kleinpaste wrote:
> Greg Hellings writes:
>> if I had electronic copies of the "Student's Bible" in KJV and my
>> Defender's Study Bible also in KJV, both of them might want to just
>> name their module the "KJV". The application should be able to discern
>>
Greg Hellings writes:
> Remember that module IDs, which are what I'm talking about, are
> extremely limited in which characters can be used. I believe A-Za-z0-9
> and maybe - and/or _. Regardless of the language, etc of the module.
> Theoretically that could easily lead to a collision between modu
Karl,
There's no need to depend on your "memory" to know which is which.
I have both KJV v2.3 (main) and KJV v2.4 (beta) installed successfully, by
means of Xiphos.
To do that I first moved the one from beta & renamed it as KJV24,
by editing the first two lines in the conf file to match the ne
There was such a collision in my experience.
Our friend who maintains the IBT repo uses the name RV for the Russian
Synodal Version.
(don't worry - I've already told him about this minor issue)
This clashes with the standard abbreviation for the English Revised Version
of 1885.
I've made an RV mo
David Haslam writes:
> I have both KJV v2.3 (main) and KJV v2.4 (beta) installed
> successfully, by means of Xiphos.
Well... from your description, "by means of Xiphos" is a considerable
stretch, in that you edited configurations outside Xiphos.
> To do that I first moved the one from beta & ren
On Thu, Jul 26, 2012 at 6:53 PM, Karl Kleinpaste wrote:
> Frankly, I hope not.
>
> The repositories do not represent (as it were) individual bookstores,
> from any of which one might find any given module. Rather, the repos
> represent individual publishers, and patrons get their modules directly
Andrew Thule writes:
> Because there are many modules not representing any publishers,
> modules not subject to restrictions in their licenses, there will be
> repos with redundant copies of modules.
I really don't see your point about this.
Take one example in the Xiphos repo, EarlyFathers ("Th
On 29/07/12 04:56, Karl Kleinpaste wrote:
> I really don't see your point about this.
To second that - there is essentially no point.
People who access us from countries which control their internet and
want to block the Bible, need to be cautious and come through proxies,
tor or whatever or obt
On Sun, Jul 29, 2012 at 7:29 AM, Peter von Kaehne wrote:
>> I really don't see your point about this.
> To second that - there is essentially no point.
Many publicly available repositories replicate themselves. (Take
Sourceforge for example). There are many reason why they do this.
Lower latenc
On Sun, Jul 29, 2012 at 8:20 AM, Andrew Thule wrote:
> On Sun, Jul 29, 2012 at 7:29 AM, Peter von Kaehne wrote:
>>> I really don't see your point about this.
>> To second that - there is essentially no point.
>
> Many publicly available repositories replicate themselves. (Take
> Sourceforge for
Hey guys. Thanks for everyone speaking on this thread. Andrew, I do
appreciate your offer, I sympathize with your single point of failure
and widest distribution possible points; however, I tend to agree with
the replies given on this thread. The primary benefit I see for a
mirror would be f
I think the vision of having the module source provider 'contribute'
the module at a site (such as NET coming from crossway) is also a good
one. That at least means should a single module source be 'shutdown',
others are still available, (even if not containing the module a users
trying to get).
Greg Hellings writes:
> The Xiphos repository essentially fits this description. It is not
> officially a part of CrossWire, but it is listed in the autodiscover
> repository list and is maintained by one of the people in this thread
> to host modules that he personally wanted to see hosted but wh
I've really had to think about this one a while before following up, and
I have to say that I just don't know from where some ideas emanate.
"Troy A. Griffitts" writes:
> The Xiphos repo hosts brave modules which give newer features, but
> which might not yet be fully tested on all platforms (I h
My apologies Karl. I hesitated to even comment. My intent wasn't to demean the
quality, but simply to state what you have stated below. I personally know that
mobiles, swordweb, and BibleCS don't support maps (generally images) very well.
We've discussed a better format than image modules for ma
On Mon, Jul 30, 2012 at 3:38 AM, Troy A. Griffitts wrote:
> The final thing I didn't mention were modules like Gill. We've had
> trouble with tracking down a Gill module with a clean pedigree (well, maybe
> 'cleared' pedigree is a better word). Whereas, Xiphos is also braver is this
> regard to ch
On 30/07/12 17:10, Andrew Thule wrote:
> Troy does this mean that with respect to the modules you host, you go
> through the rigamarole of tracing back to source the copyright status
> for the sake of due diligence?
Yes. We have been caught out, we will get caught out again, no doubt,
but we wi
Thanks Peter, I'm not so interested in the motives of those
contributing the modules or the process by which they are vetted. I
wasn't specifically asking from a Crosswire repo perspective and I
have no doubt these go through a careful filter process. Rather I'm
more interesting in finding out ho
"Troy A. Griffitts" writes:
> My apologies Karl.
None needed, Troy.
> I personally know that mobiles, swordweb, and BibleCS don't support
> maps (generally images) very well.
OK, well, that's not a critique of markup or format or anything else;
that's just features yet unimplemented or not yet
On 07/28/2012 05:56 PM, Karl Kleinpaste
wrote:
Who would want to provide EarlyFathers in a redundant repo? Perhaps
more importantly, why?
More to the point, why not? What advantages are to be gained by
limiting distribution to just one site? How d
On 07/30/2012 07:16 PM, Karl Kleinpaste wrote:
We've discussed a better format than image modules for maps and some
century might get around to implementing something, but Xiphos just
goes out and releases something. That's not a bad thing. I think you
claim that characterization with your head
33 matches
Mail list logo
