Login       -       Change Password       -       Recent Changes       -       Search:

InterStream Overview

InterStream FAQ

Working Groups

Governance

Technology and Standards

WiKi Help

edit SideBar

MediaGridObjects

InterStream.MediaGridObjects History

Hide minor edits - Show changes to markup

April 15, 2010, at 12:48 PM PST by jwgt -
Changed line 3 from:

Media Grid objects (MGOs) are rich media objects either orginated from inside the Media Grid. Permanent objects inside the grid have meta data associated with them as specified by the by the handle system's meta-data schema. Temporary objects, such as those streamed from an outside URL, may be cached within the Media Grid to improve performance to a termination element on the grid, such as an ISTP client (Media Grid Client) with the plugin. Objects have the same properties as handles. The handle system, as specified in RFC 3650, was designed to overcome the limitiations of URLs and has the following properties as outlined in the RFC. These properties provide a sound basis for the Media Grid architecture and objects within the grid.

to:

Media Grid objects (MGOs) are rich media objects either orginated from inside the Media Grid or Uploaded to the Media Grid via Secure Media Grid Clients. Permanent objects inside the grid have meta data associated with them as specified by the by the handle system's meta-data schema. Temporary objects, such as those streamed from an outside URL, may be cached within the Media Grid to improve performance to a termination element on the grid, such as an ISTP client (Media Grid Client) with the plugin. Objects have the same properties as handles. The handle system, as specified in RFC 3650, was designed to overcome the limitiations of URLs and has the following properties as outlined in the RFC. These properties provide a sound basis for the Media Grid architecture and objects within the grid.

April 15, 2010, at 12:39 PM PST by jwgt -
Changed line 3 from:

Media Grid objects (MGOs) are rich media objects either orginated from inside the Media Grid. Permanent objects inside the grid have meta data associated with them as specified by the by the handle system's meta-data schema. Temporary objects, such as those streamed from an outside URL, may be cached within the Media Grid to improve performance to a termination element on the grid, such as an ISTP client with the plugin. Objects have the same properties as handles. The handle system, as specified in RFC 3650, was designed to overcome the limitiations of URLs and has the following properties as outlined in the RFC. These properties provide a sound basis for the Media Grid architecture and objects within the grid.

to:

Media Grid objects (MGOs) are rich media objects either orginated from inside the Media Grid. Permanent objects inside the grid have meta data associated with them as specified by the by the handle system's meta-data schema. Temporary objects, such as those streamed from an outside URL, may be cached within the Media Grid to improve performance to a termination element on the grid, such as an ISTP client (Media Grid Client) with the plugin. Objects have the same properties as handles. The handle system, as specified in RFC 3650, was designed to overcome the limitiations of URLs and has the following properties as outlined in the RFC. These properties provide a sound basis for the Media Grid architecture and objects within the grid.

April 15, 2010, at 12:37 PM PST by jwgt -
Changed line 3 from:

Media Grid objects (MGOs) are rich media objects either orginated from inside the Media Grid or via an ordinary URL transferred from outside of it. Permanent objects inside the grid have meta data associated with them as specified by the by the handle system's meta-data schema. Temporary objects, such as those streamed from an outside URL, may be cached within the Media Grid to improve performance to a termination element on the grid, such as an ISTP client with the plugin. Objects have the same properties as handles. The handle system, as specified in RFC 3650, was designed to overcome the limitiations of URLs and has the following properties as outlined in the RFC. These properties provide a sound basis for the Media Grid architecture and objects within the grid.

to:

Media Grid objects (MGOs) are rich media objects either orginated from inside the Media Grid. Permanent objects inside the grid have meta data associated with them as specified by the by the handle system's meta-data schema. Temporary objects, such as those streamed from an outside URL, may be cached within the Media Grid to improve performance to a termination element on the grid, such as an ISTP client with the plugin. Objects have the same properties as handles. The handle system, as specified in RFC 3650, was designed to overcome the limitiations of URLs and has the following properties as outlined in the RFC. These properties provide a sound basis for the Media Grid architecture and objects within the grid.

