[sword-devel] Remote Module Repository Wiki

[Troy A. Griffitts]

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,
>> 
>> o	use 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 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 Internet install Bibles from that location,
>> o	then 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 for distribution" is currently unnecessary.  I hope I'm not
being daft and missing something, but how can adding a step improve user
experience?  unless...

Others have voiced that users might not want to expose their entire
module set, so I like your idea slightly modified to "Install Subset of
Books To ..."feature for these users, but for your objection, a simple
"Show library location" or even "Open library location" which would
launch their file explorer to the library path, would be cool.


> Anyway, just some more thoughts.  Sorry they're coming so much later
>  than when these were posted -- a fun consequence of living in Oz.
> :)

No, no!  They are extremely valuable.  I need to hear real world
feedback on what works and what doesn't.  What is hard and what makes
your life easy.  Please keep the feedback coming.


> I could easily be persuaded to add an "export" feature to 
> PocketSword, which would work over WiFi or 3G (similar to the current
> way of manually installing a module from a ZIP file), so you could
> share modules on your device with friends.  Of course, this would
> need to be switched on manually, and wouldn't always be running in
> the background, so as to conserve battery!  But would be quite funky.
> :)  But given you need to press a button to switch it on, at that
> point I could get PocketSword to "prep" the selected modules for
> distribution.  :)

When you plug in an iphone, is the location where pocketsword installs
modules browseable from the hosting computer as USB Storage?  If so, you
already have the feature.

Are you suggesting that it takes a nerd to know where to browse to find
the books?   I can understand that.  And to solve that problem, I could
see an 'export' function be useful.  But wouldn't it be more useful to
have something like "Show PocketSword Library Location".  This solution
would prevent the unnecessary duplication of the entire library of books
simply because the installing user doesn't know where to browse.

Thanks again for the conversation.  Anyone who's made it this far in
this email, you must really care about the topic! :)

Troy