The system we're building at Kynetx includes a domain specific language that uses rules to create JavaScript programs that get sent down to the browser. I've documented our decision to use a domain specific langauge and our choice of Perl in other posts.

When I started this project, I was reading Mark Dominus' book Higher Order Perl and started using his HOP parser to play around with. One thing led to another an before you know it I had a full blown language parser in HOP without giving much thought as to whether or not I'd made the right choice.

I found the HOP parser to be pretty flexible, but it has it's quirks. More importantly, I didn't like the BNF specification format and so I was constantly trying to keep the spec and the implementation in sync. Better if I could just use the spec as the implementation 'ala Bison. Don't get me wrong, this is a great book with lots of wonderful ideas, but I wanted something else for the parser.

As I added more and more features to the language, it got to where I'd dread making the parser changes. Recently, I decided I had to significantly beef up the predicate expressions and thought it would be a good time to change out the parser as well.

A few months ago I picked up Christopher Frenz's Pro Perl Parsing in anticipation of just this day. Reading through it illuminted my choices and ultimately, I picked Damian Conway's Parse::RecDescent, a recursive descent parser over the other contender, Parse::Yapp. The reasons for my choice were partly esthetic and partly a trust in Damian. The main thing I was after was a parse spec that I could read and compile and RecDescent seemed great in that regard.

The biggest downside of RecDescent is that there's no associated Lexer. For most things that's not a big deal since terminals can be specified as regular expressions. The place where it really bit me was comments. Removing comments is trickier than you'd think because you don't want to process "start of comment markers" inside any quotes. With a lexer, that's easy, without one, it's more problematic. Writing the regexp to remove comments took me a while to get right. I ended up using a modified version of the solution given in this FAQ. The problem with most solutions, including Regexp::Common, which has a language comment module, is that they don't account for comment markers in quotes.

All in all, it was a good thing to do and I'm happy with the choice of RecDescent. Here's a sample production from my file:

decl: VAR '=' VAR ':' VAR '(' expr(s? /,/) ')'
      {$return =
       {'lhs' => $item[1],
        'type' => 'data_source',
        'source' => $item[3],
        'function' => $item[5],
        'args' => $item[7]
       }
      }
    | VAR '=' 'counter' '.' VAR
      {$return =
       {'lhs' => $item[1],
        'type' => $item[3],
        'name' => $item[5]
       }
      }
    | VAR '=' HTML
      {$return =
       {'lhs' => $item[1],
        'type' => 'here_doc',
        'value' => $item[3]
       }
      }
    | 

This production for decl has three alternates. Each has a separate return value (a hash) that represents the portion of the abstract syntax tree created for that part of the input.

If you decide to give Parse::RecDescent a try, here are some resources:

• The Parse::RecDescent documentation
• The Parse::RecDescent tutorial
• The Parse::RecDescent FAQ
• An O'Reilly getting started-style tutorial
• An example showing SQL CREATE TABLE statements

Reading the documentation and the FAQ thoroughly is highly recommended. There's lots of little tricks that can make your job easier.

My job, replacing an existing parser, was made easier by the fact that I'd previously built a pretty thorough test suite in Perl for the parser and some related modules. So once I got the language spec pretty much complete, I started running the tests and correcting errors as they cropped up. In a few hours, I'd solved all the problems and was confident my parser was ready to go. Definitely the way to go.

At any rate, now I've for a shiny new parser that I can go modify. Fun!

Tags: kynetx perl programming+languages parsing

Doug has put code in place to post new IT Conversations podcasts on Twitter. You can follow the IT Conversations twitter account and see new podcasts as they're published (about one per day).

Tags: itconversations twitter

Doug has put together a Podtrac survey to help us understand what IT Conversations listeners listen to and who you are. We're really appreciate it if you could take a minute and fill it out. You may find some of the demographic questions a little intrusive, but remember it's anonymous and that information is extremely helpful to us when we try to find underwriters for shows. It will take you 5-10 minutes, but it's very helpful to us, so I hope you'll give us a little of your time.

Tags: itconversations survey

My review of Fatpipe WARP has appeared in InfoWorld.