March 14, 2009, at 10:58 AM PST by jlt - added MGO
Changed line 3 from:

Media Grid objects are rich media objects either orginated from inside the Media Grid or via an ordinary URL transferred from outside of it. Permanent objects inside the grid have meta data associated with them as specified by the by the handle system's meta-data schema. Temporary objects, such as those streamed from an outside URL, may be cached within the Media Grid to improve performance to a termination element on the grid, such as an ISTP client with the plugin. Objects have the same properties as handles. The handle system, as specified in RFC 3650, was designed to overcome the limitiations of URLs and has the following properties as outlined in the RFC. These properties provide a sound basis for the Media Grid architecture and objects within the grid.

to:

Media Grid objects (MGOs) are rich media objects either orginated from inside the Media Grid or via an ordinary URL transferred from outside of it. Permanent objects inside the grid have meta data associated with them as specified by the by the handle system's meta-data schema. Temporary objects, such as those streamed from an outside URL, may be cached within the Media Grid to improve performance to a termination element on the grid, such as an ISTP client with the plugin. Objects have the same properties as handles. The handle system, as specified in RFC 3650, was designed to overcome the limitiations of URLs and has the following properties as outlined in the RFC. These properties provide a sound basis for the Media Grid architecture and objects within the grid.

January 23, 2007, at 10:09 PM PST by jlt -
Changed lines 5-6 from:

From RFC 3650:

to:

From RFC 3650:

January 23, 2007, at 10:09 PM PST by jlt - more infor
Changed lines 1-2 from:

InterStream Media Grid Objects

to:

InterStream Media Grid Objects

Changed line 36 from:

The Handle System supports a distributed service model by allowing local services to be distributed across the Internet.

to:

The Handle System supports a distributed service model by allowing local services to be distributed across the Internet. InterStream uses location resolution process to locate the 'best' location to originate the URL or Handle. After the object has been originated, the grid provides a resilient framework to ensure the end-user receives a high quality experience.

January 20, 2007, at 06:15 PM PST by jlt - opening on how Media grid adheres to principles; reformat
Changed line 4 from:
to:

Changed lines 7-8 from:

Traditional URLs (Uniform Resource Locators) [4] allow certain Internet resources to be named as a combination of a DNS name and local name. The local name may be a local file path, or a reference to some local service (e.g., a cgi-bin script). This combination of a DNS name and a local name provides a flexible administrative model for naming and managing individual Internet resources. However, the URL practice also has some key limitations. Most URL schemes (e.g., http) are defined for resolution only. Any URL administration has to be done either at the local host, or via some other network service such as NFS. Using a URL as a name typically ties the Internet resource to its current network location. For example, a URL will be tied to its local file path when the file path is part of the URL. When the resource moves from one location to another for whatever reason, the URL breaks. It is especially difficult to work around this problem when the reason for the location change is change in ownership of an asset, as ownership is generally reflected in the domain name.

to:

Traditional URLs (Uniform Resource Locators) allow certain Internet resources to be named as a combination of a DNS name and local name. The local name may be a local file path, or a reference to some local service (e.g., a cgi-bin script). This combination of a DNS name and a local name provides a flexible administrative model for naming and managing individual Internet resources. However, the URL practice also has some key limitations. Most URL schemes (e.g., http) are defined for resolution only. Any URL administration has to be done either at the local host, or via some other network service such as NFS. Using a URL as a name typically ties the Internet resource to its current network location. For example, a URL will be tied to its local file path when the file path is part of the URL. When the resource moves from one location to another for whatever reason, the URL breaks. It is especially difficult to work around this problem when the reason for the location change is change in ownership of an asset, as ownership is generally reflected in the domain name.

