• Saturday September 23rd 2017
• Do you want fries with that project?

Skip to Content

liveurls

resources:	Home Mailing List Technology Installation Source Code Members Bugs Screenshots



The technology behind LiveURLs

LiveURLs is a novel approach, which uses URL fragment identifiers smartly, to enable HTTP clients to address content, independent of its original representation. LiveURLs was an idea conceptualized by InfyLUG as part of its research on internet and web technologies.

Overview

The LiveURLs extension allows users to create links to any portion of a web page. The extension allows users to exchange portions of webpages using links i.e. URLs. The user only needs to select the content that he wants to share and create a URL(link) for that content from the context menu (the menu that pops up on a right-click). This newly created URL/link when viewed with a browser, which has the LiveURL extension installed, will show the selected content with a highlight. The URLs created using this extension are called LiveURLs.

Benefits of using LiveURLs

• Sharing specific content is just a right click away
• Peer-Peer - no intermediate server required
• Usable in the same manner as existing URLs
• Browsers which do not support LiveURLs still show the whole page
• LiveURLs can be used as a bookmark within a web page

The gory details

LiveURLs use the fragment identifier portion of the URL to denote the selected range. The fragment identifier of a LiveURL is dynamically created based on the selection. Two types of LiveURLs are currently supported. They differ based on how they specify the location of the content that was selected.

• Content - the fragment identifier contains parameters that is specific to the text content of the selection
• Position of content - the fragment identifier contains parameters about position of the selected content in the DOM tree (based on the Ahoy method)

Content based LiveURLs

The fragment ID of a content based LiveURL consists of the following parameters

1. Length of the starting word of the selection (upto a maximum of 5 characters)
2. Starting word
3. Character length of the selection
4. CRC Checksum of the selection

(we refer to the above as parameters 1, 2, 3, 4 in the following discussion)

Format

sSl+c

where

• s is length of the starting word of selection
• S is the starting word of selection
• l is the length of the total selection
• + is a delimiter
• c is the checksum

On the browser that creates LiveURLs, the above parameters are calculated from the selected range. Only text type HTML nodes in the selected range are used for this purpose. These parameters are added to the URL and the URL is copied to the clipboard.

On the browser that processes the LiveURLs, a string is constructed out of all the text nodes of the document and the starting word (parameter 2) is searched for in this string. Once the starting word is located, a substring equal to the length of the selection (parameter 3) made by the sender is created and its checksum is validated against the checksum passed as part of the URL (parameter 4). If there is a match, then the corresponding section is highlighted.

The content based approach is best suited when text based content is to be shared. We are working at enhancing it to include non-text nodes too by associating unique text content with non-text based nodes.

Limitations

• Since only text based nodes are used for the creation of the LiveURL, location of non-text type HTML nodes is not possible
• Multiple instances of the same content (duplicate text) will result in multiple highlights
• Selection of a single character in a big page results in considerable processing time for the extension to display all the characters (Though this is an unlikely case, we need an optimal way to handle this. Maybe disable users from selecting very small portions of the string :))

Position based LiveURLs

The fragment ID of a position based LiveURL consists of the following components.

1. Parent Node's ID or Parent Node's Index in the DOM tree
2. A child node offset, which indicates which child (i.e. the number of the child) of the parent, the selected node is
3. The offset of exact end-point of selection within the child node

The position based implementation uses the Ahoy project's methodology to identify positions in a DOM tree uniquely. The Ahoy project's web page has a very detailed description of this method. LiveURLs differs from the Ahoy project in the placement of this information. In the Ahoy implementation, this information is a part of the "query string" portion of the URL, whereas in the case of LiveURLs it is a part of the fragment identifier.

This method is preferable for content that occupies a particular position on a web page.

Limitations

• Since the position based LiveURLs are DOM based, even the smallest change in the DOM structure of the page will result in the failure of the LiveURL. This limitation is significant because a lot of pages today have (blogs for example) dynamically generated ads as part of them, which pretty much ensures that no two rendering instances of a DOM structure of the same page are similar.

What needs to be done

• Standardize on one approach for the extension, either the content based one or the position based one so that users have it easy. For this we badly need the user community's feedback.
• Can this behaviour be standardized? Is it possible to get this functionality done across all popular browsers
• Make the phrase RTFH (Read the Fine Highlight) as ubiquitous as RTFM ;)

So, thats it folks. Thanks for reading.