You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

$Id: m3-RequirementsAnalysis.html,v 1.1 2000/06/09 01:05:38 edburns%acm.org Exp $

Webclient Requirements Analysis

Introduction
Native Analysis
Appendices

Introduction

requirements specification

using existing native code browser technology
extending existing native code browser technology

requirements specification

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:

How long did it take to prepare the analysis for this section?
What is the analogous code in the native environment?
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.
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:

webclient.Bookmarks
1. Adding bookmarks
2. Displaying bookmarks

webclient.Cookies
1. Adding/deleting cookies
2. Displaying cookies

webclient.CurrentPage
1. Selection
2. Find in Page
3. Page Info and Page Source
4. Get DOM

webclient.EventRegistration
1. Container Events
2. Document Events
3. Document Load Events
4. DOM Events
5. JavaScript Events
6. Window Events

webclient.ExtendedEventRegistration
1. HyperLink Events

webclient.History
1. History Navigation
2. History Display
3. HistoryEntry interface

webclient.Navigation

webclient.cache.NetDataCacheManager SKIP

webclient.Preferences
1. Import/Export of Bookmarks and Cookies
2. Proxies
3. Http Headers
4. Character Set
5. History Expiration, etc.
6. Security

webclient.Print SKIP

Mozilla

webclient.Bookmarks DONE(edburns)
webclient.Cookies DONE(edburns)
webclient.CurrentPage DONE(edburns)
webclient.EventRegistration DONE(anns)
webclient.ExtendedEventRegistration DONE(anns)
webclient.History DONE(kbaker)
webclient.Navigation DONE(visvan)
webclient.NetDataCacheManager SKIP
webclient.Preferences DONE(frankm)
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
`Bookmarks`	Display bookmarks	4	1 week	0.5 hours	Netscape RDF impl	20 (1 of 5 methods)	edburns
`Cookies`	Add/Remove cookies	4	1 week	0.5 hours	Depends on Blackconnect	0
`Cookies`	Display cookies	4	1 week	0.5 hours	Depends on Blackconnect	0
`CurrentPage`	Selection manipulation	2	2 weeks	2 hours	nsIPresShell	70 (7 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 (2 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)
`History`	Display HistoryEntry	4	1 week	0.5 hours	nsISessionHistory	60 (8 of 13 methods)
`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

How long did it take to prepare the analysis for this section?
0.5 hours
What is the analogous code in the native environment?
mozilla\xpfe\components\bookmarks\public\nsIBookmarksService.idl
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
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

How long did it take to prepare the analysis for this section?
2 hours
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
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.
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

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

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,
What modifications or workarounds need to be made in order to use the native code for the current functional grouping within an interface?

Container Events: The only event in mind is the FocusAvailable() event, which is in nsIWebShell feasibility scale: 2
Document Events: These exist in nsIDocumentObserver. It is unclear in what form this will exist after the webshell redesign. feasibility scale: 2;
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
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
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
Window Events [ED: I'm not sure what Window Events you mean here] feasibility scale: x

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

webclient.ExtendedEventRegistration

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

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

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

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

webclient.History

How long did it take to prepare the analysis for this section?
0.5 hours

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()

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?
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

How long did it take to prepare the analysis for this section?
1 hour
What is the analogous code in the native environment?
mozilla/webshell/public/nsIWebShell.h
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
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

How long did it take to prepare the analysis for this section?
2 hours
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.)
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
What is a rough estimate of how many person-weeks it will take to implement this webclient interface in native code?

6 weeks

Appendices

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

Webclient Requirements Analysis

Table of Contents