Changed lines 13-92 from:
  • Uniqueness: Every handle is globally unique within the Handle
    System.
  • Persistence: Handles may be used as persistent identifiers for
    Internet resources. A handle does not have to be derived from
    the entity that it names. While an existing name, or even a
    mnemonic, may be included in a handle for convenience, the only
    operational connection between a handle and the entity it names
    is maintained within the Handle System. This of course does
    not guarantee persistence, which is a function of
    administrative care. But it does allow the same name to
    persist over changes of location, ownership, and other state
    conditions. For example, when a named resource moves from one
    location to another, the handle may be kept valid by updating
    its value in the Handle System to reflect the new location.
  • Multiple Instances: A single handle can refer to multiple
    instances of a resource, at different and possibly changing
    locations in a network. Applications can take advantage of
    this to increase performance and reliability. For example, a
    network service may define multiple entry points for its
    service with a single handle so as to distribute the service
    load.
  • Multiple Attributes: A single handle can refer to multiple
    attributes of a resource, including associated services,
    available through any method at different and possibly changing
    network locations. Handles can thus be used as persistent
    entry points into an evolving world of services associated with
    identified resources.
  • Extensible Namespace: Existing local namespaces may join the
    handle namespace by acquiring a unique handle naming authority.
    This allows local namespaces to be introduced into a global
    context while avoiding conflict with existing namespaces. Use
    of naming authorities also allows delegation of service, both
    resolution and administration, to a local handle service.
  • International Support: The handle namespace is based on Unicode
    3.0 [17], which includes most of the characters currently used
    around the world. This allows handles to be used in any native
    environment. The handle protocol mandates UTF-8 [5] as the
    encoding used for handles.
  • Distributed Service Model: The Handle System defines a
    hierarchical service model such that any local handle namespace
    may be serviced by a corresponding local handle service, by the
    global service, or by both. The global service, known as the
    Global Handle Registry, can be used to dispatch any handle
    service request to the responsible local handle service. The
    distributed service model allows replication of any given
    service into multiple service sites, and each service site may
    further distribute its service into a cluster of individual
    servers. (Note that local here refers only to namespace and
    administrative concerns. A local handle service could in fact
    have many service sites distributed across the Internet.)
  • Secured Name Service: The Handle System allows secured name
    resolution and administration over the public Internet. The
    Handle System protocol defines standard mechanisms for both
    client and server authentication, as well as service
    authorization. It also provides security options to assure
    data integrity and confidentiality.
  • Distributed Administration Service: Each handle may define its
    own administrator(s) or administrator group(s). Ownership of
    each handle is defined in terms of its administrator or
    administrator groups. This, combined with the Handle System
    authentication protocol, allows any handle to be managed
    securely over the public network by its administrator at any
    network location.
  • Efficient Resolution Service: The handle protocol is designed
    to allow highly efficient name resolution performance. To
    avoid resolution being affected by computationally costly
    administration service, separate service interfaces (i.e.,
    server processes and their associated communication ports) for
    handle name resolution and administration may be defined by any
    handle service.