I've had a Comcast cable Internet connection for years. Last year I got a shiny new fiber connection from Mstar. But rather than uninstall the cable connection, I asked FatPipe Networks if they'd be willing to let me perform an extended test of the company's flagship route clustering product, WARP.

WARP is a 4U, rack-mountable network appliance that allows up to three WAN connections to be aggregated without the need for complicated BGP (Border Gateway Protocol) routing configurations. The unit provides traffic load balancing over these connections, allowing both inbound and outbound traffic to take advantage of them. Being able to handle connections of varying speeds from different providers makes WARP a great choice for businesses seeking to add extra bandwidth and increase the reliability of their connectivity.

From Product review: WARP your WAN for performance and reliability | InfoWorld | Review | 2008-08-28 | By Phillip J. Windley
Referenced Mon Sep 01 2008 10:25:41 GMT-0600 (MDT)

I eventually shut the Comcast connection down and now get by with the fiber connection (15 Mbps symmetric). But while I had it and the WARP set up, it was pretty cool to be able to push load onto one connection or the other.

Tags: infoworld networking fatpipe

If your Web service does anything that sets cookies, you'll probably bump up against the fact that Internet Explorer--since version 6--has implemented a fairly strict privacy policy regarding cookies. In a nutshell, if the site does not have the right P3P privacy policy, first-party cookies (i.e. from the site itself) are downgraded to session cookies and not stored in between browser sessions and third party cookies (i.e. from another site) are rejected completely. Here's what to do to solve this problem.

P3P, or the Platform for Privacy Preferences is a W3C "protocol allowing websites to declare their intended use of information they collect about browsing users." In IE 6 and 7, users can use a slider bar to set their desired degree of privacy and then IE will automatically check the privacy policy of the sites they visit and "protect" them according to their preferences. The default setting (medium-high, which most people never change) gives the behavior I describe above.

Deploying a P3P policy actually isn't very hard. There are some great tools for creating the policy itself. But it can be difficult to know exactly what to do. I followed these instructions but still have a few questions, so I'll document exactly what I did below.

The first step is to create the policy. I used IBM's P3P policy editor. It's a Java program, so it will run most anywhere. Using the tool takes a little work since it's not clear at first what you're editing. Create your policy from a template if you can since that will save a lot of decisions later. Once you've done that, select Policy->Policy Properties and fill in the information about your service and organization. If you look at the errors, you see that you have to fill just about everything in. Make sure you add a "privacy seal" even if it's just a notice that your customer service department can answer questions.

The policy itself is in the "groups" on the right. Double click each one and make sure you agree with what it says. Clicking on "Errors" will show you things left undone and clicking on "HTML Policy" will show you the human readable version of what you're creating. At the bottom it provides an analysis of how this policy will play in IE. Very helpful.

When you're done and there are no errors, you need to save four things:

1. The policy itself as name.xml where name is the name you selected under "Web Sites" in the Policy Properties pane. You will likely have just one, but you can have many covering different parts of your site.
2. A policy reference file as p3p.xml. This file provides discovery services for the policies. Whether you have one or many policies for your site, this file tells programs which policy applies where and how to find them
3. A human readable policy
4. A compact policy. This is a string of three and four letter acronyms that specify the policy in a compact manner.

Put the first two in http://yoursite.com/w3c/... Put the third in whatever URL you specified the human readable policy would be referenced by.

The compact policy is used in the HTTP headers that your server returns for ant HTTP request. This gets rid of one or more round trips to the server to request the XML version of the policy. In my experience, this was a necessary step to get IE to recognize the policy.

Having Apache return the compact policy in the header requires building and installing the mod_header module. I'd already done that so I simply added this line to my HTTP configuration file:

Header append P3P "CP=\"NOI DSP ADMo DEVo TAIo ... DEM STA\""

Once you've got all this installed, you should be able to open IE, double click on the eyeball with the red slash through it in the status bar and confirm that your cookies are no longer blocked. If there are no blocked cookies, the eyeball is not there at all.

That's it from a technology standpoint. The trickier part is deciding whether you can actually live with the restrictions you'll need to put in place to let IE store your cookies.

The whole thing feels like a waste of time. Your product won't be better and most people won't be any more protected when your done. But you need to do it in an IE world.

