[jcifs] SMB URL Parsing
Michael B. Allen
miallen at eskimo.com
Sat Sep 28 05:53:03 EST 2002
On Fri, 27 Sep 2002 14:37:23 -0500
"Christopher R. Hertel" <crh at ubiqx.mn.org> wrote:
> 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.
Not really. The URL class is quite pervasive. We would really be building
SmbFile and associated apparatus around it. All the state used to identify
a resource will be encapsulated in this class which is not in our package
and it's "final" meaning it cannot be extended.
> 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
A program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes the potential for it to be applied to tasks that are
conceptually similar and more importantly to tasks that have not
yet been conceived.
More information about the jcifs