to:
  • Uniqueness: Every handle is globally unique within the Handle System.
  • Persistence: Handles may be used as persistent identifiers for Internet resources. A handle does not have to be derived from the entity that it names. While an existing name, or even a mnemonic, may be included in a handle for convenience, the only operational connection between a handle and the entity it names is maintained within the Handle System. This of course does not guarantee persistence, which is a function of administrative care. But it does allow the same name to persist over changes of location, ownership, and other state conditions. For example, when a named resource moves from one location to another, the handle may be kept valid by updating its value in the Handle System to reflect the new location.
  • Multiple Instances: A single handle can refer to multiple instances of a resource, at different and possibly changing locations in a network. Applications can take advantage of this to increase performance and reliability. For example, a network service may define multiple entry points for its service with a single handle so as to distribute the service load.
  • Multiple Attributes: A single handle can refer to multiple attributes of a resource, including associated services, available through any method at different and possibly changing network locations. Handles can thus be used as persistent entry points into an evolving world of services associated with identified resources.
  • Extensible Namespace: Existing local namespaces may join the handle namespace by acquiring a unique handle naming authority. This allows local namespaces to be introduced into a global context while avoiding conflict with existing namespaces. Use of naming authorities also allows delegation of service, both resolution and administration, to a local handle service.
  • International Support: The handle namespace is based on Unicode 3.0, which includes most of the characters currently used around the world. This allows handles to be used in any native environment. The handle protocol mandates UTF-8 as the encoding used for handles.
  • Distributed Service Model: The Handle System defines a hierarchical service model such that any local handle namespace may be serviced by a corresponding local handle service, by the global service, or by both. The global service, known as the Global Handle Registry, can be used to dispatch any handle service request to the responsible local handle service. The distributed service model allows replication of any given service into multiple service sites, and each service site may further distribute its service into a cluster of individual servers. (Note that local here refers only to namespace and administrative concerns. A local handle service could in fact have many service sites distributed across the Internet.)
  • Secured Name Service: The Handle System allows secured name resolution and administration over the public Internet. The Handle System protocol defines standard mechanisms for both client and server authentication, as well as service authorization. It also provides security options to assure data integrity and confidentiality.
  • Distributed Administration Service: Each handle may define its own administrator(s) or administrator group(s). Ownership of each handle is defined in terms of its administrator or administrator groups. This, combined with the Handle System authentication protocol, allows any handle to be managed securely over the public network by its administrator at any network location.
  • Efficient Resolution Service: The handle protocol is designed to allow highly efficient name resolution performance. To avoid resolution being affected by computationally costly administration service, separate service interfaces (i.e., server processes and their associated communication ports) for handle name resolution and administration may be defined by any handle service.

Adherence to the Handle System Principles with InterStream Media Grid Objects

The Handle System supports a distributed service model by allowing local services to be distributed across the Internet.

January 20, 2007, at 04:40 PM PST by jlt - updated intro
Changed lines 3-4 from:

Media Grid objects are rich media objects either orginated from inside the Media Grid or via an ordinary URL transferred from outside of it. Permanent objects inside the grid have meta data associated with them as specified by the by the handle system's meta-data schema. Temporary objects, such as those streamed from an outside URL, may be cached within the Media Grid to improve performance to a termination element on the grid, such as an ISTP client with the plugin. Objects have the same properties as handles. The handle system, as specified in RFC 3650, has the following properties for these objects and provides a sound basis for the Media Grid architecture.

to:

Media Grid objects are rich media objects either orginated from inside the Media Grid or via an ordinary URL transferred from outside of it. Permanent objects inside the grid have meta data associated with them as specified by the by the handle system's meta-data schema. Temporary objects, such as those streamed from an outside URL, may be cached within the Media Grid to improve performance to a termination element on the grid, such as an ISTP client with the plugin. Objects have the same properties as handles. The handle system, as specified in RFC 3650, was designed to overcome the limitiations of URLs and has the following properties as outlined in the RFC. These properties provide a sound basis for the Media Grid architecture and objects within the grid.

January 20, 2007, at 04:38 PM PST by jlt - reformatted rfc section
Changed lines 7-24 from:
   Traditional URLs (Uniform Resource Locators) [4] allow certain
   Internet resources to be named as a combination of a DNS name and
   local name.  The local name may be a local file path, or a reference
   to some local service (e.g., a cgi-bin script).  This combination of
   a DNS name and a local name provides a flexible administrative model
   for naming and managing individual Internet resources.  However, the
   URL practice also has some key limitations.  Most URL schemes (e.g.,
   http) are defined for resolution only.  Any URL administration has to
   be done either at the local host, or via some other network service
   such as NFS.  Using a URL as a name typically ties the Internet
   resource to its current network location.  For example, a URL will be
   tied to its local file path when the file path is part of the URL.
   When the resource moves from one location to another for whatever
   reason, the URL breaks.  It is especially difficult to work around
   this problem when the reason for the location change is change in
   ownership of an asset, as ownership is generally reflected in the
   domain name.
