Troy,
That does answer a lot of questions. Just a few notes on why I think
that the remote source versions don't have to be different at all:
On Fri, May 15, 2009 at 12:58 AM, Troy A. Griffitts
wrote:
> "Until you understand the details, design always sounds simple."
> --I'm sure, some famous
"Until you understand the details, design always sounds simple."
--I'm sure, some famous architect near retirement.
There is a basic and practical difference between a local and a remote
installation, however abstract you want to get.
Remote repositories have concepts like 'refresh from rem
On Thu, May 14, 2009 at 11:29 PM, Matthew Talbert wrote:
>> Does it require a difference (for the C++ front ends) to add support
>> for FTP InstallMgr methods than it does for them to add a file://
>> version? It seems that, if so, this is a problem with the design of
>> InstallMgr. I would imag
> Does it require a difference (for the C++ front ends) to add support
> for FTP InstallMgr methods than it does for them to add a file://
> version? It seems that, if so, this is a problem with the design of
> InstallMgr. I would imagine that the interface between SWORD and the
> application wou
On Thu, May 14, 2009 at 9:53 PM, Troy A. Griffitts wrote:
> Thank Matthew. Yes Daniel, we have had an established standard for
> installing modules for quite some time which uses FTP for remote module
> installation. I would like all of our client applications to support all of
> our officially
Just a bit of history regarding JSword. We have an FTP mechanism. We
moved it to limbo, but can put it back at any time, with little
effort. It worked just fine on Windows XP until a particular patch
came out. After that, FTP was blocked by Windows XP. But we already
had complaints that FTP
Thanks for your assurances, Matthew and Troy. Just to make sure I've
understood, FTP was chosen initially because you can download multiple
files more easily, which is why JSword requires zipped modules when
downloading over HTTP. Adding the ability to download from a working
SWORD library over
Thank Matthew. Yes Daniel, we have had an established standard for
installing modules for quite some time which uses FTP for remote module
installation. I would like all of our client applications to support
all of our officially supported install methods.
The reason for this is so we can as
Chris said:
The ZIPs are only created by the download servlet.
If this is correct, then none of:
for module in $(cat /usr/share/sword/mods.d./*.conf | grep -e
'^\[.*\]$' | sed -e 's/\[(.*)\]/\1/'); do
installmgr -ri CrossWire $module;
done
for module in $(cat /path/to/zips); do
> I think I caught your drift with the caps in your previous message, but it's
> a bit discouraging and doesn't yet answer the problem I raised awhile back.
>
> To recap, because of security concerns with having anonymous FTP access, one
> group I work with effectively denied us the ability to set
> wget will pull over http or ftp. It's ca-raze-ey like that! :O
>
> Where is the list of all the files that need to be pulled?
>
> --Greg
Presumably all the raw zips linked from
http://crosswire.org/sword/modules/ModDisp.jsp?modType=Bibles and the
related pages.
Matthew
___
On Thu, May 14, 2009 at 8:29 PM, Matthew Talbert wrote:
>> >> The (to my mind) greater issue is simply that it this system requires
>> >> someone else to have already downloaded the most recent version of a
>> >> module.
>> >> The ZIPs are only created by the download servlet. Assuming our hope t
> Xiphos: Again, Dmitry's current packages should already work fine with SWORD
> 1.6.0.
This is correct. Xiphos 3.0.1 is compatible with 1.6.0. We are
planning another release Sunday, including a Windows release packaged
with 1.6.0. It's important to realize that "compatible" merely means
"compile
> >> The (to my mind) greater issue is simply that it this system requires
> >> someone else to have already downloaded the most recent version of a
> >> module.
> >> The ZIPs are only created by the download servlet. Assuming our hope that
> >> people migrate to InstallMgrs comes true, fewer and
On Thu, May 14, 2009 at 7:38 PM, Jonathan Marsden wrote:
> Chris Little wrote:
>
>> The (to my mind) greater issue is simply that it this system requires
>> someone else to have already downloaded the most recent version of a module.
>> The ZIPs are only created by the download servlet. Assuming o
Excellent to hear! I'll get versions of BibleTime built with the
latest SWORD released library up for Windows and Mac in the upcoming
very few days.
--Greg
On Thu, May 14, 2009 at 3:28 AM, Troy A. Griffitts wrote:
> I am very pleased to announce the release of 1.6.0. Finally, our very first
> r
David Haslam wrote:
Next task - as a follow up. Post a news item in
http://crosswire.org/index.jsp?section=News
and outline when the binaries for each "1.6 compatible front-end" are
expected to become available for download.
Here is my Debian/Ubuntu-biased perspective, in alphabetical order:
Chris Little wrote:
The (to my mind) greater issue is simply that it this system requires
someone else to have already downloaded the most recent version of a
module. The ZIPs are only created by the download servlet. Assuming our
hope that people migrate to InstallMgrs comes true, fewer and f
Troy A. Griffitts wrote:
Dear DM and other,
Maybe someone can help a bit. The problem we ran into was that there
was no reliable way to download a folder via http and there was no
way to reliably know the content of the folder.
Yes, agreed, this is why implementing this on the C++ side is n
Dear DM and other,
Maybe someone can help a bit. The problem we ran into was that there was
no reliable way to download a folder via http and there was no way to
reliably know the content of the folder.
Yes, agreed, this is why implementing this on the C++ side is not yet
complete. It is no
On May 14, 2009, at 15:39, DM Smith wrote:
Chris Little wrote:
Troy A. Griffitts wrote:
I would like to add new officially supported methods, like adding:
o Installation of modules from another existing SWORD library
installation via HTTP ( e.g., http://crosswire.org/ftpmirror/pub/
Chris Little wrote:
Troy A. Griffitts wrote:
I would like to add new officially supported methods, like adding:
o Installation of modules from another existing SWORD library
installation via HTTP ( e.g.,
http://crosswire.org/ftpmirror/pub/sword/raw )
A skeleton class for this method was
And another thing...
This module is built with the most recent osis2mod (1.6.0), so look upon
it as a test of that as well.
--Chris
Chris Little wrote:
Once you've got 1.6.0 in your hands and working, take a look at the new
WLC module, based on WLC 4.10.
The big new feature *should* be the
Troy A. Griffitts wrote:
I would like to add new officially supported methods, like adding:
o Installation of modules from another existing SWORD library
installation via HTTP ( e.g.,
http://crosswire.org/ftpmirror/pub/sword/raw )
A skeleton class for this method was already added in 1.6
To outline the supported logic for SWORD module installation as it
currently stands:
The SWORD Project library, as of 1.6.0 currently has builtin features to
support:
o Management of an existing SWORD library installation
(provided the user has proper permissions to perform the actions, etc
On May 13, 2009, at 11:50 PM, Jonathan Morgan wrote:
On Thu, May 14, 2009 at 11:07 AM, Daniel Owens
wrote:
You've got my vote. It seems to be an understandable confusion that
zipped
modules are available but most front-ends don't support their use.
BPBible
implemented the installation of
Hi all,
I have just discovered that the ThML Calvin commentary files from
CCEL, though labelled as public domain (both on their site, and in the
actual ThML), are actually copyrighted (that is, the ThML tags rather
than the text itself). The CalvinCommentaries OSIS module hosted on
Crosswire
Tischendorf actually has noticeable differences from NA27.
Westcott-Hort might be better, if it had the same morphological analysis.
Daniel Owens wrote:
I must have missed the announcement about MorphGNT. It's a real shame.
I hope the openscriptures folk figure out a solution. It sounds like
Terrific news!
Next task - as a follow up. Post a news item in
http://crosswire.org/index.jsp?section=News
and outline when the binaries for each "1.6 compatible front-end" are
expected to become available for download.
-- David
Troy A. Griffitts wrote:
>
> I am very pleased to announce the
You have my vote too!
btw. The MK program on the IBT website even supports module adding by
drag'n'drop of the ZIP file anywhere in the application Window. As a
simplicity feature for novice users this is a highly attractive behaviour
for any SWORD front end.
-- David
Daniel Owens wrote:
>
Once you've got 1.6.0 in your hands and working, take a look at the new
WLC module, based on WLC 4.10.
The big new feature *should* be the use of native versification: Malachi
will have 3 chapters, Nehemiah is the last book of the Bible, the
Chronicles come between Malachi & Psalms, and the NT
Congratulations and thank you from the BibleTime team!
mg
am Donnerstag, 14. Mai 2009 um 10:28 schrieben Sie:
> I am very pleased to announce the release of 1.6.0. Finally, our very
> first release supporting the long requested feature: alternate
> versification!
> As usually, it is the resu
I am very pleased to announce the release of 1.6.0. Finally, our very
first release supporting the long requested feature: alternate
versification!
As usually, it is the result of so many contributing their part.
We've had such a blessing of new people pitch in toward this release.
And I am
The Win32 utilities bundle for 1.6.0 is posted at
http://crosswire.org/ftpmirror/pub/sword/utils/win32/sword-utilities-1.6.0.zip
Since we're now compiling utilities in MSVC, they are much smaller and
hopefully a bit faster. Due to their much reduced size, I've eliminated
the individual utility
Am 14.05.2009 um 04:50 schrieb Jonathan Morgan:
On Thu, May 14, 2009 at 11:07 AM, Daniel Owens
wrote:
You've got my vote. It seems to be an understandable confusion that
zipped
modules are available but most front-ends don't support their use.
BPBible
implemented the installation of modu
35 matches
Mail list logo