Features of a link sharing protocol

23 views
Skip to first unread message

Tyler Close

unread,
Nov 10, 2010, 3:40:46 PM11/10/10
to OExchange
I've been thinking about cross-site sharing in the browser and
enumerating the features and protections that could be enabled by a
good sharing protocol. The OExchange protocol specification talks
about openness and service discovery in its "1.1 Motivation" section.
However, I think there are a number of other important features that a
good sharing protocol could enable. There are likely other features
enabled by the OExchange protocol that just aren't listed in that
Motivation section.

I've come up with a link sharing protocol feature list by thinking
through the problem from the perspective of all the interested
parties: the user, the publisher and the service. This list is at:

http://web-send.org/features.html#definitions

I'm wondering what other features members of this list think are
important.

Thanks for any feedback,
--Tyler

Will Meyer

unread,
Nov 10, 2010, 10:36:31 PM11/10/10
to oexc...@googlegroups.com
Hey Tyler. Cool to see the latest iterations of this stuff. I (for
one) wasn't aware of the latest introducer spec draft -- is that
superseding the earlier powerbox drafts or is there some other ongoing
relationship there? Anyway, looks cool. Having UA support of this
type will be totally awesome!

Re link-sharing, a key need we see in this space is a simplest
formulation of the actual exchange process and mechanics, and the idea
that it should be possible, without negotiation, to communicate in a
meaningful way within a certain set of expected behaviors. This means
emphasis on defining the actual transaction and its meaning, not just
on the mechanism used to discover, register, permission, initiate and
wrap those transactions. Assume a browser-based mechanism to install
handlers, invoke them, and commence communications over a general
channel is there, what do the source and the handler say to each other
and what does it mean?

In concrete web-introducer terms, I think we're talking about defined
data-types and the associated/implied message formats that can be used
to describe "link sharing" interactions. Are data-types in practical
use going to be logical object types (which don't inherently define an
action on those objects) or actions (which don't inherently define an
the object type that that action can be performed on)? Its somewhat
straightforward when it comes to things like a local file-based mp3
resource what the data-type would be, mean, and what could be done
with it (e.g. play it in the music player app), but with online
sharing its perhaps less so.

For example, are "like", "share", "post", "bookmark", and "send" all
the same type of transaction? What happens when you want to share a
link with someone, but there's video on that page -- are you sending
them a video or a link, or both? What about annotating that object,
or providing a personal message with that specific transaction? What
about addressing it to a specific person within that context (a
facebook user, an email address)? That has to be defined well enough
to model real usage, but not so well that accomplishing average tasks
requires a complex mix of type support negotiations (or everyone
supporting everything).

I think that all of this complexity is really whats at the heart of a
common approach to this kind of link sharing. The mechanics of
choosing preferred services to handle certain types of objects I think
is a fairly different problem domain, and though the web flavor
introduces many new complexities, its perhaps more akin to the local
file-system techniques we've seen than to the direct problem of
facilitating the many forms of "sharing" actions that happen when
links get passed around. For that, we need that other layer of
meaning.

No idea if that follows at all -- I'll try to give you a more concise
formulation after some rest ;-), I also have some questions on the
pro/con that I'll prob hit you up with as well. Where's the
discussion happening mostly on introducer these days, is it still in
public-device-apis or is there a better list to discuss this stuff
nowadays? I'd love to dig into this more and start talking data-type
details and also help hook up some additional proto stuff using our
proxy backend.

Best,

W

> --
> You are subscribed to the OExchange list, archived at http://groups.google.com/group/oexchange.
> To post to the list, send email to oexc...@googlegroups.com
> To unsubscribe from the list, send email to
> oexchange+...@googlegroups.com
>

Tyler Close

unread,
Nov 11, 2010, 9:53:06 AM11/11/10
to oexc...@googlegroups.com
On Wed, Nov 10, 2010 at 7:36 PM, Will Meyer <wi...@willmeyer.com> wrote:
> Hey Tyler.  Cool to see the latest iterations of this stuff.  I (for
> one) wasn't aware of the latest introducer spec draft -- is that
> superseding the earlier powerbox drafts or is there some other ongoing
> relationship there?  Anyway, looks cool.  Having UA support of this
> type will be totally awesome!

Great to hear your a fan of this protocol.

The Introducer is a rename and redesign of the Powerbox. The Powerbox
is dead, long live the Introducer.

One of the great features of the redesign is that it resulted in a
specification that I was able to implement on top of currently
deployed HTML5 features. So the full Introducer described in the
specification is available in today's browsers simply by including the
introducer.js script. The code has been tested in the latest versions
of all the major browsers and works as specified. It should also
degrade gracefully in older browsers.

That said, I am still working on a native implementation for Chrome
and believe there is interest at Mozilla for a Firefox native
implementation. So eventually, the introducer.js script won't be
necessary.

> Re link-sharing, a key need we see in this space is a simplest
> formulation of the actual exchange process and mechanics, and the idea
> that it should be possible, without negotiation, to communicate in a
> meaningful way within a certain set of expected behaviors.  This means
> emphasis on defining the actual transaction and its meaning, not just
> on the mechanism used to discover, register, permission, initiate and
> wrap those transactions. Assume a browser-based mechanism to install
> handlers, invoke them, and commence communications over a general
> channel is there, what do the source and the handler say to each other
> and what does it mean?

I've built a protocol specifically for link sharing on top of the
Introducer. It is included in the introducer.js script and you can see
it in action at <http://customer.web-send.org/>. Incidentally, the
feature list I linked to in the previous email is also link sharing
enabled using the Introducer. I intend to write up this link sharing
protocol in its own specification. Doing so will basically be a matter
of writing up the following code snippet from the introducer.js
script:

window.introducer.introduce(anchor, [ 'org.web-send.bookmark' ],
function (agreed, provider, dialog) {
if (!agreed) {
// User cancelled request.
return;
}
if (!provider) {
// No matching Provider.
useBookmarkDefault = true;
if (!later) {
bookmarkDefault(anchor);
}
return;
}

if (dialog) {
// Restrict the presentation space given to the selected Provider.
var offsets = locate(anchor);
dialog.scrolling = 'no';
dialog.frameBorder = 0;
dialog.style.borderWidth = 0;
dialog.style.position = 'absolute';
dialog.style.top = (offsets.top + anchor.offsetHeight) + 'px';
dialog.style.left = offsets.left + 'px';
dialog.height = 40;
dialog.width = 400;
}

// Send a description of the link element to the selected Provider.
provider.postMessage(asJSONML(anchor));

// Clean-up after done.
function cleanup() {
provider.close();
if (dialog && dialog.parentNode) {
dialog.parentNode.removeChild(dialog);
}
}
provider.onmessage = function () {
cleanup();

// Fire a custom "bookmark" event so that Customer can react.
if (anchor.ownerDocument.createEvent && anchor.dispatchEvent) {
var e = anchor.ownerDocument.createEvent('HTMLEvents');
e.initEvent('bookmark', true, false);
anchor.dispatchEvent(e);
}
};
pending.push(cleanup);
});

> In concrete web-introducer terms, I think we're talking about defined
> data-types and the associated/implied message formats that can be used
> to describe "link sharing" interactions.  Are data-types in practical
> use going to be logical object types (which don't inherently define an
> action on those objects) or actions (which don't inherently define an
> the object type that that action can be performed on)?

So in the above example, the data-type "org.web-send.bookmark" means
the Customer is going to send a JSON ML representation of an <a> tag
to the Provider, allow the Provider a 40x400 inline presentation
space, and close the presentation space on the first message back from
the Provider. So the data-type is used to coordinate expectations for
the full interaction, instead of referring to only a particular object
type or action. At a high-level, you can think of the
"org.web-send.bookmark" data-type as meaning: "I'm going to send you a
<a> tag and give you a small optional presentation space. Do with it
what you will".

>  Its somewhat
> straightforward when it comes to things like a local file-based mp3
> resource what the data-type would be, mean, and what could be done
> with it (e.g. play it in the music player app), but with online
> sharing its perhaps less so.
>
> For example, are "like", "share", "post",  "bookmark", and "send" all
> the same type of transaction?

The "org.web-send.bookmark" data-type treats these as all the same. Of
course, anyone could define another data-type with different
semantics. This potential divergence is expected by the Introducer
protocol, which allows a Provider to declare itself compatible with
many different data-types.

>  What happens when you want to share a
> link with someone, but there's video on that page -- are you sending
> them a video or a link, or both?

