Re: [sword-devel] RusSynodal in experimental
Sorry but text source for RusSynodal changed without reflecting it in conf or rss. Now it is Church-Slavonic translation and not Synodal. It would be nice to have Church-Slavonic translation but after we have no problems with Synodal. In my meaning it also should use slavic character set. Also OT content is missed after 2Macc. I cant understand why RusSynodal was in broken state within nine months and now there are untested releases. So i want become a part of team and help with russian-related direction of Sword Project. ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
[sword-devel] CrossWire lacks a Content Management System
No doubt this topic may have been discussed in the past, but even with my limited experiences of IT, it seems to be the case that CrossWire lacks an overall Content Management System. Far too much of what we do is ad hoc and the result is that links in the wiki pages as well as the main website swiftly become out of date. We have an ftpmirror that does not keep track of updates to scripts and other software tools that we host. The result for users, especially newcomers, can be very frustrating. Though this might read like a gripe, please understand that I'm trying to be constructive. I'm putting myself in the place of a user, and looking to those of you who are far more experts in IT than I'll ever hope to be (at my age) to put in some effort to try and improve the total experience that we want our customers to have. Yours in Christ's service, David Haslam -- View this message in context: http://sword-dev.350566.n4.nabble.com/CrossWire-lacks-a-Content-Management-System-tp3029843p3029843.html Sent from the SWORD Dev mailing list archive at Nabble.com. ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
[sword-devel] HTTP Transport support (was: Remote Module Repository Wiki)
On 11/06/2010 04:36 AM, Nic Carter wrote: I initially submitted a patch for HTTP parsing, but it only works for CrossWire and not for the Bible.org nor for the Xiphos repos, and I have no intention of modifying the parsing code even more in order to try to support more web servers! :) thanks for the patch! Yeah, surprisingly even FTP directory parsing is painful. Even libCURL doesn't have an FTP directory listing parse function. I couldn't believe that when I wrote the FTP code! We found a portable library call ftpparse which parses directory listings for us. When doing the HTTP transport, I was hopeful we might find an httpdirparse or something :) But no such luck, as of yet. We were talking on #sword the other day about how odd it is that there is no w3c standard for the obvious use case: Browse a hierarchy of folders+resources and retrieve some. I brought this up with a frequent member of w3c committees and he suggested we develop a silly stupid minimal schema to represent a resource tree and a) submit it for w3c approval, and b) submit updates for Apache and IIS to update their Folder Index listings to comply to the proposal. e.g., something like, ?stylesheet href=apache_look_and_feel.css? folder name=My Documents resource type=file mimetype=application/msword name=War Of the Worlds.doc/ /folder Then, end users wouldn't notice a difference, and we could have a standard to easily parse. As always, you know who is always in the details: attributes for permissions, mtime...; do you make the whole subdirectory hierarchy available from a directory request, or just the immediate children... Anyway, we can dream of a bold new Internet where everything is standardized and straightforward for developers... :) ah. Troy ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Remote Module Repository Wiki
Hi Nic, Thanks for the feedback. I'd like some clarification though. I really am trying to make an honest assessment of where we are and need to go in the future and note the negative feedback from frontend developers, but haven't been able to quantify what exactly that negative feedback is. Help me understand your exact objections and how an alternative scheme solves that issue. Questions below: On 11/06/2010 04:48 AM, Nic Carter wrote: I was going to download the mods.d.tar.gz file (over HTTP) and use that for moduleinformation. Then download the ZIP of the module over HTTP. If a repo doesn't have the zip folder (or the mods.d.tar.gz file), then I would either have a fall-back to use the normal InstallManager, or perhaps I'd just say that PocketSword wouldn't support that repo. But after a year of PocketSword doing things the right way, I've decided to take the JSword approach and hope that doesn't cause too many issues... :( :) OK, This is vital for me to understand your experience. I presume the right way you speak of above is simply using the InstallMgr API. Why are you unhappy with the InstallMgr API? Does it not work? Is it too hard to use? You mention speed, below... my personal tests on an iOS device show that accessing the CrossWire repo via FTP is reasonably slower than accessing it via HTTP. Really? I wouldn't have expected this at all. I want the reasonably large performance gains that I can gain from simply switching protocols! :) Yes, indeed. This is a very valid concern. Let me ask, what FTP plugin were you using, ftplib or curl? I am wondering if it might be the difference in plugin. I recently switched BibleCS's InstallMgr GUI to use the ftplib system instead of CURL and surprisingly seem to have less troubles and more responsiveness. There is still one major shortcoming of ftplib-- it cannot download directly to a buffer for a directory listing, we use a temporary file-- but I hope to resolve that in the next day or two. Speed is a very real and practical concern and if we have a problem, we need to resolve it. On 06/11/2010, at 1:35 AM, Troy A. Griffitts wrote: 2) The viral ability END USERS to share modules. If I can, for example, ouse the builtin installer of my SWORD software on my Android device to install my important modules o then plug it into my friends computer and install modules FROM my android device WITHOUT ANY PREPARATION othen from his computer right-click on the top module library folder and Share as... 'SWORD Modules', o then go to any computer on the network and install modules from that SWORD Modules share, othen install FileZilla on one of those computers and let anyone over the Internet install Bibles from that location, othen point IIS or Apache to that location (http transport needs work but is on the way-- more talk below) ... distribution of Bibles then becomes viral. It is spontaneous. No preparation. I have my library of books I use regularly with me and if someone wants one of my books, then they can install straight from my library. I don't think this should hold back usability in other ways. In what way does usability relate to storage format or network transport? I would rather that we provided some other functionality (or tool) to make this easy for end users to do, rather than make this mean that the final install of a module is a complete install source. I love the concept, but I think that your example is something that 0.0001% of users would be interested in, given the nerdery required to know how to do that! ;) I don't understand the suggestion or the nerdiness of the current method. We (the engine) does provide install functionality and we (frontend developers) do provide a tool that makes this easy for end users. Users already know how to install modules in their favorite software. The user wishing to install follows their familiar procedure to install. When prompted from which Remote Repository they would like to install, the user simply clicks a 'browse to local folder' button. I believe most frontends already support this for installing from a CD. BUT I liked the suggestion made in another post of having a prepare for distribution or publish menu item that would then automatically prepare a module (or selection of modules) for distribution. :) Use that menu item as step one, and then you can proceed through that list of examples that Troy has. As an added extra bonus, you get to specify the location to which to Save the module/s ready for distribution. That way a user doesn't even need to know where her/his modules are installed to, but instead can say desktop (yes, I'm using the LCD of a user who does everything on their desktop!) and then easily find that location share that folder. :) (or it could be specified as a network drive, for easy access to everyone on the network, etc.) The prepare
Re: [sword-devel] Remote Module Repository Wiki
Sure, of course I agree with Karl. If we decide on expanding (or contracting) the format of an installation repository, the InstallMgr class in the engine will operate against that new definition and frontend developers already using InstallMgr shouldn't need to change any code. On 11/05/2010 09:48 PM, Karl Kleinpaste wrote: Matthew Talbert ransom1...@gmail.com writes: Perhaps this isn't any better, but you can see the entire list here: http://ftp.xiphos.org/sword/zip/ Of course, it doesn't use very descriptive names, but it slightly more user friendly than opening the tar.gz. Well, again, I don't want a _human_ cracking open mods.d.tar.gz; I want the app's installer to do it, and display a nice set of available modules with descriptions and sizes and whatnot. I think InstallManager should be taught to do it all, just the way it does for FTP. ___ sword-devel mailing list: sword-devel@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@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] CrossWire lacks a Content Management System
I agree that this is a serious shortcoming of the overall project. I would be willing to pitch in some experience in this area. If the interested and or responsible parties would like perhaps we can get a discussion going. Depending on the direction I may be willing to lend a hand with coding and implementation. I'll keep an eye on this thread. Caleb On Sat, Nov 6, 2010 at 12:49, David Haslam d.has...@ukonline.co.uk wrote: No doubt this topic may have been discussed in the past, but even with my limited experiences of IT, it seems to be the case that CrossWire lacks an overall Content Management System. Far too much of what we do is ad hoc and the result is that links in the wiki pages as well as the main website swiftly become out of date. We have an ftpmirror that does not keep track of updates to scripts and other software tools that we host. The result for users, especially newcomers, can be very frustrating. Though this might read like a gripe, please understand that I'm trying to be constructive. I'm putting myself in the place of a user, and looking to those of you who are far more experts in IT than I'll ever hope to be (at my age) to put in some effort to try and improve the total experience that we want our customers to have. Yours in Christ's service, David Haslam ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] CrossWire lacks a Content Management System
On 11/6/2010 3:49 AM, David Haslam wrote: We have an ftpmirror that does not keep track of updates to scripts and other software tools that we host. What you're referring to here (linking directly to the SVN versions of perl scripts that we maintain) would be akin to replacing every single binary we provide with nightly builds. We don't need to be publishing an SVN commit that I made just over 12 hours ago when it hasn't even undergone testing beyond one or two USFM docs. The perl scripts change seldom and slowly, and they are used and tested by very few people. --Chris ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] CrossWire lacks a Content Management System
I agree with Chris on this issue. CMS has been a debated topic in the past. From my conservative position, you must give a specific, real world problem we currently have which is not easily solved with our current infrastructure, or a real world benefit we are currently lacking because we do not have something labeled a CMS, for us to even consider committing to the maintenance of another framework. Troy On 11/06/2010 12:22 PM, Chris Little wrote: On 11/6/2010 3:49 AM, David Haslam wrote: We have an ftpmirror that does not keep track of updates to scripts and other software tools that we host. What you're referring to here (linking directly to the SVN versions of perl scripts that we maintain) would be akin to replacing every single binary we provide with nightly builds. We don't need to be publishing an SVN commit that I made just over 12 hours ago when it hasn't even undergone testing beyond one or two USFM docs. The perl scripts change seldom and slowly, and they are used and tested by very few people. --Chris ___ sword-devel mailing list: sword-devel@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@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] RusSynodal in experimental
Sorry, the update that was posted earlier wasn't intended to be published or downloaded by anyone, since I was still in the middle of testing (both it and the updated Windows InstallManager.exe). The current updates to the Synodal and OCS Elizabeth Bibles are tested and should be correct. On 11/6/2010 3:49 AM, Konstantin Maslyuk wrote: Sorry but text source for RusSynodal changed without reflecting it in conf or rss. Now it is Church-Slavonic translation and not Synodal. It would be nice to have Church-Slavonic translation but after we have no problems with Synodal. In my meaning it also should use slavic character set. I don't know what you mean by slavic character set. I can think of 3 ways to interpret that: 1) You might mean that you would like to see the original orthography, since it has been modernized in CSlElizabeth. We could add another OCS Bible in a non-updated orthography, but we don't have such a text currently. 2) You might mean that you would like to see it in an OCS-style font, like you'd see in older printed books. For that, you're free to change the font to any Unicode font. 3) You might mean that you would like to see the text written in the glagolitic script. We won't be offering that, except perhaps via transliteration, in the future. Also OT content is missed after 2Macc. 3Macc and 2Esd are not included in the Elizabeth Bible (at least not the version we have). I cant understand why RusSynodal was in broken state within nine months and now there are untested releases. So i want become a part of team and help with russian-related direction of Sword Project. Since there are only a few front ends that can support the Synodal versification, there isn't much need for the content to be updated. Nothing in the experimental repository is intended for day-to-day use by actual users, so it is a very low priority. --Chris ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
[sword-devel] Holman Christian Standard Bible
Hi, I was wondering if CrossWire had any plans to make a Holman Christian Standard Bible http://www.hcsb.org/ module available. Olive Treehttp://www.olivetree.com/store/product.php?productid=17422are making a version available free. Kind regards Martin ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] HTTP Transport support (was: Remote Module Repository Wiki)
Thanks for the long reply. :) It is frustrating that some things are designed really well and other bits are painful, like getting a listing of files... ok, so, I did take a quick look at my code and one way of fixing the Xiphos listing, for example, is by not trying to parse the file sizes. We could trust the module size provided in the module conf (which isn't always provided and is sometimes wrong!) and then simply have a total size indicator rather than have an indicator for each file downloaded in the module. I think that may also work for bible.org? Would be an option, and then we'd need to check to see if the file size returned by FTPTransport::getDirList() is zero, and if it is, use the total size provided by the module conf. But, I believe there is a way of telling the size of a file being retrieved via HTTP GET? hopefully we could use that as well? :) Anyway, just a quick thought. Of course, I'd prefer that we didn't try to parse a file listing like this . . . and would rather we used the mods.d.tar.gz file module ZIP files, but more on that in another email. :) Thanks, ybic nic... :) ps: I wouldn't be against someone submitting something to w3c, but I wouldn't be holding my breath for it to be implemented, let alone approved... :( :( On 06/11/2010, at 10:15 PM, Troy A. Griffitts wrote: On 11/06/2010 04:36 AM, Nic Carter wrote: I initially submitted a patch for HTTP parsing, but it only works for CrossWire and not for the Bible.org nor for the Xiphos repos, and I have no intention of modifying the parsing code even more in order to try to support more web servers! :) thanks for the patch! Yeah, surprisingly even FTP directory parsing is painful. Even libCURL doesn't have an FTP directory listing parse function. I couldn't believe that when I wrote the FTP code! We found a portable library call ftpparse which parses directory listings for us. When doing the HTTP transport, I was hopeful we might find an httpdirparse or something :) But no such luck, as of yet. We were talking on #sword the other day about how odd it is that there is no w3c standard for the obvious use case: Browse a hierarchy of folders+resources and retrieve some. I brought this up with a frequent member of w3c committees and he suggested we develop a silly stupid minimal schema to represent a resource tree and a) submit it for w3c approval, and b) submit updates for Apache and IIS to update their Folder Index listings to comply to the proposal. e.g., something like, ?stylesheet href=apache_look_and_feel.css? folder name=My Documents resource type=file mimetype=application/msword name=War Of the Worlds.doc/ /folder Then, end users wouldn't notice a difference, and we could have a standard to easily parse. As always, you know who is always in the details: attributes for permissions, mtime...; do you make the whole subdirectory hierarchy available from a directory request, or just the immediate children... Anyway, we can dream of a bold new Internet where everything is standardized and straightforward for developers... :) ah. Troy ___ sword-devel mailing list: sword-devel@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@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Remote Module Repository Wiki
On 06/11/2010, at 10:42 PM, Troy A. Griffitts wrote: I was going to download the mods.d.tar.gz file (over HTTP) and use that for moduleinformation. Then download the ZIP of the module over HTTP. If a repo doesn't have the zip folder (or the mods.d.tar.gz file), then I would either have a fall-back to use the normal InstallManager, or perhaps I'd just say that PocketSword wouldn't support that repo. But after a year of PocketSword doing things the right way, I've decided to take the JSword approach and hope that doesn't cause too many issues... :( :) OK, This is vital for me to understand your experience. I presume the right way you speak of above is simply using the InstallMgr API. Why are you unhappy with the InstallMgr API? Does it not work? Is it too hard to use? You mention speed, below... The right way is by directly plugging into the InstallMgr API and getting it to do all the work. :) In order to get it to work, I've made a couple of rather minor changes, but that's not an issue at all, and I'm very happy to maintain my own set of patches required to get the SWORD lib working properly on an iOS device. :) (or, as an aside, I could submit some patches that have #defines for iOS, but I'm not too fussed. Perhaps they would be of interest if someone wanted to use the C++ lib for Android, but I'm not sure.) I want to switch to using HTTP only in PocketSword. Mobile phone carriers are rather horrid to deal with. My old carrier here in Australia had transparent proxies and all sorts of horrid things! Other carriers do other evil things, as well. And I am fairly certain some of them don't have FTP in the common use-set scenario for their users, even in this day and age of wireless internet, and so don't care if it works very well or not... :( I have observed first hand some annoying things with different carriers here -- so perhaps the US is ok where you only have one carrier for the iPhone hence only one set of horridness to deal with? ;) But, HTTP is so commonplace that it's harder to break it. I have yet to add proper proxy support into PocketSword, but that is high up on the list. But given that I'm thinking about rewriting the download code for PocketSword, I've put it off and I'll do both at once? BTW, I think the InstallMgr API works fairly well and is extremely easy to use. :) When I started work on PocketSword (I was helping Ian out at first), I tackled the downloading of modules as my first task and I found it fairly easy to figure out how to get it to work. :) my personal tests on an iOS device show that accessing the CrossWire repo via FTP is reasonably slower than accessing it via HTTP. Really? I wouldn't have expected this at all. This may have to do with phone carriers? altho, I'm fairly certain I tested this over WiFi as well... In my experience, it feels like the internet is moving away from FTP and using HTTP for everything? Just like HTML is now being used for many different things that it was never intended to be used for... ;) But, firewalls and proxies often screw with FTP much more than HTTP and many orgs/companies simply block FTP, hence people moving to HTTP to get around those issues. :( I want the reasonably large performance gains that I can gain from simply switching protocols! :) Yes, indeed. This is a very valid concern. Let me ask, what FTP plugin were you using, ftplib or curl? I am wondering if it might be the difference in plugin. I recently switched BibleCS's InstallMgr GUI to use the ftplib system instead of CURL and surprisingly seem to have less troubles and more responsiveness. There is still one major shortcoming of ftplib-- it cannot download directly to a buffer for a directory listing, we use a temporary file-- but I hope to resolve that in the next day or two. Speed is a very real and practical concern and if we have a problem, we need to resolve it. I see you just committed that change. :) I have only tested with curl -- as that is the only way to get HTTP downloading working. :) I never had the option to use ftplib, as downloading to a temporary file under iOS is NOT a good idea... :( I could test with ftplib, but given the other objections I have to FTP (*sigh* phone carriers *sigh*), I'm hoping to avoid FTP. :( On 06/11/2010, at 1:35 AM, Troy A. Griffitts wrote: 2) The viral ability END USERS to share modules. If I can, for example, o use the builtin installer of my SWORD software on my Android device to install my important modules othen plug it into my friends computer and install modules FROM my android device WITHOUT ANY PREPARATION o then from his computer right-click on the top module library folder and Share as... 'SWORD Modules', o then go to any computer on the network and install modules from that SWORD Modules share, o then install FileZilla on one of those computers and let anyone over the
