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 <ransom1...@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.
In Him,
DM
_______________________________________________
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
