2009/dap/design-patterns Overview.html,NONE,1.1

Update of /sources/public/2009/dap/design-patterns
In directory hutz:/tmp/cvs-serv23596

Added Files:
	Overview.html 
Log Message:
Initial list of basic design patterns

--- NEW FILE: Overview.html ---
<!DOCTYPE html>
<html>
  <head>
    <title>Device API Design Patterns</title>
    <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
    <script src='../ReSpec.js/js/respec.js' class='remove'></script>
    <script class='remove'>
      var respecConfig = {
      specStatus: "ED",
      shortName:            "dap-design-patterns",
      // publishDate:  "2009-10-23",
      // previousPublishDate:  "1976-01-19",
      edDraftURI:           "http://dev.w3.org/2009/dap/design-patterns/",
      // lcEnd: "2009-08-05",
      };
    </script>
    <script src='../common/configPolicy.js' class='remove'></script>
  </head>
<body>
    <section id='abstract'>
      These are the requirements for the API Design Patterns work undertaken by the
      DAP WG.
    </section>
    
    <section class='informative'>
      <h2>Introduction</h2>
      <p>
        This document is an editors' draft and currently does not
        reflect consensus of the WG but rather is a starting point for
        further work. It is based on input documents and list
        discussion.
      </p>
    </section>

    <section>
		<h2>Design Patterns</h2>
		<section>
			<h3>Requirements</h3>
			<p>
			At present the below items list both patterns and naming conventions.
			</p>
			<ul>
				<li>Naming of WebIDL modules, interfaces, attributes and methods MUST follow the camelCase form.
				</li>
				<li>WebIDL constant defined by DAP APIs MUST be capitalized.
				</li>
				<li>There MUST be a common pattern
				</li>
				<li>All APIs MUST follow the same convention when handling callback functions
				(e.g. XHR / FileAPI style with onreadystatechange, or ProgressEvent with EventTarget).
				</li>
				<h3>Issues</h3>
				<p class="issue">
				Maybe it would be possible to define the API in such an abstract way that both models: XHR and ProgressEvent could handle the architecture
				and vendors could differentiate?
				</p>
				<li>Large data collections MUST be handled uniformly through all the APIs.
				</li>
				<li>There MUST be a common pattern for handling asynchronous operations (e.g. through events, callbacks or mixed)
				</li>
				<li>There MUST be a host object representing the asynchronous operation.
				</li>
				<li>The asynchronous operation MUST be cancellable with a commonly defined operation on the asynchronous object.
				</li>
				<li>There MUST be a common pattern for handling the information passed by the host objects (e.g. events, callbacks, mixed events and callbacks).
				</li>
				<li>There MUST be a common naming scheme for the methods handling basic record manipulation operations (e.g. "Create" for record/item creation, "Delete" for destruction,
				"Update" or "Save" for updating, "Read" or direct object retrieval for access to the properties, "Remove" for removal from the collection [no destruction]).
				</li>
			</ul>
		</section>
    </section>

	<section class='appendix'>
		<h2>Acknowledgements</h2>
		<p>
			The editors would like to extend special thanks to ACCESS Co., Ltd., OMTP
			BONDI and Nokia for providing the foundation of the working group's requirements discussion.
		</p>
	</section>
</body>
</html>

Received on Monday, 2 November 2009 09:38:54 UTC