That Pesky URI Resolution Framework

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of
> Ken Treis
> Sent: Tuesday, January 23, 2001 12:54 AM
> To: [hidden email]
> Subject: [Swazoo-devel] That Pesky URI Resolution Framework
>
>
> Hi all,
>
> Long time, no Swazoo news.  Well, it's time to change that!
> I took an
> axe (I think it said "RB" on it) to the current URI resolution
> framework, and I came out with something that I think is:
>
> - more concise (once and only once)
> - clearer
> - more testable
>
> But I'm only one of the members of this group, so I certainly
> shouldn't
> have the final say.  That's why I've attached a parcel that all y'all
> can look at.  Here's a little history:
>
> I had gotten frustrated with the poor encapsulation of the resolution
> stream.  It bugged me that every resource had to take the
> responsibility
> for backing up the stream if it turned out that he (the
> resource) really
> couldn't respond to the request.  I spent several hours hunting down
> bugs like this.
>
> Another thing that bugged me was that all of our Resource
> tests had to
> advance the uriStream several places (3 to be exact) before
> they could
> ask a given resource to resolve the associated request.
>
> So I started out by trying to build an object that would
> encapsulate the
> act of URI resolution (Janko, this might start to sound
> familiar to you;
> I never looked at your WebResolver class, but I suspect it's
> similar).
> I ended up with something that uses a double dispatch.  There's an
> object called a URIResolution, and it has a class side method called
> #resolveRequest:startingAt:.  Here's an example of how it's used:
>
> HelloTest>>testResponse
>    |request response|
>    request := HTTPGet request: 'hello.html'.
>    response := URIResolution resolveRequest: request startingAt:
> resource.  "resource is an instance of HelloWorld with uriPattern
> 'hello.html'"
>    self assert: response code = 200.
>    self assert: request resourcePath size = 1.
>    self assert: request resourcePath first = 'hello.html'
>
> Basically, the act of resolving/responding is still a one-pass
> operation, but it's arbitrated by the URIResolution.  The
> URIResolution
> sends (helpResolve: self) to each resource, and each resource turns
> around and sends something like (resolveCompositeResource:
> self) to the
> URIResolution.
>
> One nice side effect of this protocol is that we no longer
> need any of
> those silly ServerRootIdentifier/RootIdentifier classes.  All of that
> information is tied up in the message protocol.  So I've
> turned all of
> the URIPatterns back into straight old strings.  It's simple
> again.  :)
>
> -=-=-=-
>
> Please take a look at this and tell me if you think I've lost
> it.  One
> downside is that you can't have resources that don't have a
> uriPattern
> (I broke the rules with the old Session stuff, but this
> framework made
> me give the CookieSessionResource its own uriPattern) without adding
> additional protocol to URIResolution.  Does that bother anybody?
>
> It seems that people did like the Session / ACL stuff, so I'm
> planning
> on rolling that all into SourceForge.  If people like this, too, I'll
> put them both into the code repository.
>
> On a more personal note, I'll be doing a lot of traveling
> over the next
> few months.  I'm back and forth between Walla Walla, WA and
> Medford, OR
> for Key.  They've lost all but one of their Software
> Engineers down in
> Medford, so I volunteered to travel down there and give the remaining
> soul a hand.  So if I don't respond to your emails very
> quickly, you'll
> know why (Joe, I'll get a response to you soon, I promise).
>
>
> Ken
>
>

> Don't have time to look over this now, but I'll take the opportunity to
> give a couple of updates.
>
> First, the Dolphin 4.0 port of Swazoo has been done for awhile, but every
> time I get a free moment I immediately get discouraged by CVS and haven't
> had enough time to tackle it properly.  If anyone needs the package let mem
> know and I'll mail it out.
>
> Also, I'm planning on attending Smalltalk Solutions in April.  Anyone else
> going to be there?  I'd like to catch Camp Smalltalk and I'm hoping that it
> might start early and/or continue later than the 3-day conference itself
> (and will probably need to make plans accordingly soon).  Unfortunately,
> I've sent mail asking to be added to the Camp mailing list twice and I
> still haven't received any traffic- is anyone planning to attend / have any
> information?  If there is a Swazoo presence there I'd love to join in!
>
> Thanks,
>
> Jerry Bell
> [hidden email]
>
> > -----Original Message-----
> > From: [hidden email]
> > [mailto:[hidden email]]On Behalf Of
> > Ken Treis
> > Sent: Tuesday, January 23, 2001 12:54 AM
> > To: [hidden email]
> > Subject: [Swazoo-devel] That Pesky URI Resolution Framework
> >
> >
> > Hi all,
> >
> > Long time, no Swazoo news.  Well, it's time to change that!
> > I took an
> > axe (I think it said "RB" on it) to the current URI resolution
> > framework, and I came out with something that I think is:
> >
> > - more concise (once and only once)
> > - clearer
> > - more testable
> >
> > But I'm only one of the members of this group, so I certainly
> > shouldn't
> > have the final say.  That's why I've attached a parcel that all y'all
> > can look at.  Here's a little history:
> >
> > I had gotten frustrated with the poor encapsulation of the resolution
> > stream.  It bugged me that every resource had to take the
> > responsibility
> > for backing up the stream if it turned out that he (the
> > resource) really
> > couldn't respond to the request.  I spent several hours hunting down
> > bugs like this.
> >
> > Another thing that bugged me was that all of our Resource
> > tests had to
> > advance the uriStream several places (3 to be exact) before
> > they could
> > ask a given resource to resolve the associated request.
> >
> > So I started out by trying to build an object that would
> > encapsulate the
> > act of URI resolution (Janko, this might start to sound
> > familiar to you;
> > I never looked at your WebResolver class, but I suspect it's
> > similar).
> > I ended up with something that uses a double dispatch.  There's an
> > object called a URIResolution, and it has a class side method called
> > #resolveRequest:startingAt:.  Here's an example of how it's used:
> >
> > HelloTest>>testResponse
> >
> >    |request response|
> >
> >    request := HTTPGet request: 'hello.html'.
> >    response := URIResolution resolveRequest: request startingAt:
> > resource.  "resource is an instance of HelloWorld with uriPattern
> > 'hello.html'"
> >    self assert: response code = 200.
> >    self assert: request resourcePath size = 1.
> >    self assert: request resourcePath first = 'hello.html'
> >
> > Basically, the act of resolving/responding is still a one-pass
> > operation, but it's arbitrated by the URIResolution.  The
> > URIResolution
> > sends (helpResolve: self) to each resource, and each resource turns
> > around and sends something like (resolveCompositeResource:
> > self) to the
> > URIResolution.
> >
> > One nice side effect of this protocol is that we no longer
> > need any of
> > those silly ServerRootIdentifier/RootIdentifier classes.  All of that
> > information is tied up in the message protocol.  So I've
> > turned all of
> > the URIPatterns back into straight old strings.  It's simple
> > again.  :)
> >
> > -=-=-=-
> >
> > Please take a look at this and tell me if you think I've lost
> > it.  One
> > downside is that you can't have resources that don't have a
> > uriPattern
> > (I broke the rules with the old Session stuff, but this
> > framework made
> > me give the CookieSessionResource its own uriPattern) without adding
> > additional protocol to URIResolution.  Does that bother anybody?
> >
> > It seems that people did like the Session / ACL stuff, so I'm
> > planning
> > on rolling that all into SourceForge.  If people like this, too, I'll
> > put them both into the code repository.
> >
> > On a more personal note, I'll be doing a lot of traveling
> > over the next
> > few months.  I'm back and forth between Walla Walla, WA and
> > Medford, OR
> > for Key.  They've lost all but one of their Software
> > Engineers down in
> > Medford, so I volunteered to travel down there and give the remaining
> > soul a hand.  So if I don't respond to your emails very
> > quickly, you'll
> > know why (Joe, I'll get a response to you soon, I promise).
> >
> >
> > Ken
>
> _______________________________________________
> Swazoo-devel mailing list
> [hidden email]
> http://lists.sourceforge.net/lists/listinfo/swazoo-devel