[jcifs] SMB URL Parsing

[Michael B. Allen]

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.