Posted in SOA by AST on Saturday, December 16th, 2006
Even though I had to temporarily drop out of the ongoing discussion on the service-orientated-architecture Yahoo group/mailing list, which prompted my last post, to focus on a few high-priority interrupts for a while, my brain hasn’t fully disengaged from the discussion.
One of the light bulbs that went off in my head during the aforementioned discussion was it finally clicked as to what the uniform interface constraint “hypermedia as the engine of application state” (Fielding 2000, §5.1.5) actually means (to me, anyway). Now that I think I understand it, I also understand why it is so hard for people to really get what it means: most of the people trying to figure this out are experienced, traditional programmers. What do traditional programmers do? If they’re any good and they’re dealing with large-scale distributed systems, they spend an awful lot of time on the design of the “perfect” API for their remote components. Perfect in this context means that it is the optimal trade-off between all of the architectural constraints and system requirements to deliver an efficient distributed system.
API Brain Damage
I’m going to go out on a limb here, but I think this “API brain damage” is part of why we haven’t been able to significantly advance the state of the art of software system design over the last 30 years. We all have it, because from the moment you learn what a compiler is and get started with programming they’re all around you. As you develop your own skills and experience, you’re exposed to both good and bad API design, and this all gets mixed in together in our little brains so that each of us develops their own perspective on what is a “good” vs. a “bad” API. Most of us can, by this stage, pass such a judgment in 30 minutes or less.
However, I think the effects of this brain damage are to create some pretty fundamental assumptions about how computer systems work. If you need programmatic access (here it is again, reinforced by the terms we use to describe our requirements) to a set of functionality (for kicks, lets call it a service), then the first thing we as programmers want to know is “where’s the API?”. It’s ingrained in our very being because of years and years of positive reinforcement. We all have it…and I think it’s a tragic mistake.
Even people who have a pretty good understanding of what REST is get pulled back into the primordial slime just as they’re about to sprout legs and walk upright. Joe Gregorio’s really good article on building a RESTful system, Constructing or Traversing URIs?, is a prime example of this type of thinking. I’m not criticizing Joe here, I’m criticizing the way we, as software architects and developers, have been trained to think.
The point of Joe’s article is that hypermedia is about link traversal, but that because the possible URI space is nearly infinite, it’s reasonable to publish recipes for link construction under the argument that this is what HTML Forms using the GET method do anyway (emphasis added). This “optimization” undermines what to me is the whole point of “hypermedia as the engine of application state”: link traversal, and this is recognized by the rest of the article Joe wrote. As soon as you start down this slippery slope, you’ve lost all of the advantages I see in even bothering with hypermedia at all. It no longer becomes part of the application, it’s just data that’s shipped around via some transfer mechanism, in this case HTTP.
Hypermedia Applications
Many things have contributed to my opinion about this topic, including this statement by Eric Newcomer recently on the mailing list:
I should just note that comparing the Web to WS-* is an apples-to-oranges comparison (one being an application and the other being a collection of specifications).
With apologies to Eric, I initially sorta dismissed this statement because I was focused on my conversation with Steve Jones—but I shouldn’t have. Eric is exactly right here. The World Wide Web is a hypermedia application, not just a collection of specifications. Again, our software development training doesn’t help us here very much. Good ol’ functional decomposition makes us (well, me at least) want to see the Web as HTTP (RFC 2616), URIs (RFC 3986), MIME types (Wikipedia entry to set of related RFCs), HTML/XHTML (W3C markup specifications) and HTML forms (W3C recommendation and RFC 2388).
In actual fact, it’s all of those working together to provide, as Eric said, the Web as a distributed hypermedia application (which, if I remember correctly is a point also made by Roy Fielding himself in the dissertation). The Web works because both user agents (browsers) and the server applications use all of these specifications together to expose a set of functionality to the interactive user. There is no a priori agreement between the browser and the Web server as to how the information service built on these specifications used, but because of agreement on how these specifications are used together, as an application, it doesn’t matter if today, CNN.com is built using Microsoft ASP, and tomorrow it’s built on PHP. Apart from the application of the “Cool URIs Don’t Change” principle, if a user starts from http://www.cnn.com, they will always be able to utilize the CNN news service via their browser’s implementation of those specifications and the implicit agreement of CNN to publish its service in accordance with them too.
The moment that CNN or any other service provider publishes a recipe, guideline or specification of how to access specific parts of that service, e.g. the latest headlines may be found at http://www.cnn.com/headlines/ or http://headlines.cnn.com/ or whatever, as Joe points out in the article, they’ve made an implicit commitment to support that API (because that’s what it essentially is) for a period of time. When someone comes along an implements a specialized headline grabber that follows that API, and CNN decides to change it due to idle whim or genuine business need, that headline grabber client is now broken. If it’s just a single user, maybe this isn’t a big deal, but if it is every 3rd-party trading partner of your organization, the impact is a bit more significant.
A hypermedia application such as Atom or RSS and content negotiation via MIME types, HTTP accept headers and embedded <link/> tags mean that this sort of evolution could happen without breaking the client—provided there is agreement on the application semantics of how those things should be both used and interpreted between clients and servers. Anything else means you’re back to brittle, API based systems that can no longer evolve independently of each other.
Closing Thoughts
I don’t have all of the answers here, but I think that the notion of a “REST API” is an oxymoron because REST is about dynamic evolvability of clients and servers based on codified understandings of previously agreed application semantics. This means that HTML browsers and Web servers agree to provide the Web application in a way that both can understand and use, but it also means that RSS/Atom feed readers and server feeds agree on the way they interact to both access and provide the syndication application.
What I’m saying is that the nature and specification of the hypermedia application is as key to REST as how you use the HTTP verbs. However, since the HTTP verbs are essentially an API that programmers can get their heads around, that’s where everyone’s focus is at the moment. I think this is a diversion from where people should be thinking about REST. As long as you agree the semantics of the hypermedia application (HTML+Forms+MIME+HTTP or Atom+XHTML+MIME+HTTP), the way that application is implemented on the server should be an implementation detail and not something exposed to clients in terms of an API.
If the hypermedia constructs being used to describe the interaction between the clients and servers are not rich enough to abstract these things so the client needs to know that it’s supposed to POST data to URI x rather than being able to simply traverse hypermedia provided by the server (meaning the operation, data and location are provided to the client in a way it can understand rather than having any of this hard-coded as client implementation logic), then the hypermedia application being used (and not the information service) has not been sufficiently defined. Using the existing and emerging specifications for describing content and interaction, it should be possible to specify the application. If it isn’t, then we need to be spending our efforts on a way to do that rather than arguing about the RESTfulness of so-and-so’s latest HTTP-based API.
To me, this is the real problem to be solved in implementing RESTful systems. I think there are people who are starting to realize this need implicitly, but I think it’s time we made that need an explicit requirement of systems implemented in the REST style. If you can’t describe the interaction via hypermedia and link traversal semantics only, then I don’t think the system truly meets the requirements of REST as I understand them today. The uniform interface is hypermedia, not HTTP. Focusing on HTTP is not seeing the forest for the trees.
Comments, flames and discussion are more than welcome.
Permalink
Posted in SOA by AST on Saturday, December 9th, 2006
I can appreciate Gervas’ position as a “neutral, non-technical observer” to the whole ROA/SOA thread, but I think the root of the problems in bright people having difficulty clarifying basic issues about REST is entirely one of “what they know” and “where they are coming from”.
I have tremendous respect for Steve and everyone else on the list [the service-oriented-architecture list] that I’ve interacted with, so this isn’t personal in any way. I think it is important to understand a bit of industry history in light of lots of smart people and vendors trying to figure out how to field an SOA that works.
A lot of us on this list have been doing distributed computing for a long time. Most of us have done a lot of one or more of CORBA and DCOM before RMI/EJB came on the scene and certainly before XML-RPC and SOAP came on the scene (some people have been doing it earlier than that).
The thing about a programming paradigm is that to get any good at actually doing something with it, it takes a lot of time and effort to learn how to think and design in a way that takes advantage of it. CORBA, DCOM and EJB and the like are about extending the local programming model to remote systems in a more-or-less coherent way.
All of them are object-oriented in that you create a service with a defined set of capabilities and a given interface. This interface is normally designed in similar ways to local interfaces in that it exposes a fairly rich and domain-specific API for interaction between clients and servers. Most of the early mistakes people make in developing CORBA, DCOM and EJB projects are in the granularity of those interfaces because they forget or don’t consider the effect of the cost and overhead of communicating over the network vs the costs within the same address space, e.g. “normal” objects.
Learning how to optimize the tradeoff between a rich, domain-specific interface and one that is efficient is one of the key things in learning how to design and develop successful distributed object systems.
If you take a look at the history involved in developing these systems, formalization of CORBA started in 1990 at the OMG, DCOM surfaced around 1993 and RMI and EJB emerged in 1997. Getting all of these technologies implemented took a lot of work because most of them are naturally fairly complex. It isn’t easy trying to make a remote system look like it is a local one. Lots of vendors produced a lot of products, and some companies were founded around some of these technologies.
While each of these technologies is good (to varying degrees) at providing a distributed object computing platform within a local physical environment, they didn’t scale very well over long distances or between enterprises. Most of them required a large number of proprietary ports to be opened in company networks, which has security implications not to mention just the operational issues of making it happen.
On the other hand, HTTP and Web pages nicely sailed through port 80 which, in most cases, was already open. Both vendors and customers said, “Wouldn’t it be great if we could do things like CORBA, but using HTTP?” Enter XML, XML-RPC and SOAP in 1999-2000.
Now, if you were a vendor that had spent millions in R&D in getting distributed objects computing working in CORBA, DCOM and EJB but had come up against limiting factors such as complexity of deployment (all those ports), lack of interoperability between CORBA, DCOM and EJB and the way the Web was influencing the development of applications, what would you do?
I bet you’d figure out how to take all those things you’d been doing and make them work over ubiquitous Web protocols. I’m not saying this is necessarily bad and doesn’t have its place, but there are two other big reasons why you might think it would be reasonable to do this:
- it is the way major software vendors had been developing systems since as early as 1990, meaning
- there was a legion of software developers who understood how to develop distributed systems using those concepts and mechanisms
Vendors are protecting their investment because they need to stay in business and keep their shareholders happy, but somehow make their distributed computing technologies work together as more and more people are running heterogeneous environments not only internally, but across trading partners.
The Web is different, however.
In the same way that messaging-oriented middleware (MOM) isn’t the same way of thinking about solving distributed computing problems as using distributed objects, building successful distributed hypermedia applications using REST for either human/computer or computer/computer interaction requires a shift in the way you think about the problem.
If you can’t suspend your assumptions about how things ought to work to understand how they do work in a different environment, e.g. MOM or REST, you’ll forever be frustrated and not understand the advantages and disadvantages of this approach over any other. From my perspective on the recent ROA/SOA thread, this is where we are and why reaching any sort of common understanding is and will continue to be so difficult.
Permalink
Posted in SOA by AST on Thursday, August 17th, 2006
Only kidding–well, kinda only kidding.
I just received this article from FTPOnline about a critter called NetKernel from 1060 Research. This thing looks important, so everyone who’s been napping (me included) had better sit up and start paying attention.
The title of the post relates to the similarities of the NetKernel architecture (at least on the surface, I haven’t done a deep dive yet) to what I was trying to explain in the SOA CoP forum a while back that eventually prompted the post on Information-Oriented Architecture back in April. It is also quite close to the internal research that I’ve been doing about what would be the optimal way to deliver an XML messaging system–if that’s what you were trying to do.
What I had been doing is trying to get back to the fundamentals of what makes the Internet actually work: highly-distributed networks and the applications that provide large-scale, asynchronous messaging on top of them: SMTP. What I didn’t quite do was take the whole-hog REST approach, but I was getting there around April, because I think you can do some interesting things with XML tuple spaces and a system like NetKernel.
As is pointed out in the article, the key is caching and a separation of the logical destination address from the physical location in the network. I’m sure there are some differences between what I’ve been working on for the last couple of years and what 1060 Research has been doing, but the good thing is that now I know that the concepts are out there, under an open-source license since Peter Rodgers (1060’s CEO) was able to liberate his research project from HP once HP changed strategic direction. In and of itself, that is worth my respect. Most organizations wouldn’t be as pragmatic with their investments. Lucky for all of us that they were.
If what the article says about NetKernel is true, it proves some of what I think is wrong with all of the current crop of SOA product implementations based on code generation and direct interaction with SOAP messages. I also think the NetKernel approach (if I understand it correctly from the article and brief overview of the article) blows the pants off things like JBI, SCA and anything that is going to lead you down a particular technology choice for implementing your SOA.
People are so worried about tools and products that they’re losing sight of how elegantly simple the network model, and REST in particular, can be in making some of their implementation headaches go away. What do you think is really going to make some really big iniatives like the DoD and U.S. Government’s Information Sharing (PDF) (HTML via Google) really happen? It won’t be via passing SOAP messages around in an ESB, I can assure you.
I could go on a lot more, but I won’t. I do intend to devote some of my extremely short supply of free time over the next few weeks to looking at NetKernel more closely based on what I’ve been doing. For what’s similar to what I’ve been doing enough to claim prior art (the copyright date on the website starts in 2003–long before I ever knew what the PSB was), I’ll be motivated to share and draw some concrete conclusions as to why I believe this is important.
Ok, I lied…there’s more…
Sometimes, as software people, we get so caught up in the abstractions we’ve built that we forget that sometimes there’s a simpler way to solve the problem. No, it won’t solve all problems, and there’s some use cases for all that other junk. What we need is some people who can objectively assess, from a technology and business perspective, what the consequences of implementing SOA using various technologies are. Maybe we’re just so far lost that having someone give you a fresh towel to wipe the sweat from your brow is good enough that we don’t realize that the other guys are in Hawaii with a Waborita in their hands, and we’re still shovelling coal.
I think there really are better ways to solve some of the real IT problems today, but I’m not convinced of the “wisdom of the crowds” in this case. I think we need a few more people like 1060 Research to go out there, as it seems Chris Gunderson from the Naval Postgraduate School is doing by mis-quoting Doc Emmett Brown from Back to the Future:
I’ve lost my taste for technology roadmaps. “Where we’re going we don’t need maps!”
The quote was in response to a request for the creation of a roadmap of current SOA offerings to an ideal state, stated in evolutionary stages, posted to the SOA CoP mailing list. I might state it a little differently, at the risk of being labeled as a zealot: where we’re going, we don’t nead SOAP!
Revolutionary, not evolutionary, steps are what we need, and that is why I think the potential I see in the NetKernel architecture is so important.
And now, back to your regular scheduled silence…
Permalink
Posted in Motoring by AST on Tuesday, June 6th, 2006
Taking advantage of the 3-days of Summer over the Bank Holiday weekend (I’m sure we won’t get many more days like these), I decided that it was time to give the Camaro some automotive TLC. Some of you may have read my post from May 2005 after she failed the NCT. There were three reasons it didn’t pass the test:
- Parking brake application wasn’t within tolerance/balance
- Side-mounted red lights
- Parking lamps on when the headlamps were illuminated
As I indicated in the first post, I went ahead and ordered some replacement lenses in the hope that I would have less work to do (and, of course, it would add a bit to the appearance over the standard amber ones). Since the car has pretty-much been sitting for nearly a year without being driven, it was in a pretty sorry state. The over-abundance of spiders we have around here had comfortably found themselves and their relatives a nice new home, the side which gets less sun had developed an affinity for moss (yes, eventually everything in this country turns green–go figure) and the battery had run down. It was not only embarrassing; it was a disgrace that I had let the car get into such a state. Talk about living Linus’ quote about programmers with jobs having nice cars that they never wash to the extreme.
Getting Started
I’d planned to attack the car several times over the last year, but for various reasons it somehow never happened (it invariably rained on the weekend, getting married, working too many hours during the week so all I wanted to do on the weekend was sleep, etc.). In fact, when the Road Tax expired at the end of October, I didn’t even renew it because I knew we were going to be busy with wedding stuff for a few months. Thankfully, we had a well-timed Bank Holiday and 3 days of beautiful, sunny (yes, I said sunny) weather.
The Battery
I figured since the car was 6 years old, I’d just replace the battery. I have a decent trickle battery charger, but I didn’t know if the battery would hold a charge after being dead for so long. Of course, you can’t just walk into the average motor factors and get a new battery for a 2000 Chevrolet Camaro. The only Chevrolet cars sold in Ireland (and only since about last year) are re-badged Daewoo Korean imports, however I did see an article in the paper last week announcing GM would be selling Corvettes and Cadillacs under the Cadillac brand here as well as in the rest of Europe. Strangely enough, the only dealers currently listed on the website are in Cork, Limerick and Galway.
The first thing to do was to get the battery out of the car so I could charge it over night. I didn’t really want to leave the hood open with the battery charger outside. Anyone who has done any mechanical work will know what comes next: after 6 years of sitting (with the last 3 outside in the weather), the restraining bolt for the battery clip snapped off flush with the battery tray. The good news: I could get the battery out of the car. The bad news: I needed to drill out the rest of the bolt–how hard could that be? I’d done that sort of thing before when working on equipment on the farm.
After ringing around, I did manage to find a guy who said he’d seen one like it for a Hummer (also owned by GM), but he didn’t have any in stock. If I wanted one, he should be able to order one if I rang back on Tuesday. Great. Apparently, they don’t put side-mount-terminal batteries in cars in Europe. He had only ever had the call for the Hummer one. After heading back empty-handed, I decided I’d put it on the charger and see what would happen. I needed a running car to make sure all of the other things I was planning to do were actually working correctly anyway.
Drilling out the bolt turned out to not be so easy. What I didn’t know was the following:
- The remaining bolt was actually about 3″ long, and
- the nut for the bolt was held to the frame by a wafer-thin piece of metal.
These two facts were to make all of my drilling and attempts at using varyingly increasing sizes of bolt extractors totally fruitless. What I did discover is that the reservoir for the coolant is actually manufactured as part of the battery tray which fits into a nice hole cut in the aforementioned thin piece of metal (spot-welded to the actual frame of the car). Eventually, my gyrations with the bolt broke the two spots in the metal which held the uninclined assembly–freeing the bolt, but leaving me with an as-yet-unsolved problem of how to replace it. I think I have an idea, but I need to find somewhere that has better steel stock than either of the “DIY” shops close to home. What I have in mind should work, but it certainly won’t be factory original.
The good news was that lo-and-behold, the 6-year old AC-Delco battery seems to have lived up to its 6-year warranty. So far, the battery has held the charge and shown no sign of causing any problems. I still need to get a new one, but now the need isn’t quite so urgent. Maybe I’ll try one of the spiffy new Cadillac dealers to see how many hundred Euro a new one will cost me.
Parking Light Lenses
According to the Official, 3-volume GM service manual, replacing the lenses should be straightforward. You needed to get under the car to access the lenses, undo the 3 screws holding the assembly in place, and out it comes. What isn’t really clear from the exploded part drawings in the manual is that they seem to assume that you have taken off the plastic nose of the car before you try the replacement. Next time, I’ll actually take the nose off the car, but I doubt after this episode that there will be a next time unless one of the damn things breaks.
If you’re going to try this, you’ll need 7mm, 8mm and 10mm sockets for all of the bolts. Next, you will either need to completely remove the plastic air deflector under the front of the car, or remove each side separately. It really doesn’t matter much. In order to actually work on the assembly, you’ll then need to remove all of the plastic bits under the headlights. There’s supposed to be an “access door”, but this is only useful if you want to crawl under the car to replace any of the parking light assembly bulbs.
The kicker is that between the Styrofoam insert in the bumper and the mounting brackets for the headlights, you can’t easily get the lens assembly in or out. After much struggling, I eventually won the contest, but not without messing up some of the plastic a bit–something which didn’t make me at all happy.
What also didn’t make me very happy is that, I think I have some kind of leak in the power steering system. I’m not 100% sure where it is coming from, because I haven’t had a chance to really crawl around under the car enough yet, but there seems to be reddish oil collecting at the bottom of the A/C compressor. According to the manual, there’s supposed to be 60 ml of poly-alkylene glycol (PAG) oil in it (p. 1-34), but I don’t know what color this stuff is. Maybe its the compressor instead of somewhere in the steering system. I guess I need to check this a bit closer. Also, as you can probably tell from the picture, there’s quite a bit of corrosion under the car and attacking the thinner metal bits. The frame and larger members seem to be fine, but I’ll need to do something more about this before too long.
Parking Brake Adjustment
There are conflicting instructions between the Haynes manual and the official GM one about how to adjust the parking brakes. According to the NCT, one side was grabbing more/earlier than the other one was. I had originally figured it was something to do with the cable, but Camaro’s have a self-adjusting cable which is supposed to automagically balance the applied force between the two brake drums.
The Haynes manual says to essentially do it by feel. You get the rear wheels off the ground, remove the wheels and the brake rotors and then adjust the tension until it just drags. After this, back it off slightly and you’re set. The only problem with the Haynes manual is that the picture for the brake shoe adjustment screw is taken from under the car. This means that I ended up initially adjusting it in the wrong direction; “outward” from under the car is a bit more obvious. I know you’re not going to make the mistake I did, but, for the record, “outward” means to spin the screw towards the lug bolts and up towards the top of the car. The clearance should be 0.026″.
The GM manual says you’re supposed to do it based on the amount of movement in the parking brake cables. The distance of “free lever travel at the cable interface” should be 3-8 mm, however if it’s less than 10 mm, it says the adjustment is complete.
Since I don’t have the same fancy machine that the NCT boys have to measure the pull, I did some controlled experiments on our street. I’m sure the neighbors were wondering what the hell this manky-looking car was doing pulling handbrake stops in the middle of the road. It took a couple of goes (wheels off, calipers off, rotors off, adjust, rotors on, spin, rotors off, adjust) to get it close. I’m not sure what it is, but I do know that from about 5 mph, it seems to grip about evenly now where before I could feel a definite pull to the left. We’ll just have to wait and see.
Cleaning Up
Clearly, now that it was more-or-less there mechanically and nearly there electrically, it was time to give the old girl a much needed bath. The time in Ireland has certainly taken its toll on the paint. There are constellations of rock chips spread all over the hood, with a massive one nearly the size of your little fingernail nearly in the middle so it’s impossible to miss. I didn’t have the right tools to touch it up properly, so I had to go with filling it with wax so it wouldn’t get any worse. I’m also going to soon have a bit of a rust problem from underneath on the front-left corner of the hood. Moisture has gotten inside the hood cavity and is starting to rust from the inside out.
Some of you more clever readers may wonder why I didn’t buy a car cover and put over it since it has to sit outside. The problem is the constant moisture in the air. I’ve two ultra-fancy, breathable but waterproof covers for the motorcycles, but I don’t use them anymore because they trap more moisture underneath than they keep off. I had one of them on the SuperHawk for a month or so and the damn thing actually started to mildew! After that experience, I figured the car would actually be worse off with it than without it.
The real solution is to get it inside, but since the houses with garages seem to be sized for Yugos, I don’t think that even if we moved, it would fit in a garage. In town, it was inside and out of the weather, but then people regularly tried to steal it. I think you either put up with it, or you wait until you are really rich to buy a car you care about. That way, you might be able to afford the multi-million Euro home with a garage big enough for something like this. Somehow, I don’t imagine that the people driving the Ferrarri’s around town have this trouble, but I have been pretty surprised to see extremely expensive cars sitting outside over here–either on or near the street. Some of them cost enough that you could’ve bought two cars like mine (in US$).
After the wash and wax, I noticed that the chrome wheels were in pretty dismal shape as well. The problem with chrome is that it can take a lot of work to keep clean. Fortunately, these are fairly easy to clean (as far as wheels go), because they don’t have a lot of hard edges or small spokes. That being said, the four wheels took probably 3 hrs to finish. Still, I have to say that it was worth it. When it’s clean, it is hard to forget why I love this car–when I drive it, it’s impossible.
Still to Do
The car is now nearly ready to take the NCT, but I still need to do some electrical magic on the wiring to make the parking lights not come on all the time. The last thing I’ll do before the test is to put some black electrical tape over the rear side lamps, but there’s no point in doing it now just so it can sit out in the weather. Depending on how long it takes to schedule the NCT, I may also try and have a look for that leak a bit more seriously. I’m not sure if they’ll fail it for something like that or not, but I’d prefer not to have to take it back through the process again.
It’s clean and shiny on the outside, but it needs some work on the inside. It’s pretty stunning how much dust can get in the car when it is just sitting around. I’m sure some of this is a remnant of when they pulled the window out trying to pry open the T-tops and ended up bending the window track inside the door so it doesn’t fit correctly anymore (while parked in the “secure” parking facility where I used to live and under the watchful eye of CCT cameras).
After the NCT, it’s back to the Motor Tax office so I can give the Irish Government some more money to “improve” the roads over here. Maybe they’ll put softer rocks on the roads so it won’t chip the paint quite as badly. Then, and only then, can I take it on the road. I was hoping to be able to take it to Milltown Malbay this year, but at this rate, I’ll be pretty lucky if that happens. We’ll just have to see how it goes. I can’t wait to take it out. Driving it around even the little bit that I did to make sure it was working correctly was enough to sufficiently tease me. As hard as it might be, I’ll be a good boy and leave her at home. I don’t want to give the government any more money than necessary.
Permalink
« Previous entries · Next entries »
