Notional architecture - Revision history

Stevenlawrance: /* Thunderbird interface implementation layer (model) */

2007-07-02T16:20:00Z

Thunderbird interface implementation layer (model)

← Older revision		Revision as of 16:20, 2 July 2007
Line 61:		Line 61:
	This section describes the classes and interfaces used in the Thunderbird interface implementation layer from a high level. Further experimentation and refinement is required to learn more about the Thunderbird interfaces and which ones are the right ones to use. Thunderbird includes a substantial amount of functionality in its base classes, so the experiments will also dig into which functionality to reuse and which functionality to implement ourselves.		This section describes the classes and interfaces used in the Thunderbird interface implementation layer from a high level. Further experimentation and refinement is required to learn more about the Thunderbird interfaces and which ones are the right ones to use. Thunderbird includes a substantial amount of functionality in its base classes, so the experiments will also dig into which functionality to reuse and which functionality to implement ourselves.
	*Account		*Account
	**class nsThunderforceProtocolInfo implements nsIMsgProtocolInfo		**class nsThunderforceProtocolInfo implements [http://lxr.mozilla.org/mailnews/source/mailnews/base/public/nsIMsgProtocolInfo.idl#49 nsIMsgProtocolInfo]
	**class nsThunderforceServer implements nsIMsgIncomingServer		**class nsThunderforceServer implements [http://lxr.mozilla.org/mailnews/source/mailnews/base/public/nsIMsgIncomingServer.idl#61 nsIMsgIncomingServer]
	*Address Book		*Address Book
	*Extension		*Extension

Stevenlawrance: /* Thunderbird interface implementation layer (model) */

2007-07-02T02:50:32Z

Thunderbird interface implementation layer (model)

← Older revision		Revision as of 02:50, 2 July 2007
Line 62:		Line 62:
	*Account		*Account
	**class nsThunderforceProtocolInfo implements nsIMsgProtocolInfo		**class nsThunderforceProtocolInfo implements nsIMsgProtocolInfo
			**class nsThunderforceServer implements nsIMsgIncomingServer
	*Address Book		*Address Book
	*Extension		*Extension

Stevenlawrance: /* Thunderbird interface implementation layer (model) */

2007-07-01T19:21:53Z

Thunderbird interface implementation layer (model)

← Older revision		Revision as of 19:21, 1 July 2007
Line 61:		Line 61:
	This section describes the classes and interfaces used in the Thunderbird interface implementation layer from a high level. Further experimentation and refinement is required to learn more about the Thunderbird interfaces and which ones are the right ones to use. Thunderbird includes a substantial amount of functionality in its base classes, so the experiments will also dig into which functionality to reuse and which functionality to implement ourselves.		This section describes the classes and interfaces used in the Thunderbird interface implementation layer from a high level. Further experimentation and refinement is required to learn more about the Thunderbird interfaces and which ones are the right ones to use. Thunderbird includes a substantial amount of functionality in its base classes, so the experiments will also dig into which functionality to reuse and which functionality to implement ourselves.
	*Account		*Account
			**class nsThunderforceProtocolInfo implements nsIMsgProtocolInfo
	*Address Book		*Address Book
	*Extension		*Extension

Stevenlawrance: /* Thunderbird interface implementation layer (model) */

2007-06-29T04:20:24Z

Thunderbird interface implementation layer (model)

← Older revision		Revision as of 04:20, 29 June 2007
Line 66:		Line 66:
	*Filters		*Filters
	*Folders		*Folders
	**class nsSalesforceMsgFolder implements nsIMsgFolder, nsIDBChangeListener, nsISupportsWeakReference, nsRDFResource, nsIUrlListener		**class nsSalesforceMsgFolder implements [http://lxr.mozilla.org/mailnews/source/mailnews/base/public/nsIMsgFolder.idl nsIMsgFolder], [http://lxr.mozilla.org/mailnews/source/mailnews/base/public/nsIMsgFolderNotificationService.idl nsIMsgFolderNotificationService], nsIDBChangeListener, nsISupportsWeakReference, nsRDFResource, nsIUrlListener
	*Offline		*Offline

Stevenlawrance: /* Thunderbird interface implementation layer (model) */

2007-06-29T04:02:53Z

Thunderbird interface implementation layer (model)

← Older revision		Revision as of 04:02, 29 June 2007
Line 59:		Line 59:

	===Thunderbird interface implementation layer (model)===		===Thunderbird interface implementation layer (model)===
			This section describes the classes and interfaces used in the Thunderbird interface implementation layer from a high level. Further experimentation and refinement is required to learn more about the Thunderbird interfaces and which ones are the right ones to use. Thunderbird includes a substantial amount of functionality in its base classes, so the experiments will also dig into which functionality to reuse and which functionality to implement ourselves.
	~~Coming soon, pending~~ more ~~research into~~ the ~~exact~~ Thunderbird interfaces		*Account
			*Address Book
			*Extension
			*File I/O
			*Filters
			*Folders
			**class nsSalesforceMsgFolder implements nsIMsgFolder, nsIDBChangeListener, nsISupportsWeakReference, nsRDFResource, nsIUrlListener
			*Offline

Stevenlawrance: /* Thunderbird interface implementation layer (model) */

2007-06-17T18:50:51Z

Thunderbird interface implementation layer (model)

← Older revision		Revision as of 18:50, 17 June 2007
Line 60:		Line 60:
	===Thunderbird interface implementation layer (model)===		===Thunderbird interface implementation layer (model)===

	Coming soon		Coming soon, pending more research into the exact Thunderbird interfaces

Stevenlawrance: /* Salesforce.com data layer (model) */

2007-06-17T18:49:20Z

Salesforce.com data layer (model)

← Older revision		Revision as of 18:49, 17 June 2007
Line 27:		Line 27:
	===Salesforce.com data layer (model)===		===Salesforce.com data layer (model)===
	[[Image:Module View - Salesforce.com Model.jpg]]		[[Image:Module View - Salesforce.com Model.jpg]]

			[https://www.moonlightdesign.org/thunderforce/svn/trunk/architecture/Notional%20Architecture/Module%20View%20-%20Salesforce.com%20Model.uxf Source UMLet diagram]

	The diagram above depicts how the Salesforce.com data layer components relate to each other.		The diagram above depicts how the Salesforce.com data layer components relate to each other.

Stevenlawrance: /* Salesforce.com data layer (model) */

2007-06-17T18:45:06Z

Salesforce.com data layer (model)

← Older revision		Revision as of 18:45, 17 June 2007
Line 41:		Line 41:

	One point of current architectural ambiguity is how Thunderbird's undo/redo manager will interoperate with the cache. More research through an experiment will clarify this.		One point of current architectural ambiguity is how Thunderbird's undo/redo manager will interoperate with the cache. More research through an experiment will clarify this.

			More investigation into how to leverage Mozilla's built-in cache manager is required. Ideally, the Thunderforce cache will not need to implement most of what it provides.

	This architectural pattern permits the upper layers to primarily interact with the BidirectionalAPI interface. As a result, the Cache class can be implemented in the future to get an alpha version of Thunderforce ready as soon as possible.		This architectural pattern permits the upper layers to primarily interact with the BidirectionalAPI interface. As a result, the Cache class can be implemented in the future to get an alpha version of Thunderforce ready as soon as possible.
Line 50:		Line 52:

	A class that collects API usage statistics is needed. It can probably extend APIDelegator and include methods for getting the average number of API calls per hour, the total number of API calls performed in the previous 24 hours, and other useful numbers.		A class that collects API usage statistics is needed. It can probably extend APIDelegator and include methods for getting the average number of API calls per hour, the total number of API calls performed in the previous 24 hours, and other useful numbers.

			In the implementation, the classes will likely be invoked with the following chain of delegates:
			*Cache -> BidirectionalAPIPoller -> APIMetricsCollector -> Salesforce

	===Thunderbird interface implementation layer (model)===		===Thunderbird interface implementation layer (model)===

	Coming soon		Coming soon

Stevenlawrance at 18:36, 17 June 2007

2007-06-17T18:36:02Z

← Older revision		Revision as of 18:36, 17 June 2007
Line 50:		Line 50:

	A class that collects API usage statistics is needed. It can probably extend APIDelegator and include methods for getting the average number of API calls per hour, the total number of API calls performed in the previous 24 hours, and other useful numbers.		A class that collects API usage statistics is needed. It can probably extend APIDelegator and include methods for getting the average number of API calls per hour, the total number of API calls performed in the previous 24 hours, and other useful numbers.

			===Thunderbird interface implementation layer (model)===

			Coming soon

Stevenlawrance: /* Salesforce.com data layer (model) */

2007-06-17T18:33:10Z

Salesforce.com data layer (model)

← Older revision		Revision as of 18:33, 17 June 2007
Line 44:		Line 44:
	This architectural pattern permits the upper layers to primarily interact with the BidirectionalAPI interface. As a result, the Cache class can be implemented in the future to get an alpha version of Thunderforce ready as soon as possible.		This architectural pattern permits the upper layers to primarily interact with the BidirectionalAPI interface. As a result, the Cache class can be implemented in the future to get an alpha version of Thunderforce ready as soon as possible.

	The BidirectionalAPIPoller presents a unidirectional API as a BidirectionalAPI through periodic polling for changes. To reduce the API call impact, only those entities that the user subscribed to within Thunderbird will be polled (question: will summary fields also cause the last-modified timestamp to change and trigger replication (WFOM and getUpdated)?). The set of subscribed entities is also what the Thunderforce searches are limited to, so we don't have to care about those entities that we are not subscribed to.		The BidirectionalAPIPoller presents a unidirectional API as a BidirectionalAPI through periodic polling for changes. To reduce the API call impact, only those entities that the user subscribed to within Thunderbird will be polled (question: will [http://ideas.salesforce.com/article/show/22256/Crossobject_Formulas_RollUp_Summary_fields_coming_in_Summer_07 summary fields] also cause the last-modified timestamp to change and trigger replication (WFOM and getUpdated)?). The set of subscribed entities is also what the Thunderforce searches are limited to, so we don't have to care about those entities that we are not subscribed to.
	*Each entity will have its own polling frequency that can be set in setEntityRefreshIntervals(). For now, these will likely be set to default values internally. Eventually, this can be dynamically adjusted based on how frequently that entity is changing. An exponential back-off can be used when that entity has not changed since the last check.		*Each entity will have its own polling frequency that can be set in setEntityRefreshIntervals(). For now, these will likely be set to default values internally. Eventually, this can be dynamically adjusted based on how frequently that entity is changing. An exponential back-off can be used when that entity has not changed since the last check.
	*For subscribed entities that have the replicateable attribute, the replication methods getUpdated() and getDeleted() will be used to reduce the number of API calls to query different entities. If the user does not have permissions to use those methods, the poller will fall back to using entity queries		*For subscribed entities that have the replicateable attribute, the replication methods getUpdated() and getDeleted() will be used to reduce the number of API calls to query different entities. If the user does not have permissions to use those methods, the poller will fall back to using entity queries