URL Content Type

[resplin]

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com

Community Contribution IdeasDesign DiscussionsContent Modeling
This page contains work-in-progress for a new content type to hold a URL-linked file. Feel free to join the discussion and add your wishes, suggestions, and criticism.

Note: So far, the content of this page has been written by community members and may therefore contain mistakes or misconceptions.

Goals

Alfresco currently provides content types to hold documents but does not
offer a feature-rich content type to represent external documents, such as
PDF-files referenced via a URL.

Such a type should in its most basic form hold the URL path. Several
additional features and properties may be present if needed and
applicable.

1. Availability check: Check whether the referenced resource is available. For URLs with the URI scheme 'http:', for instance, it can [always?]  be   checked whether the resource is available. If not (case of a 404, etc.),     some customizable action can be executed.
   
2. Periodical availability checks: Perform 1. at regular intervals.
   
3. Maintain a local copy of the resource described by the URL.   For files (like ;http://example.com/file.pdf') a copy of it is     cached. For the URL 'http://www.google.com' the HTML page would be kept     (not including images and other files referenced therein).     Initially, only the URI scheme 'http:' will be supported; some schemes     might not allow this sort of caching (like 'mailto:') and for others,     support might be added later (like RealPlayer streams).
   
4. Change check: Check whether the resource at the URL changed.     For files (like 'http://example.com/file.pdf') this should amount to     checking whether the external file changed.    If a change is observed, some customizable action can be executed.
   
5. Periodical change check: Perform 4. at regular intervals.
   

Proposed implementation


2.1. The content type URL


 The content type, called 'URL', inherits from cm:content and carries an
 additional property called 'url' (of type string) that holds the
 URL. Initially, the inherited property 'content' is null, so any attempt to
 access the content will result in a warning about there being no content.

 Only feature (1.1) (Availability check) is implemented for this most basic
 form of URLs. [(1.1) might require additional properties to keep track of
 which action to perform?]  All additional features are implemented via
 aspects and aspect behaviours.  In the Web Client there is an action 'Check
 availability' for feature (1.1).

 [Relation to Links Management?]
 

2.2  Aspects

 The following aspects can be applied to an instance of content type URL:
 [Please revise the names of the aspects; any better-sounding names?]

 1. 'periodically-checkable', implementing feature (1.2).

    Property 'interval; [in minutes, or whatever -- does Alfresco have
    something like this?] and a repeatedly executed check with a customizable
    action as the behaviour.  [What is the mechanism in Alfresco to attach
    customizable actions?]  [Should we add date of last check as a property?]

    [Should we do this via http://wiki.alfresco.com/wiki/Scheduled_Actions?]

 2. 'cachable', implementing feature (1.3).

    No properties, but behaviour sets the 'content' property (inherited by
    cm:content) to the resource at the URL at creation and update time.

    [Or should we implement URL as a subclass of sys:base and give aspect
    'cachable' a property 'content'?]

 3. 'monitorable', implementing features (1.4) and (1.5).

    Property 'interval' and a repeatedly executed update check with a
    customizable action as the behaviour.

    In order to implement this, it would probably be easiest to always
    enforce aspect 'cachable' whenever 'monitorable' is applied [can this be
    done in Alfresco?].  In this way, a 'change check' amounts to comparing
    the resource to the currently cached copy. Otherwise, we would have to
    ressort to a solution in which only a hash of the resource is stored, as
    an aspect property. (Then, however, we might miss some changes in case
    the new, updated resource happens to have the same hash as the previous
    one.)

  We should provide a default action for aspect 'monitorable' that, when
  exectuted due to a successful change check, updates the cached version (in
  case aspect 'cachable' is present).