Re: [sword-devel] InstallMgr::getModuleStatus / Performance optimization possible?

Hi Troy, Thank you for taking the time to test. Are you sure you have built with usrinst.sh options adjusted to switch to release optimizations? I am building SWORD with CMake. I had a look and found that I did not explicitly set the CMake build type (CMAKE_BUILD_TYPE) to "Release" when buil

Re: [sword-devel] InstallMgr::getModuleStatus / Performance optimization possible?

Dear Tobias, Thank you for taking the time to test. Are you sure you have built with usrinst.sh options adjusted to switch to release optimizations? Also, I wanted to mention that the cache is built upon the first scan of the files in the folder. I am not sure what your test program does, but

Re: [sword-devel] InstallMgr::getModuleStatus / Performance optimization possible?

Hi Troy, Thanks for looking into this! Just running this on my Dev PC (Linux, SSD disk, Intel i7) I am actually noticing a degradation with this change ... but only at first sight and compared to the SWORD version I have been using before. I am running this function within a test binary. htt

Re: [sword-devel] InstallMgr::getModuleStatus / Performance optimization possible?

OK Tobias, I have a first cut of a caching mechanism for a mods.d/ folder coded up and pushed to trunk.  I have attempted to remove the cache when the folder is changed (= new module is installed or removed), but I possibly have forgotten something.  Give it a go and let me know if it improves

Re: [sword-devel] InstallMgr::getModuleStatus / Performance optimization possible?

Thank you, Troy! I'd be glad to test any changes you come up with! Best regards, Tobias On 11/3/22 5:57 PM, Troy A. Griffitts wrote: Dear Tobias, I can have a look at optimizing getModuleStatus.  I can certainly see that only checking locally installed modules might be a speed improvement,

Re: [sword-devel] InstallMgr::getModuleStatus / Performance optimization possible?

