CX Notes

Problems with APIs

• Versioning
• Rely on the "Programming Language of the Day"
• Not necessarily cross-platform

Solution

Linking Web Services and Component Extensions together

The work needs to be done at 3 levels:

1. CX Description Format: a platform independent description of the functionality provided by the Component Extension, in order for the Host Implementation to appropriately handle the characteristics of the functionality and the content handled by the Component Extension; such description will be done using XML;
2. CX "protocol": a platform independent XML-based protocol, to allow communication between the Host Implementation and the Compenent Extension;
3. a platform independent API, for functionality that should stay platform dependent and therefore undefined, such as a graphics API.

1. CX Description Format

Current situation:

Browser side:

NPN_GetValue(myPlugin, NPPVpluginWindowBool, &returnValue);
NPN_GetValue(myPlugin, NPPVpluginTransparentBool, &returnValue);
char * mime = NP_GetMIMEDescription();

This could be replaced and extended by the CX Description file:

<?xml version='1.0'>
<cx:description xmlns:cx='http://www.example.org/cx'>

  <!-- specific information about the CX and its (optional?) location -->
  <cx:id>http://www.example.com/graphics/myCXHomePage</cx:id>
  <cx:version>1.3</cx:version>
  <cx:location>file://localhost/Program Files/Graphics/MyCX.dll</cx:location>

  <!-- list of supported MIME types -->

  <cx:mimeType>image/svg+xml</cx:mimeType>

  <!-- list of file extensions -->

  <cx:fileExtension>svg</cx:fileExtension>
  <cx:fileExtension>svgz</cx:fileExtension>

  <cx:shortDescription>Scalable Vector Graphics<cx:shortDescription>
  <cx:description>
   SVG blabla, ... See also http://www.example.com/graphics/myCXHomePage
  <cx:description>

  <!-- list of supported namespaces -->

  <cx:namespace>http://www.w3.org/2000/svg</cx:namespace>

  <!-- list of supported features -->

  <cx:feature uri='http://www.w3.org/TR/SVGMobile/Basic/feature#base' />
  <cx:feature uri='http://www.w3.org/TR/SVGMobile/Basic/feature#interactivity' />
  <cx:feature uri='http://www.w3.org/TR/SVGMobile/Basic/feature#SVGBasicDomCore' />

  <!-- list of properties and their values -->

  <!-- the CX is not windowless -->
  <cx:property uri='http:/www.example.org/Window'>
    <cx:value>false</cx:value>
  </cx:property>
  <!-- the CX does want transparency -->
  <cx:property uri='http:/www.example.org/Transparent'>
    <cx:value>true</cx:value>
  </cx:property>
</cx:description>

The browser can then read the CXDL instead of having to call functions. The CXDL file can be extended as necessary to include more informations.

2. CX operations

Invoking the find and Replace function of the browser from the plug-in:

myBrowserExtensionFind("plug-in", "component extension");

This could be changed into the following description file:

<?xml version='1.0'?>
<definitions xmlns='http:/www.w3.org/2003/11/wsdl'>
 <types>
   <xsd:schema>
    <xsd:element name='messageIn'>
      <xsd:element name='find' type='xsd:string'/>
      <xsd:element name='replace' type='xsd:string'/>
    </xsd:element>
    <xsd:element name='messageOut'>
      <xsd:element name='occurence' type='xsd:nonNegativeInteger'/>
    </xsd:element>
   </xsd:schema>
    <interface name='Browser'>
      <operation name='findAndReplace'>
	<input element='messageIn'/>
	<output element='messageOut'/>
      </operation>
    </interface>
    <binding>
      <soap:protocol transport='http://www.example.org/BinaryXML' />
    </binding>
    <service>
      <soap:address location='windowsSocket:5005'/>
    </service>
</definitions>

The code can now be generated according to the WSDL description. Thus, myBrowserExtensionFind becomes a function call on the CX side that is transformed into a WS call in order to dialog with the HI. The goal would be to define the set of operations to promote interoperability between HIs, including the type of parameters, return values, and the extensibility constraints. Technics such as required could be used to facilitate the extensibility constraints. http://www.example.org/BinaryXML needs to be defined. Advantages are:

1. language independent: The WSDL processor can generate whatever "language of the Day", etc.;
2. extensible: the findAndReplace messages can be extended.
3. versioning: findAndReplace cannot conflict with pre-existing definitions. Vendors can define their own findAndReplace message if they wish (as long as they put it in their own namespace.

WSDL definitions MUST be available on both sides, so that HI and CX can invoke each other functionalities.

3. Low level API

Functions like NPN_MemAlloc, NPN_MemFree, or other graphic low-level functions shouldn't be addressed or should be language specific (DOM-like).