• From: "Nathan Young -X \(natyoung - Artizen at Cisco\)" <natyoung@c...>
• To: "Ben Trafford" <ben@p...>, "Alexander Johannesen" <alexander.johannesen@g...>
• Date: Fri, 22 Sep 2006 17:51:06 -0700

Hi.

Couple of points about this:

>          I mean this code on your site:
> 
> <script type="text/javascript" 
> src="http://www.flickr.com/badge_code_v2.gne?show_name=1&amp;c
> ount=5&amp;display=random&amp;size=t&amp;layout=v&amp;source=u
ser&amp;user=93544306%40N00"></script>
> 
>          How much work went into creating the Javascript to display 
> that sidebar? Wouldn't it have been much nicer to simply say:
> 
>          <flickrBar userID="93544306" />
> 
>          And have CSS do the rest by intelligent placing an embedded, 
> "onLoad" link?

To the extent to which the javascript call is an API, your simplicity
comes at the cost of most of the functionality of the API.  Add back in
the URL of the service and all the other parameters the service gets
(count, display, size, layout, etc) and I'd say you'd be hard pressed to
create markup for the inclusion that's a whole lot simpler than the
javascript tag shown.

Also, although I'm intrigued by the idea of using css to specify the
details of this API, I'm not at all sure how that would play out.  It
may be that inclusion links, when they represent calls to dynamic APIs,
have javascript as a service layer because APIs make more sense
specified in a programming syntax rather than style syntax.

That leaves inclusion links that are not calls to APIs but rather
document compositing links.  There are a lot of failed systems and good
reasons for their failure, not all of them technical.  Even the right to
make a simple unidirectional link to content has been disputed in the
courts, while the use of framed content generates even more heat (and
successful lawsuits).  Third voice caused great consternation during its
15 minutes of fame. And these all stop short of true inclusion. 

Problems of broken links and missing content can also be hard to handle.
Places where both the legal and the technical issues are easier to
resolve like corporate portals and CMSs are monolithic closed systems.
(Xanadu and other earlier technologies also spring to mind)

Anyway I liked your other points, re: 

>          When we think of rendering links, we need to think beyond 
> "click and you go there,"

---->N