[jcifs] SMB URL Parsing

[Christopher R. Hertel]

On Fri, Sep 27, 2002 at 03:14:21PM -0400, Michael B. Allen wrote:
> On Fri, 27 Sep 2002 13:29:53 -0500
> "Christopher R. Hertel" <crh at ubiqx.mn.org> wrote:
> 
> > On Thu, Sep 26, 2002 at 05:12:05AM -0400, Michael B. Allen wrote:
> > > Well  without  much  effort the standard Java 2 java.net.URL class seems to
> > > parse  most everything ok. I think we're just going to have to require Java
> > > 2  and be done with it. BSD was the hold up IIRC and I think they said they
> > > run Java 2 natively now. 
> > 
> > Actually, it was embedded systems and Personal Java implementations.  I 
> > had some trouble with the Jeode system running Linux on the Sharp Zaurus 
> > palmtop (but I think the latter had to do more with Personal Java than 
> > with the rev level).
> > 
> > jCIFS is modular enough, though, that folks should be able to write a 
> > class to handle any missing functionality if they want to port to 
> > something small.
> 
> Not if we make this change. The URL will be *the* SMB URL parser. We
> have to use the Java 2 URL because the older one doesn't parse all the
> fields. Once we move that's it. There's no turning back.

We can't separate out the SMB URL parsing into its own class (descendent
from the Java class) that can be replaced?  I'm imagining an SMBURL
object, based on an SMBURL class, of course.  The user's option would be
to write a different SMBURL class to replace the missing one if they are
porting to an older or more stripped-down platform.

I wrote a Q&D SMB URL parser in C that seems to be working quite well.
It's brute-force, but perhaps we could use that as a template.

Another naïve question:  Does the older parser simply miss fields or does
it get them wrong?  If it only fails to fully parse, then we could
probably create a descendant type that completes the task.  The only 
problem I'm imagining is that the Java built-in might decode escapes on 
its own, which would mean that we would lose the escapes before we were 
done parsing (that would be bad).

-- 
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org