This section deals with mechanisms for sharing wrappers, including mechanisms for setting up a metadata repository, to which wrapper developers can contribute wrappers and wrapper users can download them. Such mechanisms concern the metadata structure for bookkeeping of wrappers contributed by the wrapper developers and the procedures for wrapper users to download the chosen wrapper software. In a nutshell, we provide a WrapperRepository object, whose install(...) and download(...) methods implement this functionality.
The method install(...) specifies the properties of the wrapper software, including the wrapper name, the URL to be used to fetch the wrapper code, the type of URL (such as ftp or http), the programming language in which the wrapper is written, whether the wrapper is hand-written or generated by a toolkit, the name and contact information of the creator of the wrapper software, the project and organization names where the wrapper is produced, and the documentation information.
The method download(...) specifies the wrapper name, the version number, the platform in which the wrapper is to be used, the destination URL to which the wrapper software is to be shipped, the name, email, and organization of the user who is going to use the wrapper software, a brief description of the context in which the wrapper is to be used.
The design of the wrapper metadata repository has to deal with a number of issues. The first issue is how to handle broken wrappers. One of the main reasons for broken wrappers is that sites change their content or presentation formats, therefore breaking wrappers that rely on the earlier format. Several mechanisms can be used to facilitate the notification that a wrapper is broken. A simple way is to set up a bulletin board where any user can post a complaint flag that a wrapper is broken and provide a short description of the problem. Another mechanism is to provide an automatic test method for each wrapper repository, which periodically test whether the wrappers are still working. If a wrapper is broken, a complaint flag is posted. When a wrapper is to be downloaded or invoked, the user can first check if any complaint have been posted. The second issue is how to encode information about wrappers and complaints. We can either encode the wrapper metadata and wrapper complaints using a formal language, a self-describing semi-structured language such as XML, or using natural language. In the current implementation of WPstore, we use the relational database as the repository and the XML language as the presentation format. The third issue is how to manage new releases of a wrapper and what sort of version control facility should be provided. Wrappers need to be updated whenever the corresponding sites change their content and presentation format, and the changes cannot be adapted automatically by the current wrapper. A simple version control mechanism is to provide a method that can track the new release of the wrappers and thus facilitates applications to decide whether an updated wrapper is available.