With "org.web-send.bookmark", it's just a link. If some Providers only
want to receive links to video, we could define
"org.web-send.bookmark.video". A Customer would then make an
introduce() invocation that lists both of these types when sending out
a link to a video.

>  What about annotating that object,
> or providing a personal message with that specific transaction?

The inline Provider presentation space can be used for that. The kind
of annotation to collect from the user is likely specific to the
Provider. For example, delicious might want tags, whereas twitter just
wants some text.

>  What
> about addressing it to a specific person within that context (a
> facebook user, an email address)?

Either via the Provider presentation space, or a dedicated Provider
for that email address. For example, a Registrant could list two
Providers for the "org.web-send.bookmark" data-type: one that sends an
email that must be addressed, and another that immediately sends an
email to a particular mailing list. The former would collect the email
addresses via the Provider presentation space. The latter is
essentially hard coded to a particular email address.

>  That has to be defined well enough
> to model real usage, but not so well that accomplishing average tasks
> requires a complex mix of type support negotiations (or everyone
> supporting everything).

I think the inline Provider presentation space creates a lot of
protocol flexibility with minimal specification/coordination
complexity.

> I think that all of this complexity is really whats at the heart of a
> common approach to this kind of link sharing.  The mechanics of
> choosing preferred services to handle certain types of objects I think
> is a fairly different problem domain, and though the web flavor
> introduces many new complexities, its perhaps more akin to the local
> file-system techniques we've seen than to the direct problem of
> facilitating the many forms of "sharing" actions that happen when
> links get passed around.  For that, we need that other layer of
> meaning.

A link sharing protocol atop the Introducer definitely needs its own
specification, but I think we'll all be pleasantly surprised by how
short that spec will be, since the Introducer is doing the heavy
lifting.

> No idea if that follows at all -- I'll try to give you a more concise
> formulation after some rest ;-), I also have some questions on the
> pro/con that I'll prob hit you up with as well.

Looking forward to it. I think I can also mine this email for some
additional rows for the feature table.

>  Where's the
> discussion happening mostly on introducer these days, is it still in
> public-device-apis or is there a better list to discuss this stuff
> nowadays?

I've just been taking the discussion to wherever the interested
parties are already gathered. Since the Introducer provides
fundamental functionality for service registration in the browser,
these interested parties are clustered in many different places.

>  I'd love to dig into this more and start talking data-type
> details and also help hook up some additional proto stuff using our
> proxy backend.

That would be excellent.

--Tyler

--
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Tyler Close

unread,
Nov 28, 2010, 11:57:14 PM11/28/10
to oexc...@googlegroups.com
On Thu, Nov 11, 2010 at 6:53 AM, Tyler Close <tyler...@gmail.com> wrote:
> On Wed, Nov 10, 2010 at 7:36 PM, Will Meyer <wi...@willmeyer.com> wrote:
>> I think that all of this complexity is really whats at the heart of a
>> common approach to this kind of link sharing.  The mechanics of
>> choosing preferred services to handle certain types of objects I think
>> is a fairly different problem domain, and though the web flavor
>> introduces many new complexities, its perhaps more akin to the local
>> file-system techniques we've seen than to the direct problem of
>> facilitating the many forms of "sharing" actions that happen when
>> links get passed around.  For that, we need that other layer of
>> meaning.
>
> A link sharing protocol atop the Introducer definitely needs its own
> specification, but I think we'll all be pleasantly surprised by how
> short that spec will be, since the Introducer is doing the heavy
> lifting.

I've written up this specification now. It's at:

http://web-send.org/bookmark/

Perhaps a concrete specification and implementation will help us pick
up the discussion of desirable features of a link sharing protocol.

--Tyler

Will Meyer

unread,
Nov 29, 2010, 8:24:01 PM11/29/10
to oexc...@googlegroups.com
Hey Tyler, great to see this written up! Long-form comments below.
We should do this real-time BTW...I'm east coast, are you in the
valley?

If I'm reading this right, the spec defines:

- in introducer-terms, a datatype (bookmark and bookmark/mime sub-type
variants) and associated message format (json-serialized arbitrary
html)
- a rel type that can be used to decoratively identify content that
should be offerable to bookmarking services using this underlying
mechanism

What the bookmark-supporting introducer actually does with the
serialized content it receives is a separate matter. There's also a
sample impl (built into the same JS file as the core lib) which shows
an example bookmark introducer that itself abstracts a few popular
bookmarking services, which are not themselves introducer-compliant.

Is that overall understanding correct?

Regarding the markup, is it in fact an anchor tag in all cases, with
defined attributes, or open-ended? For example, would you annotate an
embedded video object with a rel=bookmark and allow the bookmark
introducer to receive that, potentially without even a
directly-viewable link? Or is it formally required that the element
be an anchor tag, with "type" also formally required? Does the
requirement on the element change based on the mime-based sub-types
that are passed?

For this discussion I'll separate the idea of a meta service from an
individual destination service. e.g. AddThis and similar are
basically meta services -- they receive content, somehow, and send it
off to the target destinations that do something with it, mapping it
all together. In this vein, AddThis has a decoration-based client API
that we could wrap into a bookmark introducer instead of having
publishers code to it directly (once native in the browser ofc).
Destination services, on the other hand, are services that do the work
directly. Facebook and Twitter each have their own client JS APIs
(conceptually anyway) and could themselves be bookmark introducers, as
could any service on the web that takes bookmarks. Your demo bookmark
introducer is the former category, but, assuming those services
supported introducer directly, that wouldn't be in the middle of the
actual message sending at all, right? It'd be the browser chrome that
would render the list of available services, each of which would be
communicated-to directly via the message scheme, yes?

What I'm not fully following is how the typing rationale between the
two layers works. By this I mean first the core introducer layer,
which defines a mechanism for declaring and mapping actions onto type
support, and then the bookmark layer, which defines a mime-based
extended type mechanism on top of "bookmark". For example, when would
a service that accepts video content declare its support for video
types vs for bookmark types with an extended mime video type? Is the
distinction purely that the bookmark case rests on a URL, whereas
other types may not?

A primary case we care about is allowing a given website X to do
something to allow a user to discover that X can ingest content, and
then indicate that X is their preferred target for items of that type
of content. Demo implementation aside, that mechanism in this spec's
terms would be that the target site includes code to register its
introducer for bookmark/etc types, and that that site then implements
web introducer urls that accept the passed messages directly?

Thanks for talking me through it Tyler.

Two other minor notes:
- As it relates to "bookmark", cases like instapaper, google
translate, facebook, and most other services have a hard time fitting
into that definition. This is what's behind BTW the "exchange" part
of the oexchange name.
- the spec reads as though it addresses the tweet/like/whatever count
feature common to most sharing tools. The fact that its the local
client accounting that its really addressing might be useful to
clarify. In our experience the most common use-case for this feature
is the instrumentation in an analytics system of the share events, I
assume thats what you were thinking about as well?

W

Tyler Close

unread,
Nov 30, 2010, 12:54:03 PM11/30/10
to oexc...@googlegroups.com
On Mon, Nov 29, 2010 at 5:24 PM, Will Meyer <wi...@willmeyer.com> wrote:
> Hey Tyler, great to see this written up!  Long-form comments below.
> We should do this real-time BTW...I'm east coast, are you in the
> valley?

Hi Will, yes I'm in Mountain View. Happy to chat whenever you like.

> If I'm reading this right, the spec defines:
>
> - in introducer-terms, a datatype (bookmark and bookmark/mime sub-type
> variants) and associated message format (json-serialized arbitrary
> html)

The message format is a single JsonML encoded HTML link element. HTML
has a lot of link elements, but they're not all link elements. The
other crucial part is the Provider Frame Allowance, so that a Provider
knows how many pixels it can use in the Customer page. Together, the
data-type, message format and frame allowance define how a Customer
and Provider interoperate for bookmark sharing. All other details can
be customized without affecting interoperability. The initial three
sections, Markup, Style and Implementation all explain how Customers
are *encouraged* to use the protocol, but anything that adheres to the
Declaration, Provider Frame Allowance and Message Data sections will
work.

> - a rel type that can be used to decoratively identify content that
> should be offerable to bookmarking services using this underlying
> mechanism

The "bookmark" rel type is already defined by HTML to be a permalink.
As a convenience to Customers, the introducer.js default
implementation initiates bookmark sharing when the user clicks on such
a link.

> What the bookmark-supporting introducer actually does with the
> serialized content it receives is a separate matter.