Tags: kynetx privacy internet+explorer

I'm starting a new business called Kynetx. As I go through some of the things I do, I'm planning to blog them. The whole series will be here. This is the fifteenth installment. You may find my efforts instructive. Or you may know a better way---if so, please let me know!

One of the things that ought to strike fear into any technologist's heart is getting your first customer. You've spent months building a product you hope people will buy and find useful and suddenly someone actually is putting their faith in you and your baby.

You're happy, of course. But most of all, you're scared. What if something doesn't work? What if it doesn't scale? What about feature A, B, and Z that we haven't built yet? What about the shortcuts you took here and there to get it done? What about...

I've done this a couple of times now and I'm convinced of two things: (1) you're going to sell your service before you're ready and (2) you should have sold it even earlier.

We're at that stage with Kynetx. We've signed up several good pilot customers and we're actively courting the indirect sales channel. These are sharp, demanding folk with good ideas and little time to waste. That scares me.

Don't get me wrong. I've never built a product or service that has been more ready to scale and that I'm as confident works as promised. We've spent months automating infrastructure. I've written thousands of tests. Still, it's scary. If you asked me, I'd take another couple of months. Of course, at that point, I'd still take another couple of months. You're never ready.

That leads nicely to my second point. Since you're never ready, you might as well start selling even earlier. There are big advantages to having real people kick the tires and give you feedback. The product becomes better faster through that process than anything else you can do. And you invariably plug some of the holes that have crept into things.

But wait. There's more. The best part of selling your product early is that it helps you understand what you do and how you're different from your competitors. These are two key pieces of information when you're going out to raise money.

You may think that it's weird that you could start a company and not know what you do, but in fact it's quite common. Oh, you know what you do on many levels, but telling other people about it can present some challenges. In an earlier post in this series I wrote about finding your story. Same idea.

When you start to tell others about your product or service, they invariably try to understand you by comparison. "Oh, so you're just like [insert company name here]" or "Oh, so you're a [insert product category here]." Often these are the very companies or categories you're trying to distinguish yourself from. You need to understand how your different in ways that you can easily explain.

Going through some VC meetings and pitching events helped us refine our story, but we're reached a whole different level talking about what we do with clients. They're usually more willing share, explore, and engage in a dialogue than VCs who typically hold their cards very close to their vest.

Clients aren't as interested in comparing as VCs because they don't care as much who you're like. They're not trying to find the next category killer. They just want to solve a problem and if your nail will secure their board, then they're game.

Besides, I don't know about you, but in client meetings I'm a whole lot more relaxed than I am in a VC pitch. I'm in my element--showing off the things I'm most passionate about right now. Clients usually want to see what you have and our demo usually wows people. VCs never want to see a demo.

As a consequence of all this, I wish we'd been positioned to start selling well before we started raising money. Unfortunately, because of various timing issues and our own understanding, things didn't work out that way. If I do this again, I'll start selling much earlier.

Tags: kynetx startup selling

Dave Cross has a piece on why corporations hate Perl. He's being a little hyperbolic (as he admits)--not everyone hates Perl, but he's right in noting that there is a backlash against it. He says:

I was talking to people from one such company last night. The Powers That Be at this company have announced that Perl is no longer their language of choice for web systems and that over time (probably a lot of time) systems will be rewritten in a combination of Java and PHP. Management have started to refer to Perl-based systems as "legacy" and to generally disparage it. This attitude has seeped through to non-technical business users who have started to worry if developers mention a system that is written in Perl. Business users, of course, don't want nasty old, broken Perl code. They want the shiny new technologies.

And so, in a matter of months, the technical managers at this company have create a business environment where Perl is seen as the cause of most of the problems with the current systems. It's an impressive piece of social engineering

From Why Corporates Hate Perl - O'Reilly ONLamp Blog
Referenced Wed Aug 20 2008 10:43:00 GMT-0600 (MDT)

He labels this kind of things "anti-Perl social engineering." I've run into similar feelings.

At Kynetx, our systems are built in Perl and Ruby. We use Rails to create the user facing pieces, but the engine, that part that needs to run fast, is written as an Apache module in Perl.

