Users don’t have to use drupal variables.

I thank you for the review. I have checked the modules mentioned and provided the reasons if they are not covered by Ulink.

Filters covered by Ulink module completely or partially or can be covered programmatically by extending the module:

LinkFilter: http://www.aczoom.com/cms/software/web/link-filter-drupal-module
Specifically, this addresses these following cases - may be good if these use-cases can be handled by your project so can use a single filter for many uses!
(from the LinkFilter blurb): Would be good to have a filter that can handle a Drupal link, an external web link, or a local non-Drupal link. Prefixes representing the site url and the Drupal directory should be added, as appropriate:
1) Site url is prefixed if URL begins with a / character
2) No prefix is added if the URL has a : in it, as in http: or ftp: etc
3) Site url with Drupal base directory is prefixed in all other cases
Examples, assuming site is at http://example.com, and Drupal is installed in a sub-directory named drupal:
[l:node/281 Blue Sun] → Blue Sun
[l:travel/blue-sun] → travel/blue-sun
[l:/pub/download.zip Download] → Download
[l:http://www.example.com/ Example Web Site!] → Example Web Site!

All except (3) is covered, and (3) can be used under others category, using PHPcode of implementation. However, it is purposefully left in the default implementation due to the following reason. /pub can be a sub directory of example.com or example.com/drupal. If it is of example.com/drupal, user must have explicitly submitted /drupal/pub/download.zip and this can be achieved by the relative url for the site as giving that directly without modifying.

1.a) Context Links - http://drupal.org/project/contextlinks, uses Drupal url()
[?class:URL link text]
1.b)URL Class Filter
A simple filter which adds a CSS-class to each URL according to its target. This lets you easily distinguish between internal and external URLs, and assign a unique style to each URL based on its destination.
e.g. erdfisch :: blogs becomes erdfisch :: blogs.
1.c Outgoing links filter http://drupal.org/project/olf
adds in a configurable CSS classname to all outgoing links

Any attributes, including classes can be added as properties.
eg: [l|node/5|my node|class=node]
However, please note other modules extending ulink may not follow that and simply ignore the attributes.

2) Path Filter http://drupal.org/project/pathfilter
Uses Drupal url() function: "internal:node/23?page=1#section2" ->
"http://example.com/mysite/node/23?page=1#section2"

Covered by node type and comment type. please note other modules extending ulink may not follow that.

3) Relative Link Filter: http://drupal.org/project/rellinkfilter
It converts relative URLs to be relative to their current location, not the Drupal home directory.

The use of the module is trivial in the case of a cms using database as the way of storing content and static pages are not available normally. However, by extending node type (in case path alias is used to simulate hierarchical order) or others type this can be implemented.

4)Freelinking module - http://drupal.org/project/freelinking

Partially covered (The scope that comes under filter)

5) Macrotags module - http://drupal.org/project/macrotags

The scope of such filters is totally different. ulink targets the filters of links. However, it supports adding time, user name, site name and other tags through token module, which is the second type of implementation given in the default implementation.

Also the following modules are covered partially where it is appropriate and they can be totally implemented within ulink by adding the PHP code through PHPcode implementation or by extending proper types of the links. Most of the configurations are written with the balance between implementation on the fly and flexibility. (please add other filters that are covered to the list)
1. inline
2. amazon

Thanks for the follow up and explanation

I would like to point out that we have already categorized internal links (ie drupal links) such as node, comment, files and user. Then internal links are checked for file_exsists(), from which it is identified as an internal file. (no need for protocol checking). All others are assumed to be external.

Users don’t have to use drupal variables. For node, comment, files and user default implementation call url() which gives the complete path. However those who implements the PHP code should make sure that they call url(), still no need for drupal path variables.
Please note that drupal_get_normal_path is already executed upon the path sent in the link array.

External files have special tag associated in the link array (external = true). So the implementing function could provide different implementations for internal and external files.

I am sure I’ve answered your questions, and please do follow up if I miss any.

I'd suggest looking at http://mwt.argz.com/ulink/tests which shows a very good cross section of the various types of links that ulink handles. Note that this is just a small subset of what is possible with all the configuration options and module hook possibilities. ulink might not cover every feature (yet) of the other filters mentioned here but its well on its way to becoming the base for implementing any link type functionality needed. The one exception is Drupals built in url filtering for hard links like , http://mwt.argz.com, which remains a separate and useful filter - ulink is not looking for anything not inside the [l] syntax.

http://mwt.argz.com/ulink/gallery shows a good example of how a module can extend the link filtering and/or leverage other link filtering provided by ulink.

What is really needed at this point for the Summer of Code project to be successful is for competent people like bwooster47 to download and try it out and report bugs and missing features.

well said dledge,

We encourage the drupal community to download, test and make comments on the project. I would also like to state one issue here. Other than being able to use default implementation, Token implementation and PHPcode users can override the whole setup by writing a new module implementing the hooks.

Further more than one output can be combined together (strictly or optionally), which leads to enormous options.
I'll post some testing cases with such dynamic cascading to http://mwt.argz.com/ulink/tests

Thanks again.