Component Extension (CX) API requirements Version 1.0

1.1 Formatting [1]

The Host implementation must provide a mechanism for an embedded object to request a region or set of regions for displaying content. The formatting interface should be independent of platform specific constraints.

1.2 Rendering [1]

1.3 Style [1]

1.4 Error handling [2]

An error handling mechanism should be provided by the Host implementation to the Component Extension in a future revision of the Component Extension API. This mechanism may be based on, or inspired from, the error handling mechanism provided by the DOM Level 3 Core specification [DOM Level 3 Core].

1.5 Events [1]

There must be a way to pass events from the Host implementation to the Component Extension and from the Component Extension to the Host implementation. If the Host implementation provides a DOM tree to the component extension and contains an event mechanism, the Component Extension API must support the DOM Level 2 Events specification. User Interface events, such as window events or system events (reload, URI notify events), may be addressed.

Namespace-bound events are events whose propagation is limited to elements namespace boundaries, i.e. it propagates until it reaches an element who does not use its ancestor's namespace name. Namespace bound events are out of scope.

1.6 DOM Core tree [1]

The Component Extension API must provide programmatic read-only access to HTML and XML content by conforming to the following modules of the W3C Document Object Model Level 2 Core Specification [DOM Level 2 Core] and exporting the interfaces they define:

• the Core module for HTML

• the Core and XML modules for XML.

1.7 Starting point [1]

Features of the existing Netscape Plugin API [Netscape Plug-ins] should considered as a starting point with implementation experience for features of the Component Extension API, which may be modified, replaced, or eliminated as required to address problems and requirements.

1.8 Connecting with outside/scripting [1]

The Component Extension will call a Host implementation function to request a connection to one of its features.

This feature may be a generic functionality (eg. "copy/paste", whether this is selected by button, menu item, keyboard shortcut, drag-drop, or ...) or a specific Host implementation chrome (eg. toolbar, button, status bar ... ).

The request can be to output data through the feature (eg. status bar, title bar, alert, ...), to subscribe to events generated from a browser control, or to add a control to the chrome (eg. toolbar, menubar, menu ...)

The Host implementation should return a value indicating whether it allows the connection or not.

The Component Extension API should define how the features are selected, and specify a minimal list of connections that the browser *should* allow if it does have the requested feature, so that the Component Extension can reasonably expect such a connection request to be granted.

Subscribed-to events can be passed to the Component Extension using the normal event-passing mechanism (see 1.5 Events). If the connection needs to pass large amounts of data, the Component Extension's stream APIs should be used.

• chrome [1]

  • adding new items/removing new items

  • "right-click drop down menu"/main menu bar

  • status line

• copy/paste

• find

• drag/drop

• focus

• alert [1]

• query user agents capabilities?

• cross plug-in streams

• properties [2]

  • properties dialog

  • system properties: hostname, IP, ...

1.9 Nesting/reetrance [1]

It must be possible for a Component Extension to discover, where available, and integrate the formatting and rendering of externally supported content types inserted into the Component Extension DOM Node's subhierarchy that are not internally supported by the Component Extension.

1.10 Abstraction level [1]

Much like the W3C DOM IDL descriptions and language bindings, the Component Extension API must be described independent of programming language, operating system and platform.

1.11 timeline [2]

SMIL 2.0 [SMIL 2.0] is a specification for synchronized multimedia and SMIL Animation [SMIL Animation] is a specification for how the timing and animation aspects of SMIL 2.0 can be integrated into other languages, such as SVG (see chapter 19 in [SVG10]).

If the Host implementation supports synchronized playing of media such as audio, video or animations, then the Host implementation must support the ability for time-based Component Extensions to play media on a portion of a Host canvas, and the Host-played media and the Component Extension-played media must be synchronized. The API for achieving this synchronization must be rich enough to permit accurate implementation of the 'syncBehavior' and 'syncTolerance' attributes defined in the section 10.3.1 in [SMIL 2.0].

SMIL 2.0 and SMIL Animation allow content to be started and stopped via interactivity, such as User Interface events (e.g., mouse and keyboard). Host-supplied event propagation APIs must be such that time-based Component Extensions can implement the interactivity capabilities defined in the section 10.3.1, "Basic time support", in [SMIL 2.0].

If the Host implementation supports streaming media, then the Host implementation must supply APIs that allow Component Extensions to receive streaming content.

1.12 network/HTTP [1]

Networking Support will include an API to request the data from a URI reference.

The Component Extension will call a Host implementation function and pass the URI reference, any additional headers (for example, in the case of HTTP, maybe an additional accept type), the method (in case of HTTP, GET, PUT, POST or HEAD) and a pointer to a notify data. The Component Extension may tell the Host implementation to use the cache or to override it.

When the request is complete, the Host implementation will call the Component Extension's notify function, and pass the data to the Component Extension using the Component Extension's stream APIs.

Example:

    kError HostURIRequest(kURIMethod method,
                          const char *uri,
                          const char *headers,
                          const char *entity,
                          unsigned long entitySize,
                          void* notifyData,
                          boolean useCache);
    void   CXURINotify(const char *uri,
                       kStatus status,
                       void* notifyData);
        

1.13 Editing [2]

Many Component Extensions will involve editing functions, so the API must provide a method for access to editing functionalities - character input, drawing interfaces, etc. These must be available in a device independent manner. This requirement also means that the available rendering space may need to be dynamically re-sized (see also 1.1.2 linebreak, size and rectangle negotiation, multiple rectangles).

1.14 associations/registrations/negociations [1]

In order for the Component Extension to be able to extend the Host DOM implementation, there must be a way for the Component Extension to register its own DOM implementation in the Host DOM implementation. In that case, the DOM implementation Node factories in Document must create DOM Nodes using the registered Component Extensions Node for the corresponding types. Only the construction of the DOM nodes is affected by the registrations, not the building of the DOM tree. If the Component Extension does not provide a DOM implementation, the Host implementation must build the entire DOM tree itself, including for the content addressed by the Component Extension.

If the Host implementation provides support for XML 1.0 [XML] documents, it must also implement the namespaces support defined in the Namespaces recommendation [XML Namespaces]. Namespace conflicts resolution between Component Extensions must be resolved by the Host implementation. There must be a way for the user to choose between Component Extension implementations in case of conflicts.

The set of functionalities provided by the Host implementation must be accessible to the Component Extension. The same applies for the Component Extension: the Host implementation must have a way to query the set of functionalities provided by the Component Extension.

There are severals ways to extend the Host implementation. Technologies such as XBL or IE behaviors must be considered.

The group might decide to come up with a modular architecture for an XML parser that will permit some of the XML content to be handled by other component. A general stream API should be addressed by the Component Extension to gain access to their data.

1.15 Accessibility [2]

The Component Extension API must provide for accessibility requirements. Substantially, this reinforces the need for several of the requirements listed already, such as the ability to specify a content-type rather than a plugin, the provision and use of device-independent interaction interfaces.

The User Agent Accessibility Guidelines [UUAG] require that access is provided for DOM interfaces, and "platform-specific interfaces" (for example MSAA, the Java Accessibility API, etc) where they exist.

1.16 Versioning [1]

The Component Extension API should have an identifiable versioning mechanism. The version information must change each time the functionality is changed.

I am not sure it is necessary to discuss techniques here, as is done in the following paragraph.

One technique for achieving this is to provide the naming for functionalities, and use a mechanism like CC/PP for identifying the available functionalities. Although this seems a little heavy for this purpose, and seems to be better suited to using various unstandardized systems rather than for a standardized system.

1.17 storage/persistence [2]

The Host implementation will allow the Component Extension to save data in persistent storage or a file system. This ability will be governed by the security model associated with the Component Extension.

For example, a web page has the ability to store cookies in the file system of the host. But a sandbox model exists there. Furthermore, the user may block web pages from setting cookies.

The storage functionality can be divided into:

1. Reading and Writing data specific to the Component Extension. ('Private' Storage) Example, saving high scores in a game. Storing cookies is an example in the context of a web page.

2. Reading and Writing data from the global data. ('Public' Storage). Example, reading list of addresses (or a specific address) from an addressbook. [3]

For the first item, the Host implementation may provide the Component Extension APIs to get and set values.

For example, to set:

HostSetAttribute("newscore", itoa(newScore));
        

to read,

length = HostGetDataSize ("highscores");
if (length > 0)
{
    scoreString = memAlloc (length);
    HostGetAttribute ("highscores", scoreString);
}
        

If the security settings of the Component Extension do not allow these operations, then these operations will fail. Or, the user maybe prompted for advice.

See also [WAP Persistent Storage].

1.18 Memory management [1]

Memory management would include APIs for

• Allocating a block of memory

• Resizing the block of memory

• Releasing the block of memory and

• Flushing memory from the host's space.

          char* s = MemAlloc (100);
          s[2000] = 'a';
          

1.19 Security

Security issues must be considered for each of the functionalities of the Component Extension API.