to:

Traditional URLs (Uniform Resource Locators) [4] allow certain Internet resources to be named as a combination of a DNS name and local name. The local name may be a local file path, or a reference to some local service (e.g., a cgi-bin script). This combination of a DNS name and a local name provides a flexible administrative model for naming and managing individual Internet resources. However, the URL practice also has some key limitations. Most URL schemes (e.g., http) are defined for resolution only. Any URL administration has to be done either at the local host, or via some other network service such as NFS. Using a URL as a name typically ties the Internet resource to its current network location. For example, a URL will be tied to its local file path when the file path is part of the URL. When the resource moves from one location to another for whatever reason, the URL breaks. It is especially difficult to work around this problem when the reason for the location change is change in ownership of an asset, as ownership is generally reflected in the domain name.

January 20, 2007, at 04:36 PM PST by jlt - added RFC intro paragraph
Changed lines 7-24 from:
to:
   Traditional URLs (Uniform Resource Locators) [4] allow certain
   Internet resources to be named as a combination of a DNS name and
   local name.  The local name may be a local file path, or a reference
   to some local service (e.g., a cgi-bin script).  This combination of
   a DNS name and a local name provides a flexible administrative model
   for naming and managing individual Internet resources.  However, the
   URL practice also has some key limitations.  Most URL schemes (e.g.,
   http) are defined for resolution only.  Any URL administration has to
   be done either at the local host, or via some other network service
   such as NFS.  Using a URL as a name typically ties the Internet
   resource to its current network location.  For example, a URL will be
   tied to its local file path when the file path is part of the URL.
   When the resource moves from one location to another for whatever
   reason, the URL breaks.  It is especially difficult to work around
   this problem when the reason for the location change is change in
   ownership of an asset, as ownership is generally reflected in the
   domain name.
January 20, 2007, at 04:34 PM PST by jlt - added heading
Changed lines 3-4 from:

Media Grid objects are rich media objects either orginated from inside the Media Grid or via an ordinary URL transferred from outside of it. Permanent objects inside the grid have meta data associated with them as specified by the by the handle system's meta-data schema. Temporary objects, such as those streamed from an outside URL, may be cached within the Media Grid to improve performance to a termination element on the grid, such as an ISTP client with the plugin. Objects have the same properties as handles. The handle system, as specified in RFC 3650, has the following properties for these objects and provides a sound basis for the Media Grid architecture:

to:

Media Grid objects are rich media objects either orginated from inside the Media Grid or via an ordinary URL transferred from outside of it. Permanent objects inside the grid have meta data associated with them as specified by the by the handle system's meta-data schema. Temporary objects, such as those streamed from an outside URL, may be cached within the Media Grid to improve performance to a termination element on the grid, such as an ISTP client with the plugin. Objects have the same properties as handles. The handle system, as specified in RFC 3650, has the following properties for these objects and provides a sound basis for the Media Grid architecture.

From RFC 3650:

Changed lines 26-27 from:
         its value in the Handle System to reflect the new location.
to:
         its value in the Handle System to reflect the new location.
Changed lines 34-35 from:
         load.
to:
         load.
Changed lines 48-49 from:
         resolution and administration, to a local handle service.
to:
         resolution and administration, to a local handle service.
January 20, 2007, at 04:27 PM PST by jlt - Media Grid Objects intro
Changed lines 1-3 from:

InterStream Media Grid Objects

Media Grid objects are rich media objects, as specified by the by the handle system's meta-data registry.

to:

InterStream Media Grid Objects

