際際滷

際際滷Share a Scribd company logo

OExchange Technical Intro

Download as PPTX, PDF
Will Meyer
Will Meyer

The document proposes an open protocol called OExchange to provide a standardized way for users to send URL-based content from any website to online services. The key aspects are: 1) Allow users to discover and personalize their preferred services for sharing, saving, translating content through a common protocol. 2) Define a basic solution where services have a standard "Offer" endpoint to receive URLs plus metadata, and an XRD file describing the service. 3) Specify an HTTP GET flow where the user's browser sends the URL and optional extras to the service's endpoint, then the service handles the content.

1 of 9
Download to read offline
OExchangeAn Open Protocol Stack for URL-Based Content Sharing on the Web(Quick Geek Remix)May 2010
What are we trying to do here? The Web includes an unbounded number of services for sharing, posting, translating, printing, saving for later, and moreGoal #1: Provide a simple, default way for users to send any URL-based content to any service on the webGoal #2: Allow users to personalize their choices, across tools, publishers, and machines
We Need an Open Protocol SolutionDiscoverPersonalizeExchangeA means to associate preferred services with a userA way to interrogate and discover services that can accept contentA common and simple way to send content, using its URI, to a serviceSupport forcurrently-deployed solutions, future new UX, and verbs beyond shareCurrent-generation tools:Focus on sharingTake the form of buttons, rows of chiclets, popup menus, toolbarsPresent too many choices; may not even include what the user wants
The Basic SolutionA standard endpoint, and a defined HTTP GET flow to send URLs to that endpointAn Offer endpoint takes standard arguments (always including URL); has browser control for the transactionAn XRD-based resource that describes the serviceA Target XRD document includes the endpoint and related information about the serviceHost-Meta and page-level Link tags make the service discoverableI accept URLs at my Offer endpoint:http://<me>/<whatever>?url=<url>&<etc>That and some info for humans is in my XRD doc:http://<me>/<whatever>/target.xrdYou can discover it from my host-meta or in-page Link tags:rel=http://oexchange.org//related-target
The Offer FlowBuild on a deployed browser-based paradigm (add headless modes once discovery is adopted)Enforce URLs as primary content indicators (supporting any tagging schemes)Plan for extensibility of verbs (offer is the most generic)Content source, in a users browserReceiving service (social network, translator, whatever)HTTP GET, usually target=_blankhttp://<service>/<whatever>?url=<url>&<etc>Service-specific UI; browser session up to serviceBrowser session continued
About TypingWere ALWAYS sending URLsURLs which are viewable in a browserURLs which may use any embedded tags (OGP, microformats, etc.)Were optionally sending extra stuffIframe URLs, images, rich media objectsThis gives us guaranteed compatibility, without ANY negotiationan ability to offer a richer experience for services that support it
Personalizing ChoicesIf you can send content to any service, and discover new services automaticallyLet a user store their preferencesLet all tools, including browsers, access ithttp://<service>http://<service>http://<service>WebFinger lookupPersonal XRD with OExchange linkshttp://<service>/target.xrdhttp://<service>/target.xrdhttp://<service>/target.xrdhttp://<service>/target.xrdmary@example.comOptional local cache
So What?For ServicesReceive more content, from a greater variety of tools and content providersFor UsersGet the right option at the right time for sharing, saving, blogging, whateverEngage with longer-tail communities of interestFor PublishersGet more of your content out, through more efficient share-throughDont have to decide between options
Taking it ForwardOur strategyCodify the existing model for basic content exchange on the web, while adding a new discovery capabilityAdd new exchange models once this foundation is deployedAdditional exchange modelsWith discovery in place, its easy to standardize more optimized exchange flowsHeadless and return-to-source are primary examplesUser addressing; mutual service negotiation in Send to Mom type use-casesLearn more at www.oexchange.org

More Related Content

OExchange Technical Intro

  • 1. OExchangeAn Open Protocol Stack for URL-Based Content Sharing on the Web(Quick Geek Remix)May 2010
  • 2. What are we trying to do here? The Web includes an unbounded number of services for sharing, posting, translating, printing, saving for later, and moreGoal #1: Provide a simple, default way for users to send any URL-based content to any service on the webGoal #2: Allow users to personalize their choices, across tools, publishers, and machines
  • 3. We Need an Open Protocol SolutionDiscoverPersonalizeExchangeA means to associate preferred services with a userA way to interrogate and discover services that can accept contentA common and simple way to send content, using its URI, to a serviceSupport forcurrently-deployed solutions, future new UX, and verbs beyond shareCurrent-generation tools:Focus on sharingTake the form of buttons, rows of chiclets, popup menus, toolbarsPresent too many choices; may not even include what the user wants
  • 4. The Basic SolutionA standard endpoint, and a defined HTTP GET flow to send URLs to that endpointAn Offer endpoint takes standard arguments (always including URL); has browser control for the transactionAn XRD-based resource that describes the serviceA Target XRD document includes the endpoint and related information about the serviceHost-Meta and page-level Link tags make the service discoverableI accept URLs at my Offer endpoint:http://<me>/<whatever>?url=<url>&<etc>That and some info for humans is in my XRD doc:http://<me>/<whatever>/target.xrdYou can discover it from my host-meta or in-page Link tags:rel=http://oexchange.org//related-target
  • 5. The Offer FlowBuild on a deployed browser-based paradigm (add headless modes once discovery is adopted)Enforce URLs as primary content indicators (supporting any tagging schemes)Plan for extensibility of verbs (offer is the most generic)Content source, in a users browserReceiving service (social network, translator, whatever)HTTP GET, usually target=_blankhttp://<service>/<whatever>?url=<url>&<etc>Service-specific UI; browser session up to serviceBrowser session continued
  • 6. About TypingWere ALWAYS sending URLsURLs which are viewable in a browserURLs which may use any embedded tags (OGP, microformats, etc.)Were optionally sending extra stuffIframe URLs, images, rich media objectsThis gives us guaranteed compatibility, without ANY negotiationan ability to offer a richer experience for services that support it
  • 7. Personalizing ChoicesIf you can send content to any service, and discover new services automaticallyLet a user store their preferencesLet all tools, including browsers, access ithttp://<service>http://<service>http://<service>WebFinger lookupPersonal XRD with OExchange linkshttp://<service>/target.xrdhttp://<service>/target.xrdhttp://<service>/target.xrdhttp://<service>/target.xrdmary@example.comOptional local cache
  • 8. So What?For ServicesReceive more content, from a greater variety of tools and content providersFor UsersGet the right option at the right time for sharing, saving, blogging, whateverEngage with longer-tail communities of interestFor PublishersGet more of your content out, through more efficient share-throughDont have to decide between options
  • 9. Taking it ForwardOur strategyCodify the existing model for basic content exchange on the web, while adding a new discovery capabilityAdd new exchange models once this foundation is deployedAdditional exchange modelsWith discovery in place, its easy to standardize more optimized exchange flowsHeadless and return-to-source are primary examplesUser addressing; mutual service negotiation in Send to Mom type use-casesLearn more at www.oexchange.org