Abstract

This week has a short introduction to Mantis, the issue tracking system that will be used for the course projects. Following this brief introduction, course projects will be discussed. The two projects are the Map Mapper project, which looks at ways to make map service URI interoperable across various services, and the Feed Feeds project, which is based on the idea of providing support for managing feed metadata. Both projects have back-end and front-end issues, and this course will mostly look at the front end issues.

Issue Tracking

• Often used as a bug tracking system for software development
• Issues are anything which needs resolution
  • bugs in an existing implementation
  • requests for a feature which should be added
  • ideas for future features which should be captured
• Issue tracking is not chatting
  • please do not have conversations using the system
  • each issue and each note should have substance to it
• Try to resolve issues to the point where they can be closed

Mantis Structure

• Users get a login and have access to the application
• Each installation can have multiple projects
  • users have access to the projects which are public or open to them
• Each project has a list of issues
  • the category describes which part of a project an issue is for
  • the severity describes how important the issue is
  • the status tracks an issue through its lifecycle (until it is closed)
• Categories identify well-defined parts of a project
  • issues entered for a category are assigned to a default user
  • issue assignment can be changed manually at any time
• Adding notes to an issue can be done in two ways
  • just adding a note without changing its status
  • changing its status and then adding the note which describes the status change
• Issues can be monitored to get emails about activities

Mapping Map URIs

• Map URIs are specific to some map service
  • they identify a location, but the location is hidden in the URI
• Location is becoming an important concept on the Web
  • most services are silos for location information
  • technically, this is caused by a lack of location support of the Web
  • economically, this is caused by the services' interest to serve ads
  • ideally, location on the Web should be identified by URI: geoloc:86.507942,28.031139
• Map Mapper allows users to switch between map services
  • as a Greasemonkey script it can dynamically rewrite map URIs
  • as a Firefox add-on it could add some configuration interface
  • the add-on could also rewrite the URI of the current page (map switching)

Map Mapper Map (Read)

<mapmap version="1" revision="$Rev: 155 $">
 <service id="google" separator="&amp;" match="^http://maps\.google\.com/maps" non-match="msid=\d+" name="Google Maps">
  <info href="http://mapki.com/wiki/Google_Map_Parameters" title="Google Map Parameters - Google Mapki"/>
  <read>
   <part id="address" pattern="q=(.*?)&amp;"/>
   <part id="lat" pattern="ll=(.*?),.*?&amp;"/>
   <part id="long" pattern="ll=.*?,(.*?)&amp;"/>
   <part id="view" pattern="t=(.*?)&amp;">
    <token pattern="m" value="map" default="yes"/>
    <token pattern="h" value="hybrid"/>
    <token pattern="k" value="satellite"/>
    <token pattern="p" value="physical"/>
   </part>

Map Mapper Map (Write)

  <write prefix="http://maps.google.com/maps?">
   <part base="address" pattern="q=$1"/>
   <part base="lat long" pattern="ll=$1,$2"/>
   <part base="view" pattern="t=$1">
    <token pattern="map" value="m" default="yes"/>
    <token pattern="hybrid" value="h"/>
    <token pattern="satellite" value="k"/>
    <token pattern="physical" value="p"/>
   </part>
   <part base="zoom" pattern="z=$1">
    <token pattern="19" value="19"/>
    <token pattern="18" value="18"/>
    <token pattern="17" value="17"/>
    <token pattern="16" value="16"/>
    <token pattern="15" value="15"/>
    <token pattern="14" value="14"/>

Client-Side Code

• Implement the mapping as a JavaScript library
  • should be relatively easy (regexes supported in JavaScript)
  • currently, the processing model is only implicitly defined (but that will change)
• Use the JavaScript library in a Greasemonkey script
  • easy testing of the library on the client side
  • no UI but maybe configuration through customized code
• Use the JavaScript library in a Firefox add-on
  • better integration into the browser
  • UI for service preference or choice between one or all services
  • mapping could also be applied to the address bar (map switching)
• Mapping table hardcoded into the script/library or loaded dynamically?

Server-Side Code

• Implement the mapping of URIs as a Web-based service
• Part of the Web-Based Services Course
• Greasemonkey and Add-On could also use such a service
• Server-side implementation has always the latest mapping table
• Mapped URIs could be collected
  • statistics about map service usage
  • statistics about map URI parameter usage (extract extra infos for statistics only?)

Managing Feed Metadata

• Feed usage is already substantial and rising
• Feeds are information on demand
• Feed management on the publishing side is non-existent
  • some platforms provide support, but there is no independent service
• Feed management on the consumer side happens in feed readers
  • lock-in to feed reader and no sharing of feed data with others
  • inability to easily switch between feed readers
• Feed Feeds are feeds containing feed metadata (i.e., meta-feeds)
  • allows reuse of existing technologies and tools for handling feeds
  • enables easy tracking of feed information by subscribing to a meta-feed
  • publishing of feed information can be supported through AtomPub

Feed Management

Feed Publishers

• Feed publishers often have little support for managing feed information
  • if they use a single platform, there may be some support for feed management
  • in heterogeneous scenarios, managing feed information becomes very hard
• The Feed Feed Web Service provides feed metadata management
  • the Web service can be accessed through its Atom/AtomPub interface
  • an additional UI allows the manual management of feeds (categorization)
  • additional features include generating views (directories) of feed feeds
• Feed publishers gain better control over their feeds
  • better access for their customers to find certain feeds
  • better understanding of the dependencies of feeds (aggregates/filters)

Feed Consumers

• Feed consumers use a feed reader for feed management
  • feed readers are limited in capabilities and device support
  • feed subscriptions should be managed in an open way
• Feed feeds for consumers should be like del.icio.us for feeds
  • tagging of feeds and exploring the usage of feeds by others
  • feed-specific features allow to link the feed URI with the resource URI
  • tag-specific research can be applied to feed-specific tag spaces
• Information be publishers and consumers can be combined
  • publishers get immediate feedback about tags, subscriptions, and collateral feeds
  • consumers get information about the publishing context of the feed

Design and Implementation

• The first weeks should be mainly about thinking about design
• Thinking about implementation informs the design
• Use cases make design & implementation more realistic
• Discussions help when making design & implementation decisions