[jsword-devel] Resource

Joe Walker jsword-devel@bibletechnologieswg.org
Tue, 13 Aug 2002 22:48:12 +0100


I'm not 100% sure of all that you are suggesting.
I do think that getting rid of double /s is a good idea. I don't think that
swapping URL for File is justified (or simple) right now, and I'm not
convinced that we need to swap / for File.SEPARATOR in URLs, so unless you
are wanting to do either of the latter, I propose that you check it in, or
post a file or something and I'll take a look, and then we'll go from there.


> -----Original Message-----
> From: owner-jsword-devel@crosswire.org
> [mailto:owner-jsword-devel@crosswire.org]On Behalf Of Keith Ralston
> Sent: 13 August 2002 19:31
> To: jsword-devel@bibletechnologieswg.org
> Subject: RE: [jsword-devel] Resource
> Try removing versions from your target path and running.  I don't have any
> problems once I figured out what to name the ZIP file and where
> to place it
> before building.  In the code that looks around for a versions
> directory, we
> convert the URL to a File.  This is where the type of slash matters.  I
> modified the Resource class to look for File.separator in the path string.
> NetUtil adds a File.separator when postpending the versions directory.  If
> the string already has a slash (regardless of type) at its end, another is
> added.  I modified this to look for a File.separator and not add
> a slash if
> one already exists.
> I understand what you are saying about the URL specification.  I have also
> read it.  I am not denigrating Microsoft.  I wish I had achieved their
> degree of success in both business and software development.  I am merely
> looking at what I see on my computer.  The URL object of type "file" on
> Windows 2000 Server contains a Microsoft type slash.  On some of
> the string
> manipulations (NetUtil.lengthenURL,) the method returns several types of
> slashes.  I have not worked with URL enough on Windows to know if
> Java just
> goes with the flow and recognizes both types of slashes.  I know that
> Windows Explorer and Internet Explorer tend to be very forgiving
> and let you
> use either type of slash.
> If you would prefer that I not check this in to source.  I don't mind.  I
> can keep it local and run it here.  I am just taking a practical approach
> and dealing with what I see happening in this environment.  The changes
> should not affect how the code works in other operating environments.
> Again, I only made changes where we were already using File.separator, or
> where we were using the File object derived from the URL object.
> This brings to mind the question I posted previously: Do we want to access
> the versions as URLs?  Can you see a time when the structure of the engine
> would work well running searches over the network?  I.e., we have the code
> that performs the search on one machine and the actual text for
> the version
> on another machine.
> I can see downloading the text to the machine performing
> searches.  In this
> scenario, if the machine cannot find the version text, the
> software can look
> on the network and download the text.  Then the objects performing the
> searches would run against files local to themselves.
> Let me know what you have in mind.  I'll hold off checking
> anything in until
> I hear back from you.  I will start working on the filters (Sword
> term) for
> the versions stored on the Sword servers.
> Keith
> -----Original Message-----
> From: owner-jsword-devel@crosswire.org
> [mailto:owner-jsword-devel@crosswire.org]On Behalf Of Joe Walker
> Sent: Tuesday, August 13, 2002 12:59 PM
> To: jsword-devel@bibletechnologieswg.org
> Subject: RE: [jsword-devel] Resource
> Hi,
> Keith wrote:
> > Which separator used is a function a several things depending on
> > how you are
> > accessing the URL: protocol, implementation and OS.  All my file:
> > URLs have
> > a Windows separators on Win2k Server.
> I dont think this is the case. file: URLs *should* only contain /
> and there
> is a method of translating C: into C| if I recall correctly, and
> to be fair
> to MS these methods do work. However IE also uses (and prefers)
> to use : and
> \ in file URLs, in fact it even lets you drop the file: part too. However
> these are all extensions to the spec, I think.
> So this file:///C|/windows/blah.dll is more correct than
> file://c:\windows\blah.dll
> > I'm now using XP, and it seems to work OK for me. Is it failing for you?
> > If your environment is properly configured, it works.  Remove
> the versions
> > directory(ies) and you should see that it looks in some
> > interesting places.
> Everything is working fine for me.
> Joe.