What the Introducer does is strictly defined by the Web Introducer
specification. Simply put, the Introducer searches the user's
registered Providers for ones that support the requested data-types.
It then lets the user select one, after which, the Introducer creates
a MessageChannel between the Customer and the user-selected Provider.
The Bookmark Introducer spec, then defines how the Customer and
Provider share a bookmark over this MessageChannel, by sending a
JsonML encoded HTML link element.

>  There's also a
> sample impl (built into the same JS file as the core lib) which shows
> an example bookmark introducer that itself abstracts a few popular
> bookmarking services, which are not themselves introducer-compliant.

If the Introducer finds that none of the user's registered Providers
supports any of the requested data-types, it reports back failure to
the Customer. The Customer then has to fallback to guessing at some
reasonable options for the user. This fallback code is probably what
you're referring to above.

> Is that overall understanding correct?

Including the clarifications I made, I think you've got the basic idea.

> Regarding the markup, is it in fact an anchor tag in all cases, with
> defined attributes, or open-ended?

The Message Data can be any link element defined by HTML, such as:
<a>, <audio>, <blockquote>, <embed>, <img>, <object>, <q>, or <video>.

Supporting more than just the anchor tag means we have a way of
communicating metadata that is particular to a particular bookmark
type. For example, the <video> element supports a poster attribute
that is needed to render a link to a video.

>  For example, would you annotate an
> embedded video object with a rel=bookmark and allow the bookmark
> introducer to receive that, potentially without even a
> directly-viewable link?

The rel attribute is not valid on a <video> element, so it's not clear
what markup should be encouraged for initiating a sharing action. For
now, a Customer page that wants to share a <video> has to make the
introducer.introduce() invocation itself. I'd like a better option
here.

>  Or is it formally required that the element
> be an anchor tag, with "type" also formally required?  Does the
> requirement on the element change based on the mime-based sub-types
> that are passed?

The "type" attribute on an <a> is optional, as defined by HTML.

> For this discussion I'll separate the idea of a meta service from an
> individual destination service.  e.g. AddThis and similar are
> basically meta services -- they receive content, somehow, and send it
> off to the target destinations that do something with it, mapping it
> all together.  In this vein, AddThis has a decoration-based client API
> that we could wrap into a bookmark introducer instead of having
> publishers code to it directly (once native in the browser ofc).

I think what you're saying is that AddThis could implement several
Providers. When the Introducer is dispatching a bookmark sharing
request, it would find the user's registered AddThis Providers for the
bookmark data-type. The user could then select one of these to
complete the sharing request. This could be done today, as the native
implementation will function just like the introducer.js simulated
implementation, but with some additional security and UI improvements.

> Destination services, on the other hand, are services that do the work
> directly.

From the Introducer's perspective, they look the same, its just that
destination services register fewer Providers since they are not
aggregating many other services.

>  Facebook and Twitter each have their own client JS APIs
> (conceptually anyway) and could themselves be bookmark introducers,

They would each offer a set of Providers. The Introducer is the hub in
the browser that hooks a Customer up to a selected Provider.

> as could any service on the web that takes bookmarks.

Indeed.

> Your demo bookmark
> introducer is the former category, but, assuming those services
> supported introducer directly, that wouldn't be in the middle of the
> actual message sending at all, right?

I think you're referring to the Customer fallback code again that is
invoked when the user doesn't have any registered Providers that know
how to handle bookmarks. There will always need to be something there,
since some users will arrive with nothing. The fallback selections
should be something under the control of the Customer page. The
current code just offers a reasonable default.

>  It'd be the browser chrome that
> would render the list of available services, each of which would be
> communicated-to directly via the message scheme, yes?

Yes, if the user has at least one registered Provider for the
requested data-type, the browser's chrome presents a list of them.
After the user selects one, the Customer and the selected Provider
communicate directly over the created MessageChannel.

> What I'm not fully following is how the typing rationale between the
> two layers works.  By this I mean first the core introducer layer,
> which defines a mechanism for declaring and mapping actions onto type
> support, and then the bookmark layer, which defines a mime-based
> extended type mechanism on top of "bookmark".  For example, when would
> a service that accepts video content declare its support for video
> types vs for bookmark types with an extended mime video type?  Is the
> distinction purely that the bookmark case rests on a URL, whereas
> other types may not?

For example, Flickr might only be interested in receiving links to
images. Flickr might not have any useful service to offer for links to
other kinds of resources. If Flickr registers a Provider only for the
data-type "http://web-send.org/bookmark/#image/" then the Flickr
Provider will only be presented as a sharing option for links to
images and not for other kinds of links. In particular, using the
default introducer.js implementation, Flickr would be presented when
sharing the following anchor:

<a rel="bookmark" type="image/jpeg">my vacation</a>

but would *not* be presented for:

<a rel="bookmark" type="application/msword">my vacation</a>

nor for:

<a rel="bookmark">my vacation</a>

> A primary case we care about is allowing a given website X to do
> something to allow a user to discover that X can ingest content,

With the Introducer, the X Provider does this by listing the
data-types it supports in its registration. See:

http://web-send.org/introducer/#register

> and
> then indicate that X is their preferred target for items of that type
> of content.

The Introducer keeps track of which Providers the user uses most often
and presents them in that rank order during a sharing operation.

>  Demo implementation aside, that mechanism in this spec's
> terms would be that the target site includes code to register its
> introducer for bookmark/etc types, and that that site then implements
> web introducer urls that accept the passed messages directly?

The target site would register one or more Providers for bookmark/etc
types. These Providers then directly receive messages from Customer
pages.

> Thanks for talking me through it Tyler.

My pleasure. Thanks for working through it. It helps me understand how
to better explain and document the design.

> Two other minor notes:
> - As it relates to "bookmark", cases like instapaper, google
> translate, facebook, and most other services have a hard time fitting
> into that definition.  This is what's behind BTW the "exchange" part
> of the oexchange name.

Is it the word "bookmark" or the design of the corresponding protocol
that is problematic?

> - the spec reads as though it addresses the tweet/like/whatever count
> feature common to most sharing tools.  The fact that its the local
> client accounting that its really addressing might be useful to
> clarify.  In our experience the most common use-case for this feature
> is the instrumentation in an analytics system of the share events, I
> assume thats what you were thinking about as well?

Both the Customer and the Provider have an opportunity to update an
analytics system, as both know when a sharing action has been
completed. An aggregator like AddThis is in a good position to collect
analytics from the Provider side, since it would see sharing actions
to multiple destination sites. Individual Customer sites can also
maintain their own analytics, since they see the completion of all
sharing actions. In the introducer.js default implementation, I've
attempted to make this collection easier for Customers by firing a
"bookmark" event, see:

http://web-send.org/bookmark/#event

Is there any other tooling you'd recommend here?

Thanks for all the comments,
--Tyler

Will Meyer

unread,
Nov 30, 2010, 11:39:46 PM11/30/10
to oexc...@googlegroups.com
Spent some real time with both specs, groking it a bit more now.
Inline (will prob bubble out a new thread too).

On Tue, Nov 30, 2010 at 12:54, Tyler Close <tyler...@gmail.com> wrote:
> On Mon, Nov 29, 2010 at 5:24 PM, Will Meyer <wi...@willmeyer.com> wrote:
>> Hey Tyler, great to see this written up!  Long-form comments below.
>> We should do this real-time BTW...I'm east coast, are you in the
>> valley?
>
> Hi Will, yes I'm in Mountain View. Happy to chat whenever you like.
>
>> If I'm reading this right, the spec defines:
>>
>> - in introducer-terms, a datatype (bookmark and bookmark/mime sub-type
>> variants) and associated message format (json-serialized arbitrary
>> html)
>
> The message format is a single JsonML encoded HTML link element. HTML
> has a lot of link elements, but they're not all link elements. The
> other crucial part is the Provider Frame Allowance, so that a Provider
> knows how many pixels it can use in the Customer page. Together, the
> data-type, message format and frame allowance define how a Customer
> and Provider interoperate for bookmark sharing. All other details can
> be customized without affecting interoperability. The initial three
> sections, Markup, Style and Implementation all explain how Customers
> are *encouraged* to use the protocol, but anything that adheres to the
> Declaration, Provider Frame Allowance and Message Data sections will
> work.

ACK, that clarification helps greatly.

Re the frame allowance, the spec indicates the customer must support a
provider of at least 100x500. If I read introducer correctly, the
customer has the ability to resize the frame inside the response
callback of introduce, as in:

introducer.introduce(anchor, [ 'org.example.bookmark' ],
function (agreed, provider, frame) {

...

// Restrict the presentation space given to the selected Provider.

if (frame) {
frame.height = 40;
frame.width = 400;
}

How do these two work together to dictate what the requirements are on
providers? In other words, is it essentially the case that providers
that support web-send/bookmark/* data-types have some standard size
range expectations, and customers of these types of providers should
enforce that? I'm not clear who in the end owns the size. Also
curious BTW where 100x500 comes from, in terms of real-world use.

>
>> - a rel type that can be used to decoratively identify content that
>> should be offerable to bookmarking services using this underlying
>> mechanism
>
> The "bookmark" rel type is already defined by HTML to be a permalink.
> As a convenience to Customers, the introducer.js default
> implementation initiates bookmark sharing when the user clicks on such
> a link.

Right, I should say "designated" not defined. I'll admit I've never
properly understood bookmark (by its formal definition anyway, I get
the common-use permalink version), and don't know the latest thinking
on it as it relates to things like canonical. Regardless of whether
or not this is the same conceptual case as was originally intended
with rel bookmark, and whether existing bookmark-typed links would
really all want a share treatment popping up (e.g. you'll have a lot
of sharing icons popping up on blog post titles), I get it, its
optional as a suggested facility user agents could provide.

>
>> What the bookmark-supporting introducer actually does with the
>> serialized content it receives is a separate matter.
>
> What the Introducer does is strictly defined by the Web Introducer
> specification. Simply put, the Introducer searches the user's
> registered Providers for ones that support the requested data-types.
> It then lets the user select one, after which, the Introducer creates
> a MessageChannel between the Customer and the user-selected Provider.
> The Bookmark Introducer spec, then defines how the Customer and
> Provider share a bookmark over this MessageChannel, by sending a
> JsonML encoded HTML link element.
>

Got it now, I said Introducer when I actually meant Provider. Getting
up to speed on the terms.

>>  There's also a
>> sample impl (built into the same JS file as the core lib) which shows
>> an example bookmark introducer that itself abstracts a few popular
>> bookmarking services, which are not themselves introducer-compliant.
>
> If the Introducer finds that none of the user's registered Providers
> supports any of the requested data-types, it reports back failure to
> the Customer. The Customer then has to fallback to guessing at some
> reasonable options for the user. This fallback code is probably what
> you're referring to above.

Yup exactly. Went through the code, I see the bookmarkDefault
fallback inside introduce.

>
>> Is that overall understanding correct?
>
> Including the clarifications I made, I think you've got the basic idea.
>
>> Regarding the markup, is it in fact an anchor tag in all cases, with
>> defined attributes, or open-ended?
>
> The Message Data can be any link element defined by HTML, such as:
> <a>, <audio>, <blockquote>, <embed>, <img>, <object>, <q>, or <video>.
>
> Supporting more than just the anchor tag means we have a way of
> communicating metadata that is particular to a particular bookmark
> type. For example, the <video> element supports a poster attribute
> that is needed to render a link to a video.
>
>>  For example, would you annotate an
>> embedded video object with a rel=bookmark and allow the bookmark
>> introducer to receive that, potentially without even a
>> directly-viewable link?
>
> The rel attribute is not valid on a <video> element, so it's not clear
> what markup should be encouraged for initiating a sharing action. For
> now, a Customer page that wants to share a <video> has to make the
> introducer.introduce() invocation itself. I'd like a better option
> here.
>
>>  Or is it formally required that the element
>> be an anchor tag, with "type" also formally required?  Does the
>> requirement on the element change based on the mime-based sub-types
>> that are passed?
>
> The "type" attribute on an <a> is optional, as defined by HTML.
>

Regarding the concept of being able to offer default ui decoration in
some cases and in others requiring direct introducer requests, I think
it might be useful to consider APIs for the prompts and callouts
themselves, as opposed to apis (even if just decoration based) that
trigger transparently off of the content elements. Deserves its own
discussion, but for example what I think all in-page tools have seen
is that using flexible expanded/integrated treatments is extremely
successful, much more so than the more traditional popup menu. Page
devs want control (though they may give up some for the sake of a more
integrated experience with browser chrome), but they probably don't
want to have to completely roll their own (their own ui that requests
introductions). I think there is lots that could be done here from a
standards perspective (we've done a ton of this at AddThis with our
class-based rendering api).

>> For this discussion I'll separate the idea of a meta service from an
>> individual destination service.  e.g. AddThis and similar are
>> basically meta services -- they receive content, somehow, and send it
>> off to the target destinations that do something with it, mapping it
>> all together.  In this vein, AddThis has a decoration-based client API
>> that we could wrap into a bookmark introducer instead of having
>> publishers code to it directly (once native in the browser ofc).
>
> I think what you're saying is that AddThis could implement several
> Providers. When the Introducer is dispatching a bookmark sharing
> request, it would find the user's registered AddThis Providers for the
> bookmark data-type. The user could then select one of these to
> complete the sharing request. This could be done today, as the native
> implementation will function just like the introducer.js simulated
> implementation, but with some additional security and UI improvements.
>

I think both are possible actually, right? Protoing some stuff now.
We have an android plugin for the browser's send to menu for example
that works in that way. A registrant could either wrap individual
services, exposing them as individual providers, or expose one
provider that in turn uses its own experience to choose services. UX
aside, of course.

>> Destination services, on the other hand, are services that do the work
>> directly.
>
> From the Introducer's perspective, they look the same, its just that
> destination services register fewer Providers since they are not
> aggregating many other services.
>
>>  Facebook and Twitter each have their own client JS APIs
>> (conceptually anyway) and could themselves be bookmark introducers,
>
> They would each offer a set of Providers. The Introducer is the hub in
> the browser that hooks a Customer up to a selected Provider.
>

Yeah, again switched Introducer and Provider nomenclature. Got it.

>> as could any service on the web that takes bookmarks.
>
> Indeed.
>
>> Your demo bookmark
>> introducer is the former category, but, assuming those services
>> supported introducer directly, that wouldn't be in the middle of the
>> actual message sending at all, right?
>
> I think you're referring to the Customer fallback code again that is
> invoked when the user doesn't have any registered Providers that know
> how to handle bookmarks. There will always need to be something there,
> since some users will arrive with nothing. The fallback selections
> should be something under the control of the Customer page. The
> current code just offers a reasonable default.

Right, got it now, after reviewing the code.

Sorry, why wouldn't flickr just say it supported the "image"
data-type? I'm not really following the difference between flickr
accepting images and flickr being a bookmarking service for images. I
get the implementation difference, but not sure the motivation for it
being different -- am I missing it?

Also marginally unclear how the set of tags expected/allowed in the
message payload are tied to the mime types in the supported types.
E.g. if I send an introduction request to web-send/bookmark providers,
can I pass them a video element? Root Q is whether providers have to
all be capable of ingesting each of the enumerated elements, or not.

This goes to a related but larger point re content that is
web-accessible (public URL) vs not (local image data from my native
photo app), and whether services of the type we're discussing (social
networks and tools as opposed to cameras and device video players) are
even typed that way. One of the core design premises of oexchange
was/is that you always have to have a directly navigable URL (a
sensible one). You allow the exchange mechanism work in the simplest
case trivially (just send it the URL). If you want to provide
additional info on content, you can hint it as to the type, but its
fully optional. In practical implementation, you go further, and say
that the content is self-describing to the extent that the
destinations support that. As you probably know Facebook parses out
all the ogp tags (and others) on any URL you submit to it, sucks in
previews, videos, all of that. What they'll scrape out and honor is
growing (the theoretical case anyway). Intermediaries can even
generate richly-tagged pages on behalf of publishers, based on less
than so nicely formed input, to provide the richer content to
destinations as they support it.

As this all relates to web-send, if I was a customer video page, I
think I could just always send an anchor tag and request introductions
to web-send/bookmark type providers only, and be done with it. I
could also include bookmark/video[sic] types in my introduction
requests, too. A provider like facebook's would declare its support
for bookmark and probably every other type of content, most long-tail
providers would probably just use bookmark. I think I understand how
it all works, I'm just getting my head around practical use-cases for
some of that deep type-specificity _within_ the bookmark realm.

For example if a photo site's provider registers itself as the image
handler we discussed earlier, and then introduces a video capability
(like flickr did) at some future point, users need to visit that site
and allow it to request an updated registration for that new type in
order to be able to leverage it. I can imagine the browser prefs
dialog that shows you all these type registrations and their icons,
like the file extension registry, but I'm not totally sure how all
that complexity simplifies the basic url-sharing use-case.

The name. e.g. sending a URL for translation to google isn't going to
be though of by users/devs as "bookmarking" it. Not that it
materially matters, necessarily.

>> - the spec reads as though it addresses the tweet/like/whatever count
>> feature common to most sharing tools.  The fact that its the local
>> client accounting that its really addressing might be useful to
>> clarify.  In our experience the most common use-case for this feature
>> is the instrumentation in an analytics system of the share events, I
>> assume thats what you were thinking about as well?
>
> Both the Customer and the Provider have an opportunity to update an
> analytics system, as both know when a sharing action has been
> completed. An aggregator like AddThis is in a good position to collect
> analytics from the Provider side, since it would see sharing actions
> to multiple destination sites. Individual Customer sites can also
> maintain their own analytics, since they see the completion of all
> sharing actions. In the introducer.js default implementation, I've
> attempted to make this collection easier for Customers by firing a
> "bookmark" event, see:
>
> http://web-send.org/bookmark/#event
>
> Is there any other tooling you'd recommend here?
>

I think its just perhaps a clarification in the explanation -- when
you talk about sharing tools, the counting feature tends to have,
anecdotaly, a very specific definition.

Tyler Close

unread,
Dec 1, 2010, 2:50:35 PM12/1/10
to oexc...@googlegroups.com

Great, I also added some text along those lines to the spec. Thanks.

> Re the frame allowance, the spec indicates the customer must support a
> provider of at least 100x500.  If I read introducer correctly, the
> customer has the ability to resize the frame inside the response
> callback of introduce, as in:
>
> introducer.introduce(anchor, [ 'org.example.bookmark' ],
>                     function (agreed, provider, frame) {
>
> ...
>
>  // Restrict the presentation space given to the selected Provider.
>  if (frame) {
>    frame.height = 40;
>    frame.width = 400;
>  }
>
> How do these two work together to dictate what the requirements are on
> providers?

The Provider Frame Allowance tells the Customer what numbers it should
use in the above code when it claims compliance with the bookmark
data-type. So if the first line of code there said
"http://web-send.org/bookmark/", then the last lines should be:

frame.height = 100;
frame.width = 500;

> In other words, is it essentially the case that providers
> that support web-send/bookmark/* data-types have some standard size
> range expectations, and customers of these types of providers should
> enforce that?

Yes, but where "enforce" is "allow at least".

>  I'm not clear who in the end owns the size.

It's the Customer's page and so it owns the size, but the Provider has
expectations for what that size should be.

> Also curious BTW where 100x500 comes from, in terms of real-world use.

Mostly dart throwing. The dart I used was space for a 3 line textarea
and a separate textfield.

The number needs to be something on the small side, so that a Provider
can't take over the Customer page, but it needs to be big enough so
that the user doesn't get all squinty-eyed when interacting with the
Provider. Anything above 500x100 seems like approximately the limit
beyond which it makes more sense to use a full window for the
Provider.

>>> - a rel type that can be used to decoratively identify content that
>>> should be offerable to bookmarking services using this underlying
>>> mechanism
>>
>> The "bookmark" rel type is already defined by HTML to be a permalink.
>> As a convenience to Customers, the introducer.js default
>> implementation initiates bookmark sharing when the user clicks on such
>> a link.
>
> Right, I should say "designated" not defined.  I'll admit I've never
> properly understood bookmark (by its formal definition anyway, I get
> the common-use permalink version), and don't know the latest thinking
> on it as it relates to things like canonical.  Regardless of whether
> or not this is the same conceptual case as was originally intended
> with rel bookmark, and whether existing bookmark-typed links would
> really all want a share treatment popping up (e.g. you'll have a lot
> of sharing icons popping up on blog post titles), I get it, its
> optional as a suggested facility user agents could provide.

... that Customers could use. The user-agent's understanding of the
protocol is limited to what's in the Web Introducer spec.

If I understand you correctly, the plan is to do both, but to only
standardize on the callout API (introducer.introduce() invocation,
etc) and leave the markup (the rel="bookmark" tag on <a>) to the
wisdom of the crowds and individual Customer preference. I think both
are needed, since the markup is the easiest adoption path for
Customers whereas the Introducer API supports customization.

>  Deserves its own
> discussion, but for example what I think all in-page tools have seen
> is that using flexible expanded/integrated treatments is extremely
> successful, much more so than the more traditional popup menu.  Page
> devs want control (though they may give up some for the sake of a more
> integrated experience with browser chrome), but they probably don't
> want to have to completely roll their own (their own ui that requests
> introductions).  I think there is lots that could be done here from a
> standards perspective (we've done a ton of this at AddThis with our
> class-based rendering api).

Please propose more markup patterns that could be used to trigger
introducer.introduce() invocations.

>>> For this discussion I'll separate the idea of a meta service from an
>>> individual destination service.  e.g. AddThis and similar are
>>> basically meta services -- they receive content, somehow, and send it
>>> off to the target destinations that do something with it, mapping it
>>> all together.  In this vein, AddThis has a decoration-based client API
>>> that we could wrap into a bookmark introducer instead of having
>>> publishers code to it directly (once native in the browser ofc).
>>
>> I think what you're saying is that AddThis could implement several
>> Providers. When the Introducer is dispatching a bookmark sharing
>> request, it would find the user's registered AddThis Providers for the
>> bookmark data-type. The user could then select one of these to
>> complete the sharing request. This could be done today, as the native
>> implementation will function just like the introducer.js simulated
>> implementation, but with some additional security and UI improvements.
>>
>
> I think both are possible actually, right?

Yes, but...

>  Protoing some stuff now.
> We have an android plugin for the browser's send to menu for example
> that works in that way.  A registrant could either wrap individual
> services, exposing them as individual providers, or expose one
> provider that in turn uses its own experience to choose services.  UX
> aside, of course.

And security of that UX. The Provider selection menu is protected
against clickjacking. It might not be feasible to protect the
secondary Provider iframe from clickjacking.

So far, I've only defined a bookmarking protocol for the Introducer.
Nobody has spec'd one for transfer of raw image bits, though that
might be a good idea.

> Also marginally unclear how the set of tags expected/allowed in the
> message payload are tied to the mime types in the supported types.

They're not tied.

> E.g. if I send an introduction request to web-send/bookmark providers,
> can I pass them a video element?

Yes.

> Root Q is whether providers have to
> all be capable of ingesting each of the enumerated elements, or not.

Yes, all Providers should support each of the enumerated elements. The
received message data is similar enough that it's easy to grab just
the URL if that's all you're interested in. It would be nice if HTML
used a common attribute name for the URL, but it's still a small set:
href, src, cite, data.

> This goes to a related but larger point re content that is
> web-accessible (public URL) vs not (local image data from my native
> photo app), and whether services of the type we're discussing (social
> networks and tools as opposed to cameras and device video players) are
> even typed that way.  One of the core design premises of oexchange
> was/is that you always have to have a directly navigable URL (a
> sensible one).  You allow the exchange mechanism work in the simplest
> case trivially (just send it the URL).  If you want to provide
> additional info on content, you can hint it as to the type, but its
> fully optional.  In practical implementation, you go further, and say
> that the content is self-describing to the extent that the
> destinations support that.  As you probably know Facebook parses out
> all the ogp tags (and others) on any URL you submit to it, sucks in
> previews, videos, all of that.  What they'll scrape out and honor is
> growing (the theoretical case anyway).  Intermediaries can even
> generate richly-tagged pages on behalf of publishers, based on less
> than so nicely formed input, to provide the richer content to
> destinations as they support it.

I think it's great for Providers to grab additional meta data from the
resource, but we can't rely on that being the only mechanism. Not all
resources produce HTML and so have a widely understood way of
expressing that meta data. For example, consider a direct link to an
image or video or word document. To accommodate these cases, I think
it's wise to support at least as much link-side meta data as HTML
does.

> As this all relates to web-send, if I was a customer video page, I
> think I could just always send an anchor tag and request introductions
> to web-send/bookmark type providers only, and be done with it.  I
> could also include bookmark/video[sic] types in my introduction
> requests, too.  A provider like facebook's would declare its support
> for bookmark and probably every other type of content, most long-tail
> providers would probably just use bookmark.  I think I understand how
> it all works, I'm just getting my head around practical use-cases for
> some of that deep type-specificity _within_ the bookmark realm.

The rationale for the MIME extension of the bookmark data-type is to
enable Providers to declare support for specific MIME types and so
only be presented as a choice when the user is sharing that kind of
content. For example, it's only useful to offer the image editing
Provider as an option when the shared link refers to an image. Think
of the Bookmark Introducer as potentially also being the MIME-based
application preference database for web-applications.

> For example if a photo site's provider registers itself as the image
> handler we discussed earlier, and then introduces a video capability
> (like flickr did) at some future point, users need to visit that site
> and allow it to request an updated registration for that new type in
> order to be able to leverage it.

No, once a user has accepted a registration, the registrant can update
it whenever it wants without any user interaction required. See:

http://web-send.org/introducer/#update

> I can imagine the browser prefs
> dialog that shows you all these type registrations and their icons,
> like the file extension registry, but I'm not totally sure how all
> that complexity simplifies the basic url-sharing use-case.

I've done away with that complexity by establishing user preferences
based on what the user actually does, instead of what they've
configured. The Introducer keeps track of which Providers are being
used most often and presents them as the top choice during a sharing
action. There's no configuration required. You can see the limited
configuration supported by clicking the "edit options..." option
presented during a sharing action. It's really only there to sever a
user's relationship with a particular web site, thus preventing it
from showing up during sharing actions.

The name only ever appears in code, not in the user interface. The
term "bookmark" is also meant to refer to the thing being transmitted,
not to what the Provider might do with it.

>>> - the spec reads as though it addresses the tweet/like/whatever count
>>> feature common to most sharing tools.  The fact that its the local
>>> client accounting that its really addressing might be useful to
>>> clarify.  In our experience the most common use-case for this feature
>>> is the instrumentation in an analytics system of the share events, I
>>> assume thats what you were thinking about as well?
>>
>> Both the Customer and the Provider have an opportunity to update an
>> analytics system, as both know when a sharing action has been
>> completed. An aggregator like AddThis is in a good position to collect
>> analytics from the Provider side, since it would see sharing actions
>> to multiple destination sites. Individual Customer sites can also
>> maintain their own analytics, since they see the completion of all
>> sharing actions. In the introducer.js default implementation, I've
>> attempted to make this collection easier for Customers by firing a
>> "bookmark" event, see:
>>
>> http://web-send.org/bookmark/#event
>>
>> Is there any other tooling you'd recommend here?
>>
>
> I think its just perhaps a clarification in the explanation -- when
> you talk about sharing tools, the counting feature tends to have,
> anecdotaly, a very specific definition.

What's the common definition? Does it mean a count maintained by the
Provider, instead of the Customer?

--Tyler

Will Meyer

unread,
Dec 1, 2010, 5:39:04 PM12/1/10
to oexc...@googlegroups.com

It would help I think with this and with a few related items to talk
in the spec (or in some kind of impleentors note) in terms of explicit
requirements on providers. What exactly does the provider need to do
to support the interop, what ui it controls, what expectations it
should have on the sizing of the windows in which it is rendered, etc.
Coming from the standpoint of having worked with hundreds of
providers, this kind of explicit info telling them how big their
interface is going to be etc is key.

>
>>>> - a rel type that can be used to decoratively identify content that
>>>> should be offerable to bookmarking services using this underlying
>>>> mechanism
>>>
>>> The "bookmark" rel type is already defined by HTML to be a permalink.
>>> As a convenience to Customers, the introducer.js default
>>> implementation initiates bookmark sharing when the user clicks on such
>>> a link.
>>
>> Right, I should say "designated" not defined.  I'll admit I've never
>> properly understood bookmark (by its formal definition anyway, I get
>> the common-use permalink version), and don't know the latest thinking
>> on it as it relates to things like canonical.  Regardless of whether
>> or not this is the same conceptual case as was originally intended
>> with rel bookmark, and whether existing bookmark-typed links would
>> really all want a share treatment popping up (e.g. you'll have a lot
>> of sharing icons popping up on blog post titles), I get it, its
>> optional as a suggested facility user agents could provide.
>
> ... that Customers could use. The user-agent's understanding of the
> protocol is limited to what's in the Web Introducer spec.

So given that, I assume that rather than the fallback provider
handling that's there now, that would instead just be a set of default
registered providers. I also thought that the UA would be attaching
introduction-invoking code to the bookmark items, without requiring
customer page devs to invoke introductions themselves.

Understood, thx.

That non-HTML case is what I'm driving at actually -- the difference
between sharing a youtube video page url with someone vs sharing the
url that is the src of a video element, which is such that the
different elements that are received can't necessarily be handled in
the same generic way on the provider side. For example, would
delicious' bookmark provider bookmark urls to youtube video element
src values? If I received an HTML-renderable URL along with it, I
could say oh well, I'll use that for now, and ignore the video.
Later, I upgrade my service, and now I can do more fancy stuff with
video content directly, and the customer and registration didn't need
to change. This is why I would suggest a sensibly navigable url as a
common requirement, with other type data additive, not a replacement.
This also shows that I don't fully understand how mime types tie into
the element types, and how it works if they don't -- if I say I accept
bookmark (and not any sub types), but then some customer sends me a
serialized video element, what am I practically supposed to do with
it? What is the customer intending if they request an introduction to
a provider of bookmark/image/png but then send a video element?

An html5 video site is a good practical example. To enable
bookmarking of the video page to delicious, playing of the video on
some local attached display device, posting of the video to your
facebook feed, tweeting about it, and translating the page with google
translate, all of which are currently-deployed practical cases, would
there be multiple different introducer requests, with different types
and callbacks, to provide straight anchors in some cases, video
elements in others, etc.? Maybe it would help if the introduction
response included the types that the provider actually got selected on
(so the customer could decide what to send). And what set of types
would each provider support? I can try and write this code out as
well to try and understand how it works.

>
>> As this all relates to web-send, if I was a customer video page, I
>> think I could just always send an anchor tag and request introductions
>> to web-send/bookmark type providers only, and be done with it.  I
>> could also include bookmark/video[sic] types in my introduction
>> requests, too.  A provider like facebook's would declare its support
>> for bookmark and probably every other type of content, most long-tail
>> providers would probably just use bookmark.  I think I understand how
>> it all works, I'm just getting my head around practical use-cases for
>> some of that deep type-specificity _within_ the bookmark realm.
>
> The rationale for the MIME extension of the bookmark data-type is to
> enable Providers to declare support for specific MIME types and so
> only be presented as a choice when the user is sharing that kind of
> content. For example, it's only useful to offer the image editing
> Provider as an option when the shared link refers to an image. Think
> of the Bookmark Introducer as potentially also being the MIME-based
> application preference database for web-applications.
>

Except that its not actually tied to the content that is provided
during the transaction, at least not in a way I have my head around
yet (per the previous discussion above).

>> For example if a photo site's provider registers itself as the image
>> handler we discussed earlier, and then introduces a video capability
>> (like flickr did) at some future point, users need to visit that site
>> and allow it to request an updated registration for that new type in
>> order to be able to leverage it.
>
> No, once a user has accepted a registration, the registrant can update
> it whenever it wants without any user interaction required. See:
>
> http://web-send.org/introducer/#update

Ok, so user doesn't need to allow, but site still needs to update its
registration, for which the user has to nav to the site (at least I
think they do).

To the extent that its in the name of the spec that you can use to
send videos to your friends on social networks, I think its perhaps
odd. Again, just silly semantics, nuff said.

>
>>>> - the spec reads as though it addresses the tweet/like/whatever count
>>>> feature common to most sharing tools.  The fact that its the local
>>>> client accounting that its really addressing might be useful to
>>>> clarify.  In our experience the most common use-case for this feature
>>>> is the instrumentation in an analytics system of the share events, I
>>>> assume thats what you were thinking about as well?
>>>
>>> Both the Customer and the Provider have an opportunity to update an
>>> analytics system, as both know when a sharing action has been
>>> completed. An aggregator like AddThis is in a good position to collect
>>> analytics from the Provider side, since it would see sharing actions
>>> to multiple destination sites. Individual Customer sites can also
>>> maintain their own analytics, since they see the completion of all
>>> sharing actions. In the introducer.js default implementation, I've
>>> attempted to make this collection easier for Customers by firing a
>>> "bookmark" event, see:
>>>
>>> http://web-send.org/bookmark/#event
>>>
>>> Is there any other tooling you'd recommend here?
>>>
>>
>> I think its just perhaps a clarification in the explanation -- when
>> you talk about sharing tools, the counting feature tends to have,
>> anecdotaly, a very specific definition.
>
> What's the common definition? Does it mean a count maintained by the
> Provider, instead of the Customer?

Exactly. Also re the eventing, the more common case, which does
violate the core premise of the spec and isn't supported, is that
publishers want to handle these analytics per-service. In other
words, knowing that the event happened is less interesting than
knowing to what service, at least in terms of analytics value.
Understood not possible in a world where the customer is not supposed
to know the providers. They do still get referers on the clickbacks,
of course, and they'll still see traffic being quantified that way,
and customers will still learn of the existence and usage rates of
various providers via those referers (at least until all referers on
the web go away ;-)).

Thanks again,

W

Tyler Close

unread,
Dec 8, 2010, 3:42:00 PM12/8/10
to oexc...@googlegroups.com

I've created a section called "Provider Cheatsheet" at:

http://web-send.org/bookmark/#provider

>>>>> - a rel type that can be used to decoratively identify content that
>>>>> should be offerable to bookmarking services using this underlying
>>>>> mechanism
>>>>
>>>> The "bookmark" rel type is already defined by HTML to be a permalink.
>>>> As a convenience to Customers, the introducer.js default
>>>> implementation initiates bookmark sharing when the user clicks on such
>>>> a link.
>>>
>>> Right, I should say "designated" not defined.  I'll admit I've never
>>> properly understood bookmark (by its formal definition anyway, I get
>>> the common-use permalink version), and don't know the latest thinking
>>> on it as it relates to things like canonical.  Regardless of whether
>>> or not this is the same conceptual case as was originally intended
>>> with rel bookmark, and whether existing bookmark-typed links would
>>> really all want a share treatment popping up (e.g. you'll have a lot
>>> of sharing icons popping up on blog post titles), I get it, its
>>> optional as a suggested facility user agents could provide.
>>
>> ... that Customers could use. The user-agent's understanding of the
>> protocol is limited to what's in the Web Introducer spec.
>
> So given that, I assume that rather than the fallback provider
> handling that's there now, that would instead just be a set of default
> registered providers.  I also thought that the UA would be attaching
> introduction-invoking code to the bookmark items, without requiring
> customer page devs to invoke introductions themselves.

I'm expecting Customer libraries, similar to the introducer.js script,
to do the attaching of introducer-invoking code to bookmarked items
and to provide reasonable defaults when the user doesn't have any
registered Providers. It is also possible that some user-agents might
ship with a set of default registered providers, in which case, the
Customer library default code would never be executed.

I think the video and the page surrounding the video are two different
things that the user might want to share in different ways. Such a
page might have a sharing link at the top for use in social
bookmarking, such as with Delicious. The URL shared in this case is
the URL for the page, not the video, and the shared element is an <a>
element. The <video> element itself might also support sharing, but
with a different intended set of Providers. For example, a video
transcoding service might register for only the
<http://web-send.org/bookmark/#video/> data-type and thus only be
offered when the user is sharing the video itself. The UX might be a
right click on the video to share the <video> element itself, versus a
click on a sharing icon at the top of the page to send a link to a
social bookmarking service.

> Later, I upgrade my service, and now I can do more fancy stuff with
> video content directly, and the customer and registration didn't need
> to change.

I think we only need to be concerned with changes to the Customer. We
should expect registrations to change easily and frequently.

>  This is why I would suggest a sensibly navigable url as a
> common requirement, with other type data additive, not a replacement.
> This also shows that I don't fully understand how mime types tie into
> the element types, and how it works if they don't -- if I say I accept
> bookmark (and not any sub types), but then some customer sends me a
> serialized video element, what am I practically supposed to do with
> it?

Whatever you normally do with a URL. Perhaps the user wanted to share
the video as a top level page, instead of embedded in a surrounding
page, and so shared the video element directly. Since this action has
to be enabled by the Customer page, the Customer page developer must
have had some reason for thinking this would be a good UX. In general,
since all sharing actions are initiated by a Customer page, the
developer must have thought doing so would provide a good UX. It's
certainly possible for a developer to create a poor UX using the
Introducer, but the API and suggested libraries are designed to
discourage that.

>  What is the customer intending if they request an introduction to
> a provider of bookmark/image/png but then send a video element?

As a Provider for the <http://web-send.org/bookmark/#image/>
data-type, I would assume this meant something should be done with the
image referred to by the <video>'s "poster" attribute.

In general, each Provider should look at the HTML definition of each
of the elements they might receive, determine a corresponding action
and communicate this action to the user via the "name" and
"description" meta-data on the Provider declaration. In some cases it
might be reasonable to reject some elements. For example, an image
Provider might have no reasonable way of acting on a <audio> element.
It would be unreasonable for a Customer to make such an introduction
request in the first place.

> An html5 video site is a good practical example.  To enable
> bookmarking of the video page to delicious, playing of the video on
> some local attached display device, posting of the video to your
> facebook feed, tweeting about it, and translating the page with google
> translate, all of which are currently-deployed practical cases, would
> there be multiple different introducer requests, with different types
> and callbacks, to provide straight anchors in some cases, video
> elements in others, etc.?

I think two separate introduce() invocations would be sufficient for
this case: one for the page and another for the video itself to handle
the playing the video on an attached display device case.

>  Maybe it would help if the introduction
> response included the types that the provider actually got selected on
> (so the customer could decide what to send).

It does. That's the first argument to the callback, see:

http://web-send.org/introducer/#api.Introducer.introduce.agreed

> And what set of types
> would each provider support?  I can try and write this code out as
> well to try and understand how it works.
>
>>
>>> As this all relates to web-send, if I was a customer video page, I
>>> think I could just always send an anchor tag and request introductions
>>> to web-send/bookmark type providers only, and be done with it.  I
>>> could also include bookmark/video[sic] types in my introduction
>>> requests, too.  A provider like facebook's would declare its support
>>> for bookmark and probably every other type of content, most long-tail
>>> providers would probably just use bookmark.  I think I understand how
>>> it all works, I'm just getting my head around practical use-cases for
>>> some of that deep type-specificity _within_ the bookmark realm.
>>
>> The rationale for the MIME extension of the bookmark data-type is to
>> enable Providers to declare support for specific MIME types and so
>> only be presented as a choice when the user is sharing that kind of
>> content. For example, it's only useful to offer the image editing
>> Provider as an option when the shared link refers to an image. Think
>> of the Bookmark Introducer as potentially also being the MIME-based
>> application preference database for web-applications.
>>
>
> Except that its not actually tied to the content that is provided
> during the transaction, at least not in a way I have my head around
> yet (per the previous discussion above).

I get that there's no defined mapping between MIME types and HTML link
elements, but I don't think it's a problem. I don't think it can cause
a misunderstanding between a Customer and a Provider.

>>> For example if a photo site's provider registers itself as the image
>>> handler we discussed earlier, and then introduces a video capability
>>> (like flickr did) at some future point, users need to visit that site
>>> and allow it to request an updated registration for that new type in
>>> order to be able to leverage it.
>>
>> No, once a user has accepted a registration, the registrant can update
>> it whenever it wants without any user interaction required. See:
>>
>> http://web-send.org/introducer/#update
>
> Ok, so user doesn't need to allow, but site still needs to update its
> registration, for which the user has to nav to the site (at least I
> think they do).

Yes, so if the user never visited any page from Flickr ever again,
Flickr would never get the opportunity to tell the user about their
new video service. Is that unreasonable?

Currently, there's no data on the "bookmark" event, but it could
include the data sent in the confirmation message from the Provider.
If a Provider chose to, it could disclose it's identity in this data.
I'll see about implementing that in the introducer.js library.

> Understood not possible in a world where the customer is not supposed
> to know the providers.

The constraint I'm aiming for is that this information is not required
to be disclosed, so that Providers that want to prevent their users
from being profiled can implement that protection.

>  They do still get referers on the clickbacks,
> of course, and they'll still see traffic being quantified that way,
> and customers will still learn of the existence and usage rates of
> various providers via those referers (at least until all referers on
> the web go away ;-)).

Thanks again for all the feedback. I spent a few hours working on the
documentation this morning and have uploaded updates. I intend to do
some more based on your other emails.

--Tyler

Will Meyer

unread,
Dec 14, 2010, 3:49:26 PM12/14/10
to oexc...@googlegroups.com

helpful!

Gotcha, we see it similarly.

Understood, thats what the spec supports. We might just have a subtly
different philosophy on it -- I think a Customer dev shouldn't really
have to think about it. I suppose as long as the introductions are
wrapped in other tools which help with this, the practical path is
reasonable.

>> Later, I upgrade my service, and now I can do more fancy stuff with
>> video content directly, and the customer and registration didn't need
>> to change.
>
> I think we only need to be concerned with changes to the Customer. We
> should expect registrations to change easily and frequently.
>
>>  This is why I would suggest a sensibly navigable url as a
>> common requirement, with other type data additive, not a replacement.
>> This also shows that I don't fully understand how mime types tie into
>> the element types, and how it works if they don't -- if I say I accept
>> bookmark (and not any sub types), but then some customer sends me a
>> serialized video element, what am I practically supposed to do with
>> it?
>
> Whatever you normally do with a URL. Perhaps the user wanted to share
> the video as a top level page, instead of embedded in a surrounding
> page, and so shared the video element directly. Since this action has
> to be enabled by the Customer page, the Customer page developer must
> have had some reason for thinking this would be a good UX. In general,
> since all sharing actions are initiated by a Customer page, the
> developer must have thought doing so would provide a good UX. It's
> certainly possible for a developer to create a poor UX using the
> Introducer, but the API and suggested libraries are designed to
> discourage that.

I'd just throw in that I don't think the customer or user wants to
think about all this. They customer has a video page, and what they
really want the browser and other tools to do is help users
efficiently and effectively interact with that content, make it viral,
etc -- whatever they want that increases their satisfaction. So
whether the user wants to, based on their habits and using tools that
personalize the experience based on them, send a video to their
mobile device, save it to disk, email it, or post it to facebook,
doesn't really matter to the Customer, and it shouldn't be too complex
to enable all of those cases. With the "url plus some" model, you can
support all of those without having to have different UX's and
different introductions using different type requests. In any case,
again this is just philosophical and perhaps moot as long as there can
be facilitating tools to help the practical implementation side.

>
>>  What is the customer intending if they request an introduction to
>> a provider of bookmark/image/png but then send a video element?
>
> As a Provider for the <http://web-send.org/bookmark/#image/>
> data-type, I would assume this meant something should be done with the
> image referred to by the <video>'s "poster" attribute.
>
> In general, each Provider should look at the HTML definition of each
> of the elements they might receive, determine a corresponding action
> and communicate this action to the user via the "name" and
> "description" meta-data on the Provider declaration. In some cases it
> might be reasonable to reject some elements. For example, an image
> Provider might have no reasonable way of acting on a <audio> element.
> It would be unreasonable for a Customer to make such an introduction
> request in the first place.
>

Could the spec help prevent cases that don't work in practice? I
think all this means is the mime typing corresponding to some
specificity on the element data passed (or always including a
navigable URL, which is my preference). Maybe I'm missing the
use-case for why its useful to have strongly-typed provider selection
and then still allow effectively untyped data on the input. Would be
easier to talk about this in IRC or something BTW.

>> An html5 video site is a good practical example.  To enable
>> bookmarking of the video page to delicious, playing of the video on
>> some local attached display device, posting of the video to your
>> facebook feed, tweeting about it, and translating the page with google
>> translate, all of which are currently-deployed practical cases, would
>> there be multiple different introducer requests, with different types
>> and callbacks, to provide straight anchors in some cases, video
>> elements in others, etc.?
>
> I think two separate introduce() invocations would be sufficient for
> this case: one for the page and another for the video itself to handle
> the playing the video on an attached display device case.
>
>>  Maybe it would help if the introduction
>> response included the types that the provider actually got selected on
>> (so the customer could decide what to send).
>
> It does. That's the first argument to the callback, see:
>
> http://web-send.org/introducer/#api.Introducer.introduce.agreed
>

Ah, agreed is the array of types, got it.

You're right, its not -- given that they could do the updated
registration in the context of an introduction on an image

I like it. I agree its important that providers can't see each other,
and see the argument on not seeing Customers (at least clickstream
directly, they still obv get data input), but if the providers choose
to expose themselves to Customers, that can only help the customer
imho.

Tyler Close

unread,
Dec 15, 2010, 1:00:04 PM12/15/10
to oexc...@googlegroups.com
On Tue, Dec 14, 2010 at 12:49 PM, Will Meyer <wi...@willmeyer.com> wrote:
> I'd just throw in that I don't think the customer or user wants to
> think about all this.  They customer has a video page, and what they
> really want the browser and other tools to do is help users
> efficiently and effectively interact with that content, make it viral,
> etc -- whatever they want that increases their satisfaction.  So
> whether the user wants to, based on their habits and using tools that
> personalize the experience  based on them, send a video to their
> mobile device, save it to disk, email it, or post it to facebook,
> doesn't really matter to the Customer, and it shouldn't be too complex
> to enable all of those cases.

...

>  In any case,
> again this is just philosophical and perhaps moot as long as there can
> be facilitating tools to help the practical implementation side.

Actually, I think this is exactly the sort of question that is
important to probe now. You're right that we want a protocol that
makes it as easy as possible for Users, Customers and Providers to
engage in sharing. Now's the time to shave off any warts.

>>>  What is the customer intending if they request an introduction to
>>> a provider of bookmark/image/png but then send a video element?
>>
>> As a Provider for the <http://web-send.org/bookmark/#image/>
>> data-type, I would assume this meant something should be done with the
>> image referred to by the <video>'s "poster" attribute.
>>
>> In general, each Provider should look at the HTML definition of each
>> of the elements they might receive, determine a corresponding action
>> and communicate this action to the user via the "name" and
>> "description" meta-data on the Provider declaration. In some cases it
>> might be reasonable to reject some elements. For example, an image
>> Provider might have no reasonable way of acting on a <audio> element.
>> It would be unreasonable for a Customer to make such an introduction
>> request in the first place.
>>
>
> Could the spec help prevent cases that don't work in practice?  I
> think all this means is the mime typing corresponding to some
> specificity on the element data passed (or always including a
> navigable URL, which is my preference).

Currently, the Bookmark Introducer sends an array of one HTML link
element. We could change this to an array of up to two HTML link
elements, where the first is always an <a> element for a navigable
resource and the second is an optional link element to a subordinate
resource. So when sharing a video, the first element is an <a> for the
surrounding page and the second is the <video> element.

I suppose we could also then further restrict the type of the optional
HTML element, so that if video/ is the agreed data-type, then the
optional element must be either video or object or embed or iframe.

>  Maybe I'm missing the
> use-case for why its useful to have strongly-typed provider selection
> and then still allow effectively untyped data on the input.

The strong-typing on provider selection allows the user-agent to
simplify the user's selection task by eliminating options that won't
work. The somewhat loose typing on the exchanged data can be handled
with a receiver-makes-right design for Providers which enables them to
interact with a wide-array of Customers. So the idea is to present the
user with the simplest set of options and then have the selected
parties do whatever it takes to make that work.

That said, I don't think there's any harm in pointing out the cases
that are truly silly, such as sending an <img> to an audio/ only
Provider. So, I'll do that.

>  Would be
> easier to talk about this in IRC or something BTW.

I've got a GMail window open most of the time and so can chat there.

...

>> Currently, there's no data on the "bookmark" event, but it could
>> include the data sent in the confirmation message from the Provider.
>> If a Provider chose to, it could disclose it's identity in this data.
>> I'll see about implementing that in the introducer.js library.
>
> I like it.  I agree its important that providers can't see each other,
> and see the argument on not seeing Customers (at least clickstream
> directly, they still obv get data input), but if the providers choose
> to expose themselves to Customers, that can only help the customer
> imho.

I've spec'ed this and implemented it. The spec text is at:

http://web-send.org/bookmark/#attribution

The current introducer.js code implements it.

Thanks,

Tyler Close

unread,
Dec 15, 2010, 2:33:26 PM12/15/10
to oexc...@googlegroups.com
On Wed, Dec 15, 2010 at 10:00 AM, Tyler Close <tyler...@gmail.com> wrote:
> Currently, the Bookmark Introducer sends an array of one HTML link
> element. We could change this to an array of up to two HTML link
> elements, where the first is always an <a> element for a navigable
> resource and the second is an optional link element to a subordinate
> resource. So when sharing a video, the first element is an <a> for the
> surrounding page and the second is the <video> element.

I've written up the spec text for this now. It's at:

http://web-send.org/bookmark/#data

This change is backwards compatible and so didn't require any changes
to the introducer.js implementation.

Reply all
Reply to author
Forward
0 new messages