[sword-devel] InstallMgr

[Greg Hellings]

On Fri, May 15, 2009 at 7:18 AM, DM Smith <dmsmith at crosswire.org> 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 <ransom1982 at gmail.com>
>>> 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 imagine that the interface between SWORD and the
>>>>> application would be identical in all those cases -- all the
>>>>> application needs is to retrieve the information and provide a way for
>>>>> the user to input new locations.  I get the impression from your
>>>>> previous messages that the front ends will need to change when you add
>>>>> HTTP support to the library then front ends will need to add another
>>>>> portion to their install manager that allows the user to create HTTP
>>>>> install locations separate from FTP or file:// ones -- is that the
>>>>> case?
>>>>
>>>> The interface is different for local installations than it is for FTP
>>>> installations. For local installations, you must create an SWMgr that
>>>> points to the location of the modules to be installed, then you can
>>>> get a listing of the modules available (but you must be careful to not
>>>> augment the path with HOME/.sword or other locations or it won't
>>>> work). For FTP, it also creates an SWMgr, but it does it itself, and
>>>> exposes the list of available modules. This difference is why Xiphos
>>>> couldn't really use a local source until 3.0. No one had figured out
>>>> how it was supposed to work :)
>>>
>>> I see -- it seems to me that method doesn't take nearly as much
>>> abstraction as it should.  I should imagine that a client application
>>> could simply create an InstallMgr object and pass it the string that
>>> it ought to search for.  If the string is file://, ftp://, http://,
>>> cifs:// or \\host or whatever shouldn't much matter in my mind.  The
>>> URI should be parsed and the proper actions taken within InstallMgr.
>>
>> Yeah. I second that.
>> For any install source location InstallMgr should be used and it should be
>> able to handle any URL.
>
> Not a particular response to this, but the thread in general:
>
> With JSword, internally we use the URI class to represent every file object
> independent of its location. We do this for everything. It can even be a
> file within a zip or a jar. We have helper classes to convert that to a
> stream. And we have the notion that a named file can be along a URI path.
>
> It was not easy to permeate JSword with this, but the payoff was immense.
>
> That said, some URIs (or URLs) need additional information that is not
> stored in it to work. It handles user name and password well enough, but it
> needs extra help with HTTP proxies and in the case of FTP passive and mode
> settings, to name a few.
>
> But using a URI implies that a thing at the other end is atomic. A pdf, an
> image, a zip, ..... Even a web page is atomic.
>
> But a SWORD module is not atomic in its representation. I think this is what
> several have suggested that users think of it as and how we should treat it.
>
> In Troy's all caps, he was trying to get across (Troy, correct me if I'm
> wrong) that he feels strongly that the minimum entry for a SWORD repository
> is its current expanded disk representation. There are two supported ways to
> work with that: FTP and local. He also said that HTTP when added will work
> with that layout. Zips and mods.d.tar.gz are merely cached representations
> of that and thus unreliable.
>
> 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 important to the application developer than
having the install manager in the library handle all the different URL
protocols invisibly to the application developer.

In an out-of-stream e-mail to me, Troy seemed to indicate that he does
expect the InstallMgr to do exactly that and the application level
changes he perceives as important are simply in the user input design
when a user is inputting the connection information.  I presume he
means that an application might have a drop-down box to select FTP or
FILE and it would need to add an HTTP element to that.  If I
understood his latest email correctly, it sounds like he plans to do
exactly what we are all hoping -- force no additional work on the
application developer, unless they have forced it on themselves by
means of their source input method.  Did I understand that correctly,
Troy?

--Greg

>
> In Him,
>        DM
>
>
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>