$Id: RequirementsAnalysis.html,v 1.16 2000/03/08 19:38:17 edburns%acm.org Exp $

Webclient Requirements Analysis

Table of Contents

  1. Introduction
  2. Native Analysis
    1. Mozilla
    2. Internet Explorer
    3. HotJava Bean
  3. Appendices
    1. The Requirements Specification
    2. Differences from the Current Implementation
    3. People who have worked on this document

Introduction

Native Analysis

For each of the native browser environments, this section goes through each of the relevant interfaces defined in the requirements spec and answers the following questions:

  1. How long did it take to prepare the analysis for this section?

  2. What is the analogous code in the native environment?

  3. What modifications or workarounds need to be made in order to use the native code for the current functional grouping within an interface?

    For each functional grouping within an interface, use the following scale to rate the feasibility of exposing this feature to webclient:

    1. No brainer: the feature is already exposed
    2. It's glue code: the feature exists, but isn't exposed
    3. Needs work: the basic infrastructure for the feature is there, but some significant changes need to be made in order to expose the feature.
    4. Redesign required: the existing architecture doesn't allow for this feature to be exposed.
    5. Impossible: a prohibitively large amount of work is required to expose the feature.

  4. What is a rough estimate of how many person-weeks it will take to implement this webclient interface in native code? Assume the person implementing the code is familiar with mozilla code in general, but is not necessarily familiar with the particular part of the code in which the feature must be implemented.

Webclient interfaces:

Mozilla

  1. webclient.Bookmarks DONE(edburns)
  2. webclient.Cookies DONE(edburns)
  3. webclient.CurrentPage DONE(edburns)
  4. webclient.EventRegistration DONE(anns)
  5. webclient.ExtendedEventRegistration DONE(anns)
  6. webclient.History DONE(kbaker)
  7. webclient.Navigation DONE(visvan)
  8. webclient.NetDataCacheManager SKIP
  9. webclient.Preferences DONE(frankm)
  10. webclient.Print SKIP
webclient interface feasibility scale time to implement time to prepare analysis implementation depends on implementation % complete owner
Bookmarks Add/Remove bookmarks 4 1 week 0.5 hours Netscape RDF impl 20 (1 of 5 methods) edburns
Display bookmarks 4
Cookies Add/Remove cookies 4 1 week 0.5 hours Depends on Blackconnect 0
Display cookies 4
CurrentPage Selection manipulation 2 2 weeks 2 hours nsIPresShell 10 (1 of 10 methods) ashuk
Find in Page 3
Page Info 3
Page Source 3
Get DOM 1 depends on JavaDOM project
EventRegistration Container Events 2 3 weeks 2 hours Mozilla Observer interfaces 8 (1 of 12 methods) ashuk
Document Events 2
Document Load Events 2
DOM Events 1
JavaScript Events 3
Window Events 3
ExtendedEventRegistration HyperLink Events 1 0.5 weeks 0.25 hours - 0
History Add/Remove HistoryEntry 4 1 week 0.5 hours nsISessionHistory 60 (8 of 13 methods)
Display HistoryEntry 4
Navigation Navigation 1 0.2 weeks 1 hour nsIDocShell 100 (3 of 3 methods) edburns
Preferences Import Export of bookmarks and cookies 4 6 weeks 2 hours - 0
Proxies 3
Http headers 4
Character Sets 3
History Expiration, etc. 3
Security 3
Font, color, etc 3
Set user stylesheet 3
Total Implementation Time: 14 weeks
Estimated Total Implementation Time (with padding): 18 weeks

webclient.Bookmarks

  1. How long did it take to prepare the analysis for this section?

    0.5 hours

  2. What is the analogous code in the native environment?

    mozilla\xpfe\components\bookmarks\public\nsIBookmarksService.idl
  3. What modifications or workarounds need to be made in order to use the native code for the current functional grouping within an interface?

    For adding to the bookmarks, no facility exists to insert a bookmark into a hierarchy structure. This would have to be added. There is api for just adding a bookmark to a list, however. If we take it as it is, feasibility scale: 1, if we want to expose the hierarchy feature, feasibility scale: 4

    For exposing the current bookmarks to enable the embedding app to display the bookmarks in a custom UI, this feature doesn't exist. feasibility scale: 4

  4. What is a rough estimate of how many person-weeks it will take to implement this webclient interface in native code?

    1 week

webclient.CurrentPage

  1. How long did it take to prepare the analysis for this section?

    2 hours

  2. What is the analogous code in the native environment?

    copy: http://lxr.mozilla.org/mozilla/source/xpfe/global/resources/content/globalOverlay.js#135 with argument of 'cmd_copy' calls http://lxr.mozilla.org/mozilla/source/rdf/content/src/nsXULCommandDispatcher.cpp#485

    find: http://lxr.mozilla.org/mozilla/source/xpfe/components/search/resources/find.js#7

    page info http://lxr.mozilla.org/mozilla/source/xpfe/browser/resources/content/nsContextMenu.js#241

    page source http://lxr.mozilla.org/mozilla/source/xpfe/browser/resources/content/navigator.js#951

  3. What modifications or workarounds need to be made in order to use the native code for the current functional grouping within an interface?

    1. Selection feasibility scale: 2

      Selection manipulation commands are currently initiatiated through XUL, which means they are accessible to javascript, which means they are accessible through XPCOM.

    2. Find in Page feasibility scale: 3

      Not as straightforward as you might think. Currently there is no simple find api that takes the argument string and parameters as we've specified in the webclient.CurrentPage api.

    3. Page Info feasibility scale: 3

      Will be available from XUL, but not implemented yet.

    4. Page Source feasibility scale: 3

      Similar to Find in Page, the java script code does some nonsense to get the view source window to come up. We'll have to do some extra work to get the page source as a byte array.
    5. Get DOM feasibility scale: 1

      Getting access to the DOM is taken care of by an external blackwood project.

  4. What is a rough estimate of how many person-weeks it will take to implement this webclient interface in native code?

    2 weeks

webclient.EventRegistration

  1. How long did it take to prepare the analysis for this section?

  2. 2 hours
  3. What is the analogous code in the native environment? 
    /webshell/public/nsIDocumentLoaderObserver, /layout/base/public/nsIDocumentObserver, nsILinkHandler, /network/public/nsIStreamObserver (not sure if this interface will go away, it has some redundant APIs). After the webshell redesign, the major consolidated interfaces will be nsIDocShell, nsIWebBrowser, nsIProgressListener,
  4. What modifications or workarounds need to be made in order to use the native code for the current functional grouping within an interface?
    1. Container Events: The only event in mind is the FocusAvailable() event, which is in nsIWebShell feasibility scale: 2
    2. Document Events: These exist in nsIDocumentObserver. It is unclear in what form this will exist after the webshell redesign. feasibility scale: 2;
    3. Document Load Events: These exist in nsIDocumentLoaderObserver . A wrapper for nsIDocumentLoaderObserver has been implemented in /java/webclient/src/DocumentObserver However, nsIDocumentLoaderObserver is supposed to be replaced by nsIProgressListener. feasibility scale: 1-2
    4. DOM Events: The JavaDOMEvent API will exist. As of Oct 20 1999, Igor Nekrestyanov <nis@sparc.spb.su> is working on it. feasibility scale: 1
    5. JavaScript Events: events such as mouse_over, drag, etc are going to be exposed as DOMEvents. See /layout/events/src/nsDOMEvent However, the event notifications for the other events such as OnChange, OnBlur, etc have not been located yet. feasibility scale: 3
    6. Window Events [ED: I'm not sure what Window Events you mean here] feasibility scale: x

    7.  

       
       
       

  5. What is a rough estimate of how many person-weeks it will take to implement this webclient interface in native code?

  6. 3 weeks
     

webclient.ExtendedEventRegistration

  1. How long did it take to prepare the analysis for this section?

  2. .25 hours
  3. What is the analogous code in the native environment?
  4. JavaDOMEvent handling.
  5. What modifications or workarounds need to be made in order to use the native code for the current functional grouping within an interface?
    1. HyperLink Events events such as mouse_over, drag, etc are going to be exposed as DOMEvents. See /layout/events/src/nsDOMEvent. Since DOM Events are being exposed by Igor N, this should be no problem feasibility scale: 1

    2.  

       
       
       

  6. What is a rough estimate of how many person-weeks it will take to implement this webclient interface in native code?

  7. <.5 week
     

webclient.History

  1. How long did it take to prepare the analysis for this section?

    0.5 hours

  2. What is the analogous code in the native environment?

    mozilla/source/webshell/src/nsWebShell.cpp
        Back()
        CanBack()
        Forward()
        CanForward()
        GetHistoryIndex()
        GoTo()
        GetHistoryLength()
        GetURL()
        GetSessionHistory()
        SetSessionHistory()
    mozilla/source/xpfe/appshell/src/nsSessionHistory.cpp
        GetTitleForIndex()
        NS_NewSessionHistory()
    
    	

  3. What modifications or workarounds need to be made in order to use the native code for the current functional grouping within an interface?

    Most of the methods can be implemented simply by calling methods in nsWebShell.cpp. These include: back(), canBack(), forward(), canForward(), getHistoryIndex(), setHistoryIndex(), getHistoryLength(), and getURL(). Most of the remaining methods can be defined in terms of using the simple methods. These include: getBackList(), getForwardList(), getHistory(), and getHistoryIndex(). Feasibility scale: 1.

    The method clearHistory() may not be easily implemented unless we can find out if it is OK to delete the webShell's nsSessionHistory and replace it with a new one by calling NS_NewSessionHistory() and setting the WebShell's session history by calling SetSessionHistory(). Feasibility scale: 3.

    A definition for the class webclient.HistoryEntry needs to be defined and should include at least the following: URL, Title, the index for the HistoryEntry, statistics for last time visited, and number of times visited. Suggestions for other fields are welcome. Feasibility scale: 3.

    Note that many of these methods return results, and since they are likely to be called from an event thread (back() and forward()), the event thread will lock until the operation is complete. We may want to change the interface to allow this to be decoupled. Suggestions?

  4. What is a rough estimate of how many person-weeks it will take to implement this webclient interface in native code?

    1 week

webclient.Navigation

  1. How long did it take to prepare the analysis for this section?

    1 hour

  2. What is the analogous code in the native environment?

    mozilla/webshell/public/nsIWebShell.h

  3. What modifications or workarounds need to be made in order to use the native code for the current functional grouping within an interface?

    All the methods are exposed in the native code. For the methods loadURL and stop, no modifications should be necessary. The refresh method's equivalent native method is
    nsWebShell::reload ( nsLoadFlags aType )
    where aType is a constant with the following possible values
    nsISessionHistory::LOAD_HISTORY
    nsIChannel::LOAD_NORMAL
    nsIChannel::LOAD_BACKGROUND
    ( These were the only values I could find. Hope I covered everything. )
    So refresh method has to be changed so that it takes a static int as a parameter. feasibility scale: 1

  4. What is a rough estimate of how many person-weeks it will take to implement this webclient interface in native code?

    1 day

webclient.Preferences

  1. How long did it take to prepare the analysis for this section?

    2 hours

  2. What is the analogous code in the native environment?

    mozilla/modules/libpref/public/nsIPrefs.idl, accessed through GetPrefs in nsIWebShell.h. (Other APIs may be needed for specific tasks; see below.)

  3. What modifications or workarounds need to be made in order to use the native code for the current functional grouping within an interface?

    1. Import/Export of Bookmarks and Cookies feasibility scale: 4

      mozilla/modules/libpref/src/init/all.js indicates that the bookmark file is indicated by the property "browser.bookmark_location". However, to add to, or read from, the current bookmarks, the API must use the RDF service to get a tree of DOM nodes denoting the bookmarks, and modify it.

      Cookies: There is an nsICookieService defined in mozilla/extensions/cookie/nsICookieService.h. It is presumably accessible through the Service Manager (or Component Manager). However, it only allows item-by-item addition of cookies (and a method to clear all current cookies), so the API must parse the file containing cookies.

      In both cases, we will need to prototype solutions before definitively claiming that the API as it stands is or is not feasible.

    2. Proxies feasibility scale: 3

      These are simple properties, get and set through nsIPrefs methods. However, there is not a one-to-one correspondence between nsIPrefs and webclient.Preferences methods; instead, each get must pass a Mozilla property name to GetTypePref(), where Type is one of String, Int, or Bool. Set methods must do something similar, after perhaps checking the result of GetPrefType to make sure the value passed in is of the expected type.

    3. Http Headers feasibility scale: 4

      There seems no direct way to implement adding HTTP headers, except to insert headers into the disk cache, or on each sent message. It might be better to make this a separate API, since this might be a seldom-used feature, and a difficult one to implement.

    4. Character Set feasibility scale: 3

      mozilla/modules/libpref/src/init/all.js indicates that the character set is tied to the property "intl.character_set". The Java API must translate the string value to a java.lang.Character.Subset.

    5. History Expiration, etc. feasibility scale: 3

      I can't find a mechanism that actually sets history expiration. It may not be implemented yet.

    6. Security feasibility scale: 3

      mozilla/modules/libpref/src/init/all.js lists various security-related properties, starting with "security.policy".

    7. For font, color, and style on web pages, a modification could be made to mozilla\layout\html\content\src\nsHTMLFontElement.cpp that queries a preference and does the right thing. feasibility scale: 3

    8. For setUserStyleSheet, we could do something with nsIPresShell.h, where we look in the prefs and do the right thing. feasibility scale: 3

  4. What is a rough estimate of how many person-weeks it will take to implement this webclient interface in native code?

    6 weeks

Appendices

  1. The Requirements Specification

    This analysis document is based on version 1.6 of the Requirements Specifaction. Version 1.6 of the spec is available at http://www.mozilla.org/projects/blackwood/webclient/RequirementsSpec.html. The latest version of the spec is available at http://www.mozilla.org/projects/blackwood/webclient/RequirementsSpec.html

People who have worked on this Document


Ed Burns
Created: Thu Oct 14 18:08:52 PDT 1999

Last modified: Wed Mar 08 11:37:23 Pacific Standard Time 2000