Dear Tobias, I can have a look at optimizing getModuleStatus.  I can certainly see that only checking locally installed modules might be a speed improvement, but I suspect most of the time is loading all the .conf files for each module, and that is done when constructing the SWMgr (remote and

Re: [sword-devel] installmgr -r different behaviour

Hi Teus, SWORD compiled without zlib support must download each .conf file one by one. I would check the build where this is happening and provide zlib support during the build. Hope this helps, Troy On March 12, 2021 4:26:03 AM MST, Teus Benschop wrote: >Hello, > >The installmgr seems to be

Re: [sword-devel] InstallMgr Woes

Just to prove to myself that I'm not completely crazy, I just did the same process on my Windows machine where I'm running Fedora 33 in WSL2, using the exact same bits and bytes of SWORD. I still had to edit /etc/sword.conf to avoid writing files to /usr/share/sword, but it installed the KJV to ~/

Re: [sword-devel] InstallMgr Woes

On Fri, Feb 5, 2021 at 12:49 PM Troy A. Griffitts wrote: > Hi Greg, > > I few quick comments and thoughts... > > So, regarding the commandline tool and option: installmgr -init > > This simply does: > > SWBuf baseDir = FileMgr::getSystemFileMgr()->getHomeDir(); > i

Re: [sword-devel] InstallMgr Woes

Hi Greg, I few quick comments and thoughts... So, regarding the commandline tool and option: installmgr -init This simply does:     SWBuf baseDir = FileMgr::getSystemFileMgr()->getHomeDir();     if (baseDir.length() < 1) baseDir = ".";     baseDir += "/.sword

Re: [sword-devel] installmgr docs

I was actually looking for a webpage that I could link users of my app to, since I currently don't have any sort of module installation code set up. ___ sword-devel mailing list: sword-devel@crosswire.org http://crosswire.org/mailman/listinfo/sword-dev

Re: [sword-devel] installmgr docs

Hi Loren, No. I believe installmgr has a fairly verbose usage statement describing all the options and includes examples. Your perspective from a new user's standpoint is valuable. What questions do you have that might be helpful for us to answer in the usage text? Troy On December 17, 2020 4

Re: [sword-devel] installmgr problem

Peter, I had no problem installing a module from CrossWire - using Xiphos for Windows. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/installmgr-problem-tp4655427p4655428.html Sent from the SWORD Dev mailing list archive at Nabble.com. _

Re: [sword-devel] installmgr bug?

Just to add, the "other" local option "-li" for install from a specified directory works just fine. Peter On Tue, 2015-07-21 at 09:02 +0200, Peter von Kaehne wrote: > Testing various commandline installmgr options I found some odd > behaviour > > installmgr --ll ./ should list all modules in thi

Re: [sword-devel] InstallMgr does not install modules in several conditions

Thank your for your reply. Indeed the order is detailed in the file INSTALL. Never mind (I think installmgr should output an error, and I still don't understand why installmgr creates and uses ~/.sword/Installmgr, and is not able to create ~/.sword/mods.d...) Le 28/10/2013 23:34, Troy A. Griff

Re: [sword-devel] InstallMgr does not install modules in several conditions

Installmgr attempts to install modules to your primary SWORD module folder. There is a priority order in which this folder is found. CWD is higher priority, the SWORD_PATH env variable, some other locations, and also location set in /etc/sword.conf. there's a readme somewhere with the lookup ord

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

Am Sat, 06 Jul 2013 03:51:01 +0200 schrieb "Troy A. Griffitts" : > Mark and Jaak, Hi, > Thanks for your work on this. I've applied a modified patch from the > resolved update from Mark. Please have a look and let me know if > this tests ok against your repository. The modification was to > s

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

Mark and Jaak, Thanks for your work on this. I've applied a modified patch from the resolved update from Mark. Please have a look and let me know if this tests ok against your repository. The modification was to simplify the logic using SWBuf instead of a char *. Thanks again for the patc

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

Replying to myself again, maybe I should find a doctor :) one patch didn't apply right away, I ported it to current trunk and made one big patch file out of the 3. The attached one should work right away. Testet with my own repository and with crosswire.org http(s) repositories. Blessings Mark On

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

ok, just to summarize, what we need is: https://gitorious.org/~jotik/sword-svn-mirrors/jotiks-sword-trunk/commit/1b8ab91ff994c8584d6c61cb7d334273732d8216?format=patch https://gitorious.org/~jotik/sword-svn-mirrors/jotiks-sword-trunk/commit/4a261b27a7bec9d9300da6c357666a3851f3d34e?format=patch https

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

On Tue, Jul 2, 2013 at 9:50 AM, Jaak Ristioja wrote: > Well, if pBufRes == NULL, then pBufRes < pBuf. > > For reference, here is the latest version of this source file: > > > https://gitorious.org/~jotik/sword-svn-mirrors/jotiks-sword-trunk/blobs/master/src/mgr/curlhttpt.cpp > > It currently only

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02.07.2013 09:45, Mark Trompell wrote: >> Question is how can pBufRes get <= pBuf, if the char is found it >> is >= pBuf or NULL if char isn't found. The only reason for >> pBuf==pBufRes I can imagine is a which is annoying >> but not really a reas

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

re you go! Took me half an hour. >> >> Blessings, Jaak >> >> On 27.06.2013 22:41, Mark Trompell wrote: >>>>> I see. I'll try to come up with a better patch on Monday. I >>>>> won't have time earlier. Blessings Mark --- Ursprüngl. >>

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

c9d9300da6c357666a3851f3d34e > > There you go! Took me half an hour. > > Blessings, Jaak > > On 27.06.2013 22:41, Mark Trompell wrote: >>>> I see. I'll try to come up with a better patch on Monday. I >>>> won't have time earlier. Blessings Mark

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

tch on Monday. I won't >> have time earlier. Blessings Mark --- Ursprüngl. Mitteilung --- >> Von: Jaak Ristioja Gesend.: 27.06.2013, 16:15 An: >> sword-devel@crosswire.org Betreff: Re: [sword-devel] installmgr >> (and xiphos) crashes (svn 2831) >> >> >> I thi

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

Von: Jaak Ristioja Gesend.: 27.06.2013, 16:15 An: > sword-devel@crosswire.org Betreff: Re: [sword-devel] installmgr > (and xiphos) crashes (svn 2831) > > > I think you only fixed pBuf not being set to NULL prematurely. But > this: > > memset(possibleName, 0, 400); >

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

I see. I'll try to come up with a better patch on Monday. I won't have time earlier. Blessings Mark --- Ursprüngl. Mitteilung --- Von: Jaak Ristioja Gesend.: 27.06.2013, 16:15 An: sword-devel@crosswire.org Betreff: Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think you only fixed pBuf not being set to NULL prematurely. But this: memset(possibleName, 0, 400); doesn't help. The sprintf function always writes a terminating \0 character. The problem is not that a \0 character is not written, because it is

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

Sending again with tabs instead of blancs in the first hunk On Thu, Jun 27, 2013 at 1:17 PM, Mark Trompell wrote: > I just fixed it :). > Attached patch will initialize possibleNames with 0 bytes to make sure > we always have the name 0 terminated properly. > and it will move the pBuf=pBufRes int

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

I just fixed it :). Attached patch will initialize possibleNames with 0 bytes to make sure we always have the name 0 terminated properly. and it will move the pBuf=pBufRes into the check for ifBufRes != NULL, in case no filesize is found (because of another apache is displaying it differently) Shou

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

I believe the issue we had which didn't make this easy was that libz only handles the compression aspect of zip; it didn't offer facilities to deal with the internal directory and file structures. It is certainly on my list as an optimization option for a repository, but I hope to continue to su

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

It would be even nicer if a few other front-ends could install .zip modules just like xulsword does for .xsm files. i.e. By drag&drop into the running app. Of course, some platforms don't support drag&drop, but as some do, it's worth thinking about. David

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

On 6/26/2013 5:43 PM, Nic Carter wrote: Ok, noted. Thanks Jaak. FYI, I don't have SVN access either. I'd appreciate it if you did fork on git and made the changes there to be downloading the ZIP files directly. I know it's on Troy's todo list, but we all have issues with lack of time around her

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok. I pushed my own changes to Sword to Gitorious: https://gitorious.org/~jotik/sword-svn-mirrors/jotiks-sword-trunk which is based on my Sword SVN trunk git mirror: https://gitorious.org/sword-svn-mirrors/trunk I think there's currently not mu

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

Ok, noted. Thanks Jaak. FYI, I don't have SVN access either. I'd appreciate it if you did fork on git and made the changes there to be downloading the ZIP files directly. I know it's on Troy's todo list, but we all have issues with lack of time around here[1]. I'd take your changes and use the

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

Hi Greg, On Wed, Jun 26, 2013 at 2:58 PM, Greg Hellings wrote: > > > > On Wed, Jun 26, 2013 at 8:44 AM, Nic Carter wrote: > >> (Sorry for the top reply) >> >> IMHO it would be easier to switch to downloading a ZIP file of the module >> than it would to add the infrastructure required to generate

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ZIP files would be OK. But these architectural changes: The thing is that I'm either lazy or just don't have too much time on my hands. And since I have no write access to Swords SVN to fix anything, it were just so much easier for me to fork on git t

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

On Wed, Jun 26, 2013 at 8:44 AM, Nic Carter wrote: > (Sorry for the top reply) > > IMHO it would be easier to switch to downloading a ZIP file of the module > than it would to add the infrastructure required to generate a custom > listing of file names. > I encountered the issues you point out (a

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

On Wed, Jun 26, 2013 at 8:35 AM, Jaak Ristioja wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 26.06.2013 16:25, Greg Hellings wrote: > > bserver directory listing output (which is what I think it does). > > > > V E R Y V E R Y B A D P R A C T I C E ! ! ! > > > > > > Parsing

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

(Sorry for the top reply) IMHO it would be easier to switch to downloading a ZIP file of the module than it would to add the infrastructure required to generate a custom listing of file names. I encountered the issues you point out (and agree with you) & gave up. If/when the CrossWire httpd ser

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26.06.2013 16:25, Greg Hellings wrote: > bserver directory listing output (which is what I think it does). > > V E R Y V E R Y B A D P R A C T I C E ! ! ! > > > Parsing server output is bad practice? How in the world did you > reach that ov

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

The problem with the code is that different web servers will spit out different HTML for a directory listing. It works for CrossWire & I stopped at that. There is probably a better way of doing it all, but I have up at that point cause my c++ skills are way too rusty & I'd prefer to rewrite it a

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

On Wed, Jun 26, 2013 at 8:21 AM, Jaak Ristioja wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > The greatest bug here is that it tries to parse the webserver > directory listing output (which is what I think it does). > > V E R Y V E R Y B A D P R A C T I C E ! ! ! > Parsing

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The greatest bug here is that it tries to parse the webserver directory listing output (which is what I think it does). V E R Y V E R Y B A D P R A C T I C E ! ! ! On 26.06.2013 16:17, Jaak Ristioja wrote: > Ok, the crash is caused by a NULL

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok, the crash is caused by a NULL pointer dereference, because pBufRes = (char *)findSizeStart(pBuf); might return NULL after which pBuf = pBufRes; and pBuf++; pBuf = strstr(pBuf, " This might not be directly related, but looking at curlht

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

Having contributed to the http code a while ago, I know that it worked for some httpd servers and not for others because of the way that file listings worked over http... In the end, I only use the http code with the official CrossWire repos & force the use of the ftp code for other repos in ord

Re: [sword-devel] installmgr (and xiphos) crashes (svn 2831)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This might not be directly related, but looking at curlhttpt.cpp, the line: sprintf(possibleName, "%.*s", possibleNameLength, pBuf); Is a potential buffer overflow, because the possibleName buffer is 400 bytes, but possibleNameLength is not checked

Re: [sword-devel] InstallMgr question

Thanks for that info, Troy. I thought it looked like it assumed a single thread. However, I thought it probably was designed with multi-thread in mind. No problem, I shall queue downloads, as that probably makes more sense on a hand-held device. ;) While we're on renaming things, osisruby.cpp

Re: [sword-devel] InstallMgr question

Hey Nic, Thanks for the reminder about the name change. I just checked in a fix for this. While doing this rename, I saw things in the code which look like they depend on installModule being single threaded, like setting a single RemoteTransport parameter in InstallMgr to the most recent so

Re: [sword-devel] InstallMgr

New Zealand. Never heard of Detica until now. What brought on that question? Robert. On 02/11/10 09:16, Chris Burrell wrote: Not working in the UK at Detica are you? Just wondering... Chris On 1 November 2010 19:4

Re: [sword-devel] InstallMgr

Not working in the UK at Detica are you? Just wondering... Chris On 1 November 2010 19:42, Robert Hunt wrote: > Actually, I had tried it with sudo with exactly the same result. > > But it seems that my modules are in .sword. What determines where they go? > (I would have originally used Xiphos

Re: [sword-devel] InstallMgr

Actually, I had tried it with sudo with exactly the same result. But it seems that my modules are in .sword. What determines where they go? (I would have originally used Xiphos to install them.) Thanks, Robert. On 01/11/10 23:16, Troy A. Griffitts wrote: Your modules are likely installed to

Re: [sword-devel] InstallMgr questions...

Dear Nic, Have a look at the c-tor to InstallMgr which takes a StatusReporter object. You can pass your own status reporter subclass to this to report status to your user however you'd like. Here is a simple example (not checked for syntax): class MyStatusReporter : public StatusReporter { priv

Re: [sword-devel] InstallMgr excess-of-remembrance problem

Yup, never mind, the problem was that Xiphos was not properly informing InstallMgr of a removal. We do some management of InstallMgr.conf because we also include local directory sources in it, so I've fixed the problem internally. There was a bit of difficulty because clearSources() didn't remove

Re: [sword-devel] InstallMgr excess-of-remembrance problem

Hey Karl, Ok, let's see if we can nail this one down. I need a little more info on the: Karl Kleinpaste wrote: > - Delete mine. step. Are you removing your personal repo from the InstallMgr::sources man and then using the InstallMgr::saveInstallConf method to write out the .conf file, or are y

Re: [sword-devel] InstallMgr ftp difficulty

Three weeks ago, I mentioned having trouble in a NAT'd VirtualBox VM with trying to do module installation. There is a new VirtualBox release, 3.0.4, which corrects this problem. It was broken since 3.0.0. From their ChangeLog: | NAT: fixed passive ftp access to host server (bug #4427)

Re: [sword-devel] installmgr completely failing

Greg Hellings writes: > You could always try manually creating it, see if that's the issue? > It's trying to install there, but if there is no .sword directory, it > might just silently fail. No, you misunderstand. ~karl/.sword exists. The find command looks for anything there that isn't owned

Re: [sword-devel] installmgr completely failing

On Fri, Jul 17, 2009 at 8:39 AM, Karl Kleinpaste wrote: > Greg Hellings writes: >> I haven't tried recently, but when I've used the command-line tool >> from in OS X before, I very frequently will run into an issue where >> the install directories are all under the ownership of root. > > "find .sw

Re: [sword-devel] installmgr completely failing

Greg Hellings writes: > I haven't tried recently, but when I've used the command-line tool > from in OS X before, I very frequently will run into an issue where > the install directories are all under the ownership of root. "find .sword ! -user karl" has empty output. ___

Re: [sword-devel] installmgr completely failing

Karl, I haven't tried recently, but when I've used the command-line tool from in OS X before, I very frequently will run into an issue where the install directories are all under the ownership of root. There doesn't seem to be any reason for how they end up owned by root, but installmgr doesn't s

Re: [sword-devel] InstallMgr ftp difficulty

> Karl Kleinpaste wrote: > > > Trying to refresh from ftp.bible.org fails; it happens to hang Xiphos > > forever. Trying a command line ftp program, I can get logged in, but > > any commands are rejected with "500 I won't open a connection to > > 10.0.2.15 (only to 71.206.198.112)", the latter of

Re: [sword-devel] InstallMgr ftp difficulty

Karl Kleinpaste wrote: > Trying to refresh from ftp.bible.org fails; it happens to hang Xiphos > forever. Trying a command line ftp program, I can get logged in, but > any commands are rejected with "500 I won't open a connection to > 10.0.2.15 (only to 71.206.198.112)", the latter of which is my

Re: [sword-devel] InstallMgr ftp difficulty

I can not help you, but have noticed that using VB in NAT has been pretty odd and difficult. I certainly failed to make it work in the way I wanted on a number of occasions. Maybe you have more luck by creating a virtual network card (not sure what the correct term is) whose IP is dependent on on

Re: [sword-devel] InstallMgr

Greg Hellings wrote: This thread seems to be of the mind that perhaps the module should always be zipped and not expanded on disk. I believe that was Eeli's feeling. My feeling, and it sounds like the feeling of several others is that the actual representation on the server's end is less impo

Re: [sword-devel] InstallMgr

On Fri, May 15, 2009 at 7:18 AM, DM Smith wrote: > > On May 15, 2009, at 4:28 AM, Manfred Bergmann wrote: > >> >> Am 15.05.2009 um 05:38 schrieb Greg Hellings: >> >>> On Thu, May 14, 2009 at 11:29 PM, Matthew Talbert >>> wrote: > > Does it require a difference (for the C++ front ends) to

Re: [sword-devel] InstallMgr

Matthew Talbert wrote: Xiphos can produce GenBook modules as well, or additional personal commentaries. Of course, we provide a handy function inside Xiphos to zip up any module :) ... And if this is generally useful for all frontends, why not put it into the library? Or into a small command

Re: [sword-devel] InstallMgr

On Fri, May 15, 2009 at 10:15 AM, Peter von Kaehne wrote: > Eeli Kaikkonen wrote: >> However, it already requires some >> nous to create a module and put it to some file system location, so >> zipping it and creating the (g)zipped file of the .conf files isn't a >> large step. I wonder if there ex

Re: [sword-devel] InstallMgr

Eeli Kaikkonen wrote: > However, it already requires some > nous to create a module and put it to some file system location, so > zipping it and creating the (g)zipped file of the .conf files isn't a > large step. I wonder if there exist such people who can create a sword > module but can't zip it.

Re: [sword-devel] InstallMgr details.

> Short term for SWORD, that is likely to remain an important difference. > Long term, either a local repo just returns "OK, done, nothing changed" > when asked to refresh, or you can rethink whether this is really needed... If local sources were really handled as the others were, then a refresh w

Re: [sword-devel] InstallMgr details.

> Remote repositories have concepts like 'refresh from remote source' (apt-get > update) > > Local repositories usually aren't 'entered' in a list by a user, though I > suppose they could be if it was useful.  Practically there is usually 1 > local source (a CD or USB drive) and the user can Browse

Re: [sword-devel] InstallMgr

On May 15, 2009, at 4:29 AM, Peter von Kaehne wrote: Eeli Kaikkonen wrote: 2. We need to support http. 3. We don't need to support the old, standard non-zipped directory structure with http because it's not needed for backwards compatibility. I think Troy's argument is right for module li

Re: [sword-devel] InstallMgr

On May 15, 2009, at 4:28 AM, Manfred Bergmann wrote: Am 15.05.2009 um 05:38 schrieb Greg Hellings: 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:

Re: [sword-devel] InstallMgr

Peter von Kaehne wrote: Eeli Kaikkonen wrote: 2. We need to support http. 3. We don't need to support the old, standard non-zipped directory structure with http because it's not needed for backwards compatibility. I think Troy's argument is right for module libraries, created by people who do

Re: [sword-devel] InstallMgr details.

Am 15.05.2009 um 06:58 schrieb Troy A. Griffitts: To understand the design decisions for InstallMgr, you have to have a basic understanding of the SWORD API: Libraries of modules are exposed as SWMgr objects. An SWMgr object can be easily created from a local path: SWMgr localLibrary("/path

Re: [sword-devel] InstallMgr

Eeli Kaikkonen wrote: > 2. We need to support http. > > 3. We don't need to support the old, standard non-zipped directory > structure with http because it's not needed for backwards compatibility. I think Troy's argument is right for module libraries, created by people who do not have much nous

Re: [sword-devel] InstallMgr

Am 15.05.2009 um 05:38 schrieb Greg Hellings: 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

Re: [sword-devel] InstallMgr

Am 15.05.2009 um 05:11 schrieb Greg Hellings: Is this a basic idea of how it could/should work? Or do we want it to work with some internal inclusion of times when cURL isn't available and we've had to fall back to ftplib? I think you'll fall into problems there and, for any such system, it w

Re: [sword-devel] InstallMgr

Troy A. Griffitts wrote: On top of that, we may add what I've been labeling as CACHING / OPTIMIZATION mechanisms to make downloading quicker, but these will require the content providers be more savvy, possibly implement cron jobs to zip up folders, etc. But these mechanisms will be optiona

Re: [sword-devel] InstallMgr details.

Troy A. Griffitts wrote: > 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 remote source' > (apt-get update) Short term for SWORD, that is likely to remain an importa

Re: [sword-devel] InstallMgr

Troy A. Griffitts wrote: > Am I helping explain my reasoning? Yes, I think you do. Wrt HTTP repositories - this is a valid need. Our church has cheap hosting space which uses its ftp server only to upload stuff for the website. There is no anonymous ftp. Nor is there any way i know of of making s

Re: [sword-devel] InstallMgr details.

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

Re: [sword-devel] InstallMgr details.

"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

Re: [sword-devel] InstallMgr

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

Re: [sword-devel] InstallMgr

> 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

Re: [sword-devel] InstallMgr

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

Re: [sword-devel] InstallMgr

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

Re: [sword-devel] InstallMgr

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

Re: [sword-devel] InstallMgr

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

Re: [sword-devel] InstallMgr

> 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

Re: [sword-devel] InstallMgr

> 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 ___

Re: [sword-devel] InstallMgr

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

Re: [sword-devel] InstallMgr

> >> 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

Re: [sword-devel] InstallMgr

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

Re: [sword-devel] InstallMgr

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

Re: [sword-devel] InstallMgr

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

Re: [sword-devel] InstallMgr

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

Re: [sword-devel] InstallMgr

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/

Re: [sword-devel] InstallMgr

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

Re: [sword-devel] InstallMgr

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

Re: [sword-devel] InstallMgr questions

On Mon, Apr 21, 2008 at 1:19 PM, Chris Little <[EMAIL PROTECTED]> wrote: > Adding to what others have said, I'll note that the ZIPs are not > reliably up to date. They are only updated by the JSPs after someone has > attempted to download an out of date ZIP of the same type (raw presumably). > >

  1   2   >