mca blog

SSDSDeploy.exe release 1.0

Tue, 19 Aug 2008 04:56:00 GMT

i finally posted (googelcode, codeplex) my first pass at a deployment tool (SSDSDeploy.exe) for posting binary files to your SSDS stores. it's now possible to upload one or more files (using wildcards or command-line scripts) to any designated SSDS /authory/container location. below is the 'help doc' for this command-line app:

SSDS Deploy Console (1.0 - 2008-08-18)

POST single binary file:
/{a}/{c}/{e} "[c:][\folder\path\]file.ext" ["mime-type"] [y]
where:
	{a} = authority
	{c} = container
	{e} = entity
	 y  = overwrite existing entities

ex:	/my-auth/files/my-profile "c:\temp\profile.jpg" "image\jpeg" y

POST multiple files using wildcard:
/{a}/{c}/* "[c:][\folder\path\]*.*" [y]

ex:	/my-authority/my-container/* "c:\uploads\*.*" y
	or
ex:	/my-authority/my-container/* "c:\images\*.png" y

in this release you can POST (including overwrite) to the /authority/container/ store using a simple filename (filename.ext). currently SSDS has trouble parsing entities w/ "/" and/or "\" in the name. for now, that means you can't upload using an entity name such as /images/file.png. but you *can* use file.png. while SSDS is working on this bug, i may release a version of the tool that uses some other URL-safe character as the 'folder-separator' (":"?).

exyus: no updates?

Sat, 16 Aug 2008 17:11:00 GMT

i recently got a question on why i've not rev'd the exyus codebase in months. good question.

first, i started to slow on changes to the codebase this spring. i'd reach most of my initial goals of building a REST-y library for IIS w/ C# and began focusing on exercising the details. that allowed me to flush out weak spots, find holes in the implementation, etc. and besides, i was kinda tierd of writn C# and more interested in building web apps[g].

along the way, i got side-tracked by SSDS. SSDS is MSFT's implmentation of database services 'in the cloud.' in this case, they support basic data read/write via SOAP and a REST interface. i've only worked with the REST interface and it's pretty solid. so, over the last two months i've been putting out demo apps and posting my code for other to play with. i'll also point out it's a great beta program. the SSDS team is a good bunch and they are pretty active on the MSFT-hosted SSDS forum.

so...

i cut back on rev-ing exyus to take time to use it and i started working with a new data storage system that uses REST as an interface. the next logical thing would be to combine the two, eh? it would be pretty simple. i just need to implement a single class within exyus that does the read/write work against SSDS. the main issue is that, right now, SSDS is quite constrained in it's feature set. it's an early beta. but i have it on my list of things to do.

finally, now that i've used exyus as a web library for a while, i can areas where it can be improved, expanded, and (most importantly) where code can be removed (remember: Code is our enemy). over the next month or so, i'll get back to updating the exyus source code. and when i do, it should be smaller, faster, and better able to handle typical workflow of a web application.

Bill de hÓra is amazing

Fri, 15 Aug 2008 23:18:00 GMT

in the last few days, Bill de hÓra has posted some incredible stuff on REST-related issues.

i'm blown away.

thanks.

REST checklists are cool

Fri, 15 Aug 2008 17:52:00 GMT

not sure how i missed this but it's excellent!

REST: they just don't get it

Fri, 15 Aug 2008 02:38:00 GMT

i read REST, I just don't get it today and just had to hang my head.

there is so much of REST that folks don't get. but saying:

...just use a POST as an RPC call, keep it as simple as possible and be done with it. And don't spend another minute worrying about being RESTful or not.

is just wrong.

while i see lots of 'hey, you put a VERB in the URL!' or 'You're lame if you don't use PUT' kinda talk, i don't see folks talking about some of the most important concepts outlined in Fielding's 1999 dissertation, Architectural Styles and the Design of Network-based Software Architectures - the document that described for the first time (in Chapter 5) what REpresentational State Transfer was about. check the year - 1999. actually, first drafts of the REST model were written as early as 1994! Fielding was part of the team that outlined the massively scalable distributed-networking protocol known to us as HTTP. Fielding was there on the ground floor. his REST model, even almost a decade after it's official release, stands as one of the best attempts to codify some of the key architectural patterns that went into designing HTTP.

and there are several

Use of separation of concerns via the Client-Server style
Stateless, self-descriptive messages supported by meta-data
Support for cache-ability including third-party intermediaries
A stable, uniform interface understood by all parties.
A layered, multi-party network where everyone can work safely without having to understand every detail of a transaction
Support for portable code-on-demand that allows servers to send executable units to clients for local execution

and add to the above vital system-wide constraints these additional patterns so common today we hardly give them much thought:

the abstraction of Resource Identifiers and Resources (via URIs)
the abstraction of the Resource and it's Representation (via MIME-types)
the abstraction of process flow and resource discovery (via Hypermedia links)
the abstraction of resource access, transfer, and processing (via a single abstract interface) that allows clients, proxies, servers, caches, resolvers, and other agents to work safely together

that's quite a bit of work. quite a bit of *important* work. important work that, even after a decade (almost a century in 'Internet years') continue to thrive, grow, change, and adapt to include new media types, new authentication schemes, and more.

finally, you should note that this rant does not address the 'REST means you *MUST* use PUT and DELETE methods' or 'REST means you can't use a *VERB* in the URI' assertions. that stuff just misses the point. REST is much more than rules about URLs and HTTP method calls.

and that, apparently, is what most people "Just Don't Get."

bird by bird; anne lamott

Thu, 14 Aug 2008 22:31:00 GMT

i'm reading Anne Lamott's Bird by Bird and loving it. recommended to me by shannon. i found out that there's a documentary (Bird by Bird with Annie), too.

will have to check that out once i finish the book.

SSDS and binary data - FTW!

Wed, 13 Aug 2008 02:13:00 GMT

the last SSDS 'sprint' (kinda like a beta release only 'sprintier') had a major update - support for BLOB data. users can now read/write/delete binary items using the REST interface for SSDS. very nice. this adds a whole new level to the power and flexibility of SSDS

despite a few drawbacks (limited control of the binary item's metadata and some URL-encoding bugs), i've been very keen on using SSDS to handle binary data. mostly because it allowes|forces me to level-up on my HTTP programming foo to handle binary data requests and responses. to this point, i've been taking shortcuts and only working with text-based data. this covers the better portion of most web requests, but leaves out very important stuff. not just images, but also PDF and the whole range of download-able binary formats (.ZIP, .DOC, etc.). i avoided this work for two reasons: 1) i was lazy, and 2) i was dumb. well, avoid no more.

it took some work tonight, but i finally got binary data support rolled into my HttpClient class and into the Entity class within the SSDS-Proxy library. this also meant updating my internal Caching class to make sure it could handle binary data. i still have some rough edges to sand out (mostly dealing with server-side content-negotiation and caching the proper media type), but it should be clean and zippy by the end of the week.

i first plan on updating the SSDS Provisioning Client. that will mean users will be able to upload, update, and delete binary data via the Web app. and once that's done, i've got some ideas on how to leverage binary data support in SSDS in general. if time allows, i'll have another demo app by the end of the month. i'm rubbing my hands together already[g].

SSDS Guestbook has RSS feed!

Mon, 11 Aug 2008 00:18:00 GMT

i updated my latest SSDS demo app, the SSDS Guestbook to support RSS feeds. Now, guests can monitor the public feed and even get filtered feeds of their own posts to integrate into blogs, etc.

i've had lots of fun working this demo. it turned into a 'Twitter-like' app that allows folks to post short message and reply to existing ones. not as fully-functional as the *real* Twitter, but you get the idea. i've got some other ideas on how to improve things including a visual make-over and some added features (editing profiles, track replies in a conversation, etc.), but we'll see how things go. there are so many cool things you can do with the SSDS platform, it's hard for me to focus on one project.

BTW - i notice about a week or so ago (and has been confirmed by SSDS team and other users) that the SSDS engine has been running a bit slow lately. i'd hoped it would have been cleared up by now, but it's still a bit sluggish. hopefully this will clear up soon.

firmin by sam savage = excellent

Sun, 10 Aug 2008 20:44:00 GMT

i read "Firmin: Adventures of a Metropolitan Lowlife" this evening. it was excellent!

q quirky story from what seems to me to be a quirky author. very well done. lots of literary references (for those who like that kind of thing). a great weekend read.

"incoherent things"

Fri, 08 Aug 2008 20:06:00 GMT

during a thread on the REST-discuss forum today, Bill de hÓra said (in part):

You can have a design that allows you say incoherent things and result in bugs, like having a overly finegrained programming API where users can call methods out of order. Without the constraints in place, you need lots of discipline win, or heaven forbid, governance. What's most interesting to me is that I think many programmers in the field prefer RPC or REST-RPC hybrids.

and that's a big deal, really.

in my experience, most developers have a bias for RPC. that's mostly 'cuz we've had that pattern drummed into us form almost 'day one.' but this preference for "RPC or REST-RPC hybrids" that Bill talks about is more than habit, imho. it's also a bias of perspective. devs love to 'program' stuff. and that happens when we start thinking about the Internet, too.

what i see often is the attempt to expose the same method->class->library->application pattern on the whole Internet and that leads to big trouble. instead, i try to think about exposing resources for folks to interact with. and that's it.

don't write programs.

don't write workflows or wizards or processes.

expose resouces.