Media Grid objects are rich media objects either orginated from inside the Media Grid or via an ordinary URL transferred from outside of it. Permanent objects inside the grid have meta data associated with them as specified by the by the handle system's meta-data schema. Temporary objects, such as those streamed from an outside URL, may be cached within the Media Grid to improve performance to a termination element on the grid, such as an ISTP client with the plugin. Objects have the same properties as handles. The handle system, as specified in RFC 3650, has the following properties for these objects and provides a sound basis for the Media Grid architecture:

The Handle System is designed to overcome these limitations and to add significant functionality. Specifically, the Handle System is designed with the following objectives:

  • Uniqueness: Every handle is globally unique within the Handle
    System.
  • Persistence: Handles may be used as persistent identifiers for
    Internet resources. A handle does not have to be derived from
    the entity that it names. While an existing name, or even a
    mnemonic, may be included in a handle for convenience, the only
    operational connection between a handle and the entity it names
    is maintained within the Handle System. This of course does
    not guarantee persistence, which is a function of
    administrative care. But it does allow the same name to
    persist over changes of location, ownership, and other state
    conditions. For example, when a named resource moves from one
    location to another, the handle may be kept valid by updating
    its value in the Handle System to reflect the new location.
  • Multiple Instances: A single handle can refer to multiple
    instances of a resource, at different and possibly changing
    locations in a network. Applications can take advantage of
    this to increase performance and reliability. For example, a
    network service may define multiple entry points for its
    service with a single handle so as to distribute the service
    load.
  • Multiple Attributes: A single handle can refer to multiple
    attributes of a resource, including associated services,
    available through any method at different and possibly changing
    network locations. Handles can thus be used as persistent
    entry points into an evolving world of services associated with
    identified resources.
  • Extensible Namespace: Existing local namespaces may join the
    handle namespace by acquiring a unique handle naming authority.
    This allows local namespaces to be introduced into a global
    context while avoiding conflict with existing namespaces. Use
    of naming authorities also allows delegation of service, both
    resolution and administration, to a local handle service.
  • International Support: The handle namespace is based on Unicode
    3.0 [17], which includes most of the characters currently used
    around the world. This allows handles to be used in any native
    environment. The handle protocol mandates UTF-8 [5] as the
    encoding used for handles.
  • Distributed Service Model: The Handle System defines a
    hierarchical service model such that any local handle namespace
    may be serviced by a corresponding local handle service, by the
    global service, or by both. The global service, known as the
    Global Handle Registry, can be used to dispatch any handle
    service request to the responsible local handle service. The
    distributed service model allows replication of any given
    service into multiple service sites, and each service site may
    further distribute its service into a cluster of individual
    servers. (Note that local here refers only to namespace and
    administrative concerns. A local handle service could in fact
    have many service sites distributed across the Internet.)
  • Secured Name Service: The Handle System allows secured name
    resolution and administration over the public Internet. The
    Handle System protocol defines standard mechanisms for both
    client and server authentication, as well as service
    authorization. It also provides security options to assure
    data integrity and confidentiality.
  • Distributed Administration Service: Each handle may define its
    own administrator(s) or administrator group(s). Ownership of
    each handle is defined in terms of its administrator or
    administrator groups. This, combined with the Handle System
    authentication protocol, allows any handle to be managed
    securely over the public network by its administrator at any
    network location.
  • Efficient Resolution Service: The handle protocol is designed
    to allow highly efficient name resolution performance. To
    avoid resolution being affected by computationally costly
    administration service, separate service interfaces (i.e.,
    server processes and their associated communication ports) for
    handle name resolution and administration may be defined by any
    handle service.
January 20, 2007, at 11:26 AM PST by jlt - initial edit -- needs more work
Added lines 1-3:

InterStream Media Grid Objects

Media Grid objects are rich media objects, as specified by the by the handle system's meta-data registry.

Edit - History - Print - Recent Changes - Search
Page last modified on April 15, 2010, at 12:48 PM PST