I've noticed that when I explain the language choice to people I almost always have to answer the spoken or unspoken question: "Perl?? Really? Why Perl?" After I explain the architecture and the reasons behind the decision, they're almost always satisfied, but there's a definite stigma.

I'm doing a talk next week at the Utah Open Source Conference (Friday morning at 10am) on using Apache as an application server. There are some significant advantages and Apache offers some real great application support that is largely untapped. But to talk advantage of it, you're pretty much stuck with C...or Perl. Given that choice the decision is a no-brainer. I'll be putting my thoughts together for the talk later this week or next week and promise to blog the ideas.

Still, the idea that Perl is an old crusty language couldn't be more wrong. I've been programming in Perl for nigh on 15 years now and I don't think it's ever been more interesting. Perl sports the best collection of libraries of any dynamic language and supports modern engineering practices like modules, objects, and testing. I've seen ugly Perl code--heck I've written it--but that's not Perl's fault.

I spoke with a local company last week that has been a Perl shop but is moving to Java. I smiled because I know that means there will be a lot of unhappy Perl programmers there who I can hire later! :-)

I'll continue to proudly carry the torch for Perl.

Tags: kynetx perl programming+languages

We'll be holding the CTO Breakfast next week on Thursday at 8am in conjunction with the 2008 Utah Open Source Conference. You don't have to be going to the conference to attend the breakfast, but I do have discount codes available for CTO Breakfast attendees. Contact me if you're like one.

The Utah Open Source Conference 2008 will be held at the Salt Lake Community College, Redwood Road campus from August 28 - 30, 2008. We'll be meeting in rooms 221/223 of the Student Center (SC) at the Salt Lake Community College (Redwood Road campus). Here's a map that shows where to park. There is food on campus near where we'll be meeting so you can pick up breakfast.

Even though the venue is different, we'll be doing the same thing: talking about cool technology, building high-tech companies, and what's hot. Come join us.

Here's the schedule for the next several meetings:

• August 28 at UTOSC
• Sept 26 (Friday)
• Oct 30 (Thursday)
• Dec 5 (Friday) - Combined Nov and Dec breakfast

Please mark your calendars.

Remember that you don't have to be a CTO to come. Anyone interested in product development in high tech is welcome.

Tags: utah cto breakfast open+source UTOSC

Craig Burton has written a nice essay on why software infrastructure behaves differently, economically speaking, than other products and why that upsets the natural inclination most people have relative to protectionism. That, of course, is what the whole net neutrality debate is about.

As Craig says, artificially disrupting the "run to ubiquity" in the software infrastructure on which we all depend, disrupts all players: all

So here is my point about the inverted supply and demand model; today's core software infrastructure is made up of a core set of services. Roughly, file, print, web, database, directory, security, and the Internet protocol suite. Anything that artificially restricts the growth of this infrastructure compounds growth limitation on almost all technology across the board. From Ruminations of a Software Man
Referenced Fri Aug 15 2008 09:48:23 GMT-0600 (MDT)

Tags: net+neutrality internet software infrastructure

We were notified that Kynetx will not be one of the TechCrunch 50. Ah well... The rejection notice said this:

We are sorry to let you know that your company was not selected as a finalist for the TechCrunch50 conference. As you know, we are only able to select a very, very small percentage of the more than 1,000 outstanding applications we receive.

Your company was among a select set of candidates that we considered, and it was a difficult decision driven purely by the limited number of presentation slots. Since we regarded your business so highly, we want to make sure you still get the opportunity to participate in the conference in our DemoPit.

As a DemoPit company, you will have the opportunity to be nominated for the People's Choice award and win the 50th spot on the TechCrunch50 main stage. As the 50th company to present, the People's Choice award winner will be able to compete for the $50,000 TechCrunch50 award. Act fast, as spaces are very limited and first come, first served.

Additionally, all DemoPit companies will benefit from the exposure generated by media attending the event. We do anticipate having approximately 300 members of the international press in attendance.

Participating in the DemoPit costs $3000, a not insignificant sum for our early stage start up. My question is "is it worth it?" Any wisdom out there?

Tags: techcrunch kynetx

A few days ago I wrote about federating with Identi.ca. Yesterday I had a great chat with Craig Burton about that whole idea. He's not buying. I asked him to respond on his blog so we could move the discussion online.

My argument was essentially that moving Twitter-like functionality onto a distributed platform was a good thing and likely to make more people comfortable with the idea of building out additional functionality in the micro-blogging space (what people have started to call the space that Twitter is in). The fly in the ointment, from my perspective, is the additional friction engendered by the need to subscribe to people on federating systems. Much harder than clicking "follow" on the Twitter page.

Craig's argument is that the advantages of a single namespace are so huge that the friction I mention is a deal-killer. He goes on:

With all of the downsides of Twitter, I still love it. Why? Because it has the big names already in it! Don't you get that?

I chortle at my cohorts--- @stevegillmor and @jessestay (twitter names) that are bad mouthing twitter and claiming that somehow other systems are better from some tech reason or another. The big names are already in Twitter. Ample reason to stay and stick out the growing pains.

From Federated Twitter Look alikes---Ho Hum
Referenced Thu Aug 14 2008 13:07:08 GMT-0600 (MDT)

Craig's got a point that goes beyond what I was considering. The namespace issue and the friction of subscription collide in unpleasant ways. But as I thought about it, I realized that with Laconi.ca based systems, URLs are the namespace. Laconi.ca, and hence Identi.ca, don't create a private namespace. That's why federation works.

So, the friction that subscription creates might the death of these federated systems. Or it might be it's salvation. Things like the gateway that WebDevStudios' put up to link Twitter and Identi.ca might make the whole discussion moot. Or, it might be something else entirely like the fact that Identi.ca doesn't do SMS.

I'm going to be talking to http://evan.prodromou.name/, the man behind Identi.ca and Laconi.ca on Monday as part of my Technometria podcast. I'm really looking forward to it--this whole thing is really heating up.

Tags: twitter microblogging itconversations

Twitter's performance problems over the past few months have made people skittish about basing businesses, even ideas, on it. The problem isn't just performance problems, however. When one company controls what many come to consider a key piece of infrastructure (who'd have thought they'd read that about Twitter 18 months ago), it creates a brittle situation. What if they can't perform or go out of business?

Enter Identi.ca, a Twitter-like site that's based on open source software called laconi.ca. The key problem with something like Identi.ca is that if it's just another centralized solution, nothing's changed.

Laconi.ca has the ability to federate different servers so that if I have an account on Identi.ca and you have an account on whojusttweeted.com, I can follow you and you can follow me. Until today, I've understood that in theory, but not in practice.

Jay Ridgeway has put together a short instruction page on how to federate two accounts on different Laconi.ca servers. There are seven, count'em, seven steps. That's a little more involved that most people will put up with, but, as Jay says, it's a start.

It really isn't any more involved than subscribing to an RSS feed and over the years we've discovered ways to make that less painful. Still, I'd argue that part of the lag in uptake of RSS by most people is this complicated subscription process.

I think subscriptions are a great answer to complicated syndication problems--whether it be RSS, tweets, or whatever, but we've failed to make that pattern so precise that systems take the pain out of subscriptions for users.

I think I'll set up a Laconi.ca server and play with this a little. There's something here, I think.

Tags: federation social+networks twitter

The whole idea of Puppet is to put your machine configuration scripts in a versioned repository. This is good because I've found that a syntax error on a manifest not even used by the current machine will stop the puppet updates from running. One error anywhere kills the whole thing everywhere. So, being able to back out of a change is good.

We can go one better however and keep people from checking in files that aren't syntactically correct using the pre-commit hook in SVN. If you don't use SVN, your repository probably has something similar.

I followed these instructions for the hook and these instructions for installing it.

I ran into a problem however. The pre-commit script wasn't reporting an error condition correctly. I'm not sure what was wrong. Running the puppet command on the command line and then checking $? gave a "1", but inside the script it wasn't working that way. So, I punted and wrote the error output to a file and checked whether or not the file existed and then just cat'd that out to standard err. Messy, but it worked and I need to go home. Here's the file as modified by me:

#!/bin/bash
# SVN pre-commit hook to check Puppet syntax for .pp files
PATH="/usr/bin:/bin"
REPOS="$1"
TXN="$2"
tmpfile=`mktemp`
errfile=`mktemp`
export HOME=/
SVNLOOK=/usr/bin/svnlook
$SVNLOOK changed -t "$TXN" "$REPOS" | awk '{print $2}' \
   | grep '\.pp$' | while read line
do
  $SVNLOOK cat -t "$TXN" "$REPOS" "$line" > $tmpfile
  if [ $? -ne 0 ]
  then
    echo "Warning: Failed to checkout $line" >&2
  fi
  /usr/bin/puppet --color=false --confdir=/tmp \
     --vardir=/tmp --parseonly --ignoreimport $tmpfile \
     >$errfile 2>/dev/null
  if [  -s $errfile ]
  then
    echo "Puppet syntax error in $line." >&2
    cat $errfile >&2
    exit 2
  fi
done
res=$?
rm -f $tmpfile
rm -f $errfile
if [ $res -ne 0 ]
then
  exit $res
fi

Note: you may need to combine lines separated by "\\" into a single line.

This works great. Syntax errors are caught before they make it into the repository. I'm still looking for a good way to thoroughly test puppet scripts before they get into the production servers. If you have any best practices in that area, I'd love to hear about them.

Tags: puppet kynetx svn

I'm stil catching up on my IT Conversations listening after being gone on vacation for 10 days. This morning I listened to Mark Rolston's talk from the Emerging Communications conference entitled The New Singularity. Contrary to what you might think from the title, this isn't about "the" Singularity, but rather the idea that we typically have one concept about what a product should and the phone belies that. I really enjoyed the thinking about products and designs. I found myself wishing I could ask a few questions!

Tags: itconversations design phones iphone

I'm continuing to explore the use of puppet for managing systems. I'm convinced that it's the best system for managing large groups of interacting servers and keeping them all in sync. For example, today I was trying to figure out why a cronjob that processes log files wasn't working. Turns out that it was a system issue and there was also a problem with mail aliases, so we weren't even finding out.

I create a simple puppet recipe for all our machines that simply ensures crond is running. That's basic and now it's ensured on all our machines. This was simple:

class cron {
      service { crond:
	      ensure => running,
	      enable => true
      }		
}

Next I created a manifest to installed the correct crontab entry on the right machines to process the logs along with setting the right environment variables for the processing daemon. There's a cron "type" in puppet so it's pretty easy:

class kobj_log_daemon {

      cron { kobj_log_daemon:
           command => "bin/kobj_log_daemon -v",
	   user => www,
	   hour => 0,
	   minute => 5,
	   environment => ["WEBROOT=/www", "MAILTO=root"],
      }
}

Finally, I took care of mail aliases by putting /etc/aliases under the control of puppet. Here's the class definition that does that:

class aliases {
 file { "/etc/aliases":
   mode  => 640,
   source => 
     "puppet://puppet.kobj.net/dist/apps/sendmail/aliases",
   owner => "root",
   group => "root",
   before  => Exec["create aliases db"]
 }

 exec { "new_aliases":
   command => "/usr/bin/newaliases",
   alias => "create aliases db",
   subscribe => File["/etc/aliases"],
   refreshonly => true,
 }
}

Now there's one place--under version control--where all of this is controlled for every machine we own. Managing this any other way would be a recipe for disaster.

Tags: system+configuration kynetx puppet

Businesses spend a great deal of time and money trying to identify their customers. By "identify" I mean not just get a name and credit card number, but find, learn about, and discover the attributes, preferences, and even desires of customers. They spend millions of dollars on "customer relationship management" (CRM) systems that are really "customer dossier systems" in a quest to manage the identity data they collect about customers.

In the same way, customers spend a great deal of effort identifying businesses. Which business sells the product that will meet my needs at a price I'm willing to pay? Which business will give me the best shipping, the best service, or even the most emotional lift when I buy from them?

Doc Searls has been talking about the need for the one-way "CRM" systems to become more truly about relationships for years--ever since I first met him. He's set up Project VRM at Harvard to focus on that effort. VRM, which stands for "vendor relationship management" was meant as a play on CRM, but is maybe too "user-centric" at this point. The real idea is relationships.

When Bob Blakely spoke at IIW about relationships, I don't think I really understood what he was saying, but I took notes and today when I was going back over them, the idea of relationships as the context for identity actually leaped out at me. (See also Drummond Reed's notes on this same talk.)

I've been thinking about this idea in the context of ecommerce lately and trying to understand the market that might emerge as ideas like VRM start to take hold. As Bob mentioned in his talk, this idea has real power when relationship intermediaries start to get involved.

The much used analogy to the credit card industry is applicable here. I can buy a TV at Best Buy on credit not because I have a direct credit relationship with Best Buy (although they'd love to establish one with me) but because I have a trusted relationship with my bank, they have one with their bank and there's a contract between those two banks (via the Visa network) that links them.

In a similar way, intermediaries could provide strong trust relationships that link merchants and shoppers. Here's a picture:

In this diagram the blue box labeled "RelP" represents a relationship provider. Not an IdP who provides low value authentication services, but someone with a strong trust relationship with various parties--shoppers and merchants in my example. The RelP creates a relationship context within which the identity data lives and is shared. Other RelPs through contractual relationships can federate to create relationship contexts that span a single RelP.

As a side note, this model doesn't necessarily envision the creation of a network for relationships like Visa, although you could imagine one. This was the reason Andre Durand started Ping Identity. 2002 was probably too early to get that gargantuan task accomplished, but the technology and thought processes around this area have grown up a lot in the last 6 years.

How might such relationships be created and managed? Drummond and the folks at the Higgins Project believe that relationship cards, or r-cards are the answer. They well may be. An r-card, perhaps slightly misnamed, offers the capability to instantiate an ongoing data sharing relationship that can be terminated at any time by either party. in Drummond's words:

An r-card ... exchanges a set of claims and associated policies that enables both parties to continue to share other information over time, e.g.:

• Updates to the initial values of the claims
• New claims
• Permissions and controls over communications via other channels
• Changes to the r-card itself

I'm still trying to understand all the details, but convinced of the necessity of this kind of thing. My work on reputation (PDF) was a start at understanding how trust relationships can be created online. I'll be writing more about this as I understand it more over the coming weeks.

Tags: identity relationship rcards reputation

The iPhone apps for Typepad and Wordpress made me jealous. But I found that there's a plugin for MovableType that provides a servicable interface for the iPhone. Typing HTML on the iPhone keyboard isn't easy. But if you have to blog remotely, here it is.

Tags:

I forgot my laptop at home today. Just drove off without it. Left it sitting in the garage. Ugh.

Fortunately, today wasn't a day that I was planning on spending the day coding. My development environment runs in Fusion on my MBP, so that would have been tough. I had a day of meetings and discussion and for that, my iPhone worked just fine.

For the most part, I take my laptop everywhere I go. This mistake has taught me that I could take it fewer places and get by.

What suffered? I couldn't pusblish today's show on IT Conversations from my iPhone very easily. I couldn't blog easily. As I mentioned, I was without my development environment. Other than that, life went on.

Tags:

A few days ago I said that we wouldn't be holding a CTO breakfast in August. I was wrong. In fact, we'll be holding the breakfast on August 28 in conjunction with the Utah Open Source Conference at Salt Lake Community College. Please mark your calendars.

If you're a regular breakfast attendee, I have discount codes for UTOSC that I can give you. Just send me a note.

Tags: utah events open+source cto breakfast

With the high price of gasoline, lots of people are looking for ways to save money on gas. The simplest method is simply to slow down. The drag on a vehicle goes up with the fourth power of the speed. That implies a very crisp knee in the curve.

Of course, the standard answer would be "lower the speed limit to 55MPH." But that would really be a bummer for people on long trips. We have better technology than in the 70's. Most people cruising down the highway at 75 don't know that they could slow down 10 or 20 MPH and save real money. Let's give them data. Here's my proposal.

Why don't cars come with a meter that shows how much you're spending right now on gas. Turn instantaneous mileage into instantaneous dollars and you'll see real behavior change. That leaves people free to choose and most will choose saving money when there's no compelling reason not to while leaving people the freedom to spend money to get where they need to be.

One step further: create an online game where people can compete for best performance over a given route.

I'm looking for an iPhone app that does this for starters.

Tags: politics gas