Architectural review and refinement - Revision history

Stevenlawrance at 18:02, 16 September 2007

2007-09-16T18:02:48Z

← Older revision		Revision as of 18:02, 16 September 2007
Line 42:		Line 42:
	In the cache, a write-back flag is included to effectively switch between online mode and offline mode. When write-back caching is enabled, the only the cache is updated. The backing store is not notified of the cached changes until the write-back flag is turned off. When the write-back flag is off, the caching becomes write-through, meaning that the backing store is notified synchronously. Note that event generation is performed by the cache when write-back is enabled. When write-back is disabled, the backing store generates the events that the cache propagates to its listeners. The cache will not, however, propagate events that do not alter the cached state, regardless of whether or not write-back is enabled.		In the cache, a write-back flag is included to effectively switch between online mode and offline mode. When write-back caching is enabled, the only the cache is updated. The backing store is not notified of the cached changes until the write-back flag is turned off. When the write-back flag is off, the caching becomes write-through, meaning that the backing store is notified synchronously. Note that event generation is performed by the cache when write-back is enabled. When write-back is disabled, the backing store generates the events that the cache propagates to its listeners. The cache will not, however, propagate events that do not alter the cached state, regardless of whether or not write-back is enabled.

	This architectural pattern permits the upper layers to primarily interact with the nsISalesforceBidirectionalPartner interface. As a result, the nsSalesforceBidirectionalPartnerCache class can be implemented in the future to get to the ~~Dreamforce~~ version as soon as possible. The nsSalesforceLocalBidirectionalPartner will be implemented for ~~Dreamforce~~ as a naive bidirectional API that only generates events for local changes.		This architectural pattern permits the upper layers to primarily interact with the nsISalesforceBidirectionalPartner interface. As a result, the nsSalesforceBidirectionalPartnerCache class can be implemented in the future to get to the M1 version as soon as possible. The nsSalesforceLocalBidirectionalPartner will be implemented for M1 as a naive bidirectional API that only generates events for local changes.

	The nsISalesforceBidirectionalPartnerPoller presents a unidirectional API as a nsISalesforceBidirectionalPartner 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.		The nsISalesforceBidirectionalPartnerPoller presents a unidirectional API as a nsISalesforceBidirectionalPartner 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.
Line 49:		Line 49:
	*If a large amount of data changed, the poller will notify listeners that possibly the entire state of the Salesforce.com data changed and that they should re-query anything that they are interested in. The nsSalesforceBidirectionalPartnerCache object will invalidate its entire cache upon receiving that event		*If a large amount of data changed, the poller will notify listeners that possibly the entire state of the Salesforce.com data changed and that they should re-query anything that they are interested in. The nsSalesforceBidirectionalPartnerCache object will invalidate its entire cache upon receiving that event

	The nsSalesforceLocalBidirectionalPartner class simply generates events based on local changes, such as calls to update(), deleteIds(), etc. This will be implemented in the ~~Dreamforce demo~~ and can be used in the full version as an option to enhance local performance, though the nsSalesforceBidirectionalPartnerCache class will be needed to suppress duplicate events in the full version.		The nsSalesforceLocalBidirectionalPartner class simply generates events based on local changes, such as calls to update(), deleteIds(), etc. This will be implemented in the M1 version and can be used in the full version as an option to enhance local performance, though the nsSalesforceBidirectionalPartnerCache class will be needed to suppress duplicate events in the full version.

	The nsSalesforcePartnerMetricsCollector class collects API usage statistics and includes methods for getting the average number of API calls per hour, the total number of API calls performed in the previous 24 hours, the predicted amount of time left before API usage is exceeded, and other useful numbers. In the full version, a special window can show this information.		The nsSalesforcePartnerMetricsCollector class collects API usage statistics and includes methods for getting the average number of API calls per hour, the total number of API calls performed in the previous 24 hours, the predicted amount of time left before API usage is exceeded, and other useful numbers. In the full version, a special window can show this information.
Line 56:		Line 56:
	*nsSalesforceBidirectionalPartnerCache -> nsSalesforceLocalBidirectionalPartner -> nsISalesforceBidirectionalPartnerPoller -> nsSalesforcePartnerMetricsCollector -> nsSalesforcePartner		*nsSalesforceBidirectionalPartnerCache -> nsSalesforceLocalBidirectionalPartner -> nsISalesforceBidirectionalPartnerPoller -> nsSalesforcePartnerMetricsCollector -> nsSalesforcePartner

	In the ~~Dreamforce~~ implementation, the classes will likely be invoked with the following chain of delegates:		In the M1 implementation, the classes will likely be invoked with the following chain of delegates:
	*nsSalesforceLocalBidirectionalPartner -> nsSalesforcePartner		*nsSalesforceLocalBidirectionalPartner -> nsSalesforcePartner

Line 119:		Line 119:

	====Folders====		====Folders====
	The following table lists which entity types as columns can be used to store an email message within an entity instance. Because the combination of Attachment and Document can be used on all entities, the ~~Dreamforce~~ release will turn all emails into either Attachment or Document objects when copying or moving a message to Salesforce.com.		The following table lists which entity types as columns can be used to store an email message within an entity instance. Because the combination of Attachment and Document can be used on all entities, the M1 release will turn all emails into either Attachment or Document objects when copying or moving a message to Salesforce.com.

	{\|border="1"		{\|border="1"

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

2007-09-09T19:54:39Z

Thunderbird interface implementation layer (model)

← Older revision		Revision as of 19:54, 9 September 2007
Line 91:		Line 91:
	*'''[[Requirements#R2: Address Book\|Address Book]]'''		*'''[[Requirements#R2: Address Book\|Address Book]]'''
	**nsThunderforceAddressBook		**nsThunderforceAddressBook
	***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIAbDirFactory.html nsIAbDirFactory]
	***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIAbDirectory.html nsIAbDirectory]		***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIAbDirectory.html nsIAbDirectory]
	***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIAbDirectoryQuery.html nsIAbDirectoryQuery]		***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIAbDirectoryQuery.html nsIAbDirectoryQuery]
Line 97:		Line 96:
	***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIClassInfo.html nsIClassInfo]		***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIClassInfo.html nsIClassInfo]
	***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIRDFResource.html nsIRDFResource]		***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIRDFResource.html nsIRDFResource]
			**nsThunderforceAddressBookFactory
			***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIAbDirFactory.html nsIAbDirFactory]
	**nsThunderforceAddressCard		**nsThunderforceAddressCard
	***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIAbCard.html nsIAbCard]		***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIAbCard.html nsIAbCard]

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

2007-09-09T18:40:29Z

Thunderbird interface implementation layer (model)

← Older revision		Revision as of 18:40, 9 September 2007
Line 91:		Line 91:
	*'''[[Requirements#R2: Address Book\|Address Book]]'''		*'''[[Requirements#R2: Address Book\|Address Book]]'''
	**nsThunderforceAddressBook		**nsThunderforceAddressBook
			***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIAbDirFactory.html nsIAbDirFactory]
	***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIAbDirectory.html nsIAbDirectory]		***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIAbDirectory.html nsIAbDirectory]
	***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIAbDirectoryQuery.html nsIAbDirectoryQuery]		***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIAbDirectoryQuery.html nsIAbDirectoryQuery]

Stevenlawrance: /* Folders */

2007-09-07T17:29:29Z

Folders

← Older revision		Revision as of 17:29, 7 September 2007
Line 123:		Line 123:
	\|'''[http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_attachment.htm Attachment]'''		\|'''[http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_attachment.htm Attachment]'''
	\|'''[http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_note.htm Note]'''		\|'''[http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_note.htm Note]'''
			\|'''[http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_task.htm Task]'''
	\|'''[http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_emailmessage.htm EmailMessage]'''		\|'''[http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_emailmessage.htm EmailMessage]'''
	\|'''[http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_document.htm Document]'''		\|'''[http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_document.htm Document]'''
	\|-		\|-
	\|Account		\|Account
			\|<font color="#007700">yes</font>
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
Line 133:		Line 135:
	\|-		\|-
	\|Asset		\|Asset
			\|<font color="#007700">yes</font>
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
Line 141:		Line 144:
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
	\|<font color="#AA0000">no</font>		\|<font color="#AA0000">no</font>
			\|<font color="#007700">yes</font>
	\|<font color="#AA0000">no</font>		\|<font color="#AA0000">no</font>
	\|<font color="#AA0000">no</font>		\|<font color="#AA0000">no</font>
Line 147:		Line 151:
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
	\|<font color="#AA0000">no</font>		\|<font color="#AA0000">no</font>
			\|<font color="#007700">yes</font>
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
	\|<font color="#AA0000">no</font>		\|<font color="#AA0000">no</font>
	\|-		\|-
	\|Contact		\|Contact
			\|<font color="#007700">yes</font>
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
Line 157:		Line 163:
	\|-		\|-
	\|Contract		\|Contract
			\|<font color="#007700">yes</font>
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
Line 163:		Line 170:
	\|-		\|-
	\|Custom Objects		\|Custom Objects
			\|<font color="#007700">yes</font>
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
Line 170:		Line 178:
	\|EmailTemplate		\|EmailTemplate
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
			\|<font color="#AA0000">no</font>
	\|<font color="#AA0000">no</font>		\|<font color="#AA0000">no</font>
	\|<font color="#AA0000">no</font>		\|<font color="#AA0000">no</font>
Line 176:		Line 185:
	\|Event		\|Event
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
			\|<font color="#AA0000">no</font>
	\|<font color="#AA0000">no</font>		\|<font color="#AA0000">no</font>
	\|<font color="#AA0000">no</font>		\|<font color="#AA0000">no</font>
Line 181:		Line 191:
	\|-		\|-
	\|Folder		\|Folder
			\|<font color="#AA0000">no</font>
	\|<font color="#AA0000">no</font>		\|<font color="#AA0000">no</font>
	\|<font color="#AA0000">no</font>		\|<font color="#AA0000">no</font>
Line 187:		Line 198:
	\|-		\|-
	\|Lead		\|Lead
			\|<font color="#007700">yes</font>
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
Line 193:		Line 205:
	\|-		\|-
	\|Opportunity		\|Opportunity
			\|<font color="#007700">yes</font>
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
Line 199:		Line 212:
	\|-		\|-
	\|Product2		\|Product2
			\|<font color="#007700">yes</font>
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
Line 207:		Line 221:
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
	\|<font color="#AA0000">no</font>		\|<font color="#AA0000">no</font>
			\|<font color="#007700">yes</font>
	\|<font color="#AA0000">no</font>		\|<font color="#AA0000">no</font>
	\|<font color="#AA0000">no</font>		\|<font color="#AA0000">no</font>
Line 212:		Line 227:
	\|Task		\|Task
	\|<font color="#007700">yes</font>		\|<font color="#007700">yes</font>
			\|<font color="#AA0000">no</font>
	\|<font color="#AA0000">no</font>		\|<font color="#AA0000">no</font>
	\|<font color="#AA0000">no</font>		\|<font color="#AA0000">no</font>
Line 217:		Line 233:
	\|-		\|-
	\|User		\|User
			\|<font color="#AA0000">no</font>
	\|<font color="#AA0000">no</font>		\|<font color="#AA0000">no</font>
	\|<font color="#AA0000">no</font>		\|<font color="#AA0000">no</font>

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

2007-08-26T17:46:14Z

Thunderbird interface implementation layer (model)

← Older revision		Revision as of 17:46, 26 August 2007
Line 89:		Line 89:
	**nsThunderforceMessageHeader		**nsThunderforceMessageHeader
	***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIMsgDBHdr.html nsIMsgDBHdr]		***[http://www.xulplanet.com/references/xpcomref/ifaces/nsIMsgDBHdr.html nsIMsgDBHdr]
	**nsThunderforceAttachmentFolder
	***nsThunderforceFolder
	**nsThunderforceNoteFolder
	***nsThunderforceFolder
	**nsThunderforceEmailMessageFolder
	***nsThunderforceFolder
	**nsThunderforceDocumentFolder
	***nsThunderforceFolder
	*'''[[Requirements#R2: Address Book\|Address Book]]'''		*'''[[Requirements#R2: Address Book\|Address Book]]'''
	**nsThunderforceAddressBook		**nsThunderforceAddressBook

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

2007-08-26T17:39:05Z

Thunderbird interface implementation layer (model)

← Older revision		Revision as of 17:39, 26 August 2007
Line 61:		Line 61:
	===Thunderbird interface implementation layer (model)===		===Thunderbird interface implementation layer (model)===
	The following tree lists each high-level class that will be implemented and the interfaces that they implement.		The following tree lists each high-level class that will be implemented and the interfaces that they implement.
	*'''[[Requirements#R1: Account Type\|Account Type]]'''<br>[[Image:Thunderbird Inferface Module View.png]]		*'''[[Requirements#R1: Account Type\|Account Type]]'''<br>[[Image:Thunderbird Inferface Module View.png]]<br>[https://www.moonlightdesign.org/thunderforce/svn/trunk/architecture/Architecture/Thunderbird%20Inferface%20Module%20View.uxf Source UMLet diagram]
	**nsThunderforceServer		**nsThunderforceServer
	***@mozilla.org/messenger/server;1?type=imap		***@mozilla.org/messenger/server;1?type=imap

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

2007-08-26T17:37:52Z

Salesforce.com data layer (model)

← Older revision		Revision as of 17:37, 26 August 2007
Line 28:		Line 28:
	[[Image:Architecture Module View - Salesforce.com Model.png]]		[[Image:Architecture Module View - Salesforce.com Model.png]]

	[https://www.moonlightdesign.org/thunderforce/svn/trunk/architecture/Architecture/Module%20View%20-%20Salesforce.com%20Model.uxf Source UMLet diagram].		[https://www.moonlightdesign.org/thunderforce/svn/trunk/architecture/Architecture/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: /* Thunderbird interface implementation layer (model) */

2007-08-26T17:37:26Z

Thunderbird interface implementation layer (model)

← Older revision		Revision as of 17:37, 26 August 2007
Line 60:		Line 60:

	===Thunderbird interface implementation layer (model)===		===Thunderbird interface implementation layer (model)===
	~~This section~~ lists ~~the Thunderforce classes~~ and the interfaces that they implement.		The following tree lists each high-level class that will be implemented and the interfaces that they implement.
	*'''[[Requirements#R1: Account Type\|Account Type]]'''		*'''[[Requirements#R1: Account Type\|Account Type]]'''<br>[[Image:Thunderbird Inferface Module View.png]]
	**nsThunderforceServer		**nsThunderforceServer
	***@mozilla.org/messenger/server;1?type=imap		***@mozilla.org/messenger/server;1?type=imap

Stevenlawrance: /* Module View */

2007-08-26T09:00:03Z

Module View

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

2007-08-26T08:21:54Z

Thunderbird interface implementation layer (model)

← Older revision		Revision as of 08:21, 26 August 2007
Line 60:		Line 60:

	===Thunderbird interface implementation layer (model)===		===Thunderbird interface implementation layer (model)===
	This section ~~describes~~ the classes and interfaces ~~used in the Thunderbird interface implementation layer by dependency. Branches generally need to be implemented before their leafs can be implemented~~.		This section lists the Thunderforce classes and the interfaces that they implement.
	*'''[[Requirements#R1: Account Type\|Account Type]]'''		*'''[[Requirements#R1: Account Type\|Account Type]]'''
	**nsThunderforceServer		**nsThunderforceServer

← Older revision		Revision as of 09:00, 26 August 2007
Line 26:		Line 26:

	===Salesforce.com data layer (model)===		===Salesforce.com data layer (model)===
	[[Image:Module View - Salesforce.com Model.~~jpg~~]]		[[Image:Architecture Module View - Salesforce.com Model.png]]

	[https://www.moonlightdesign.org/thunderforce/svn/trunk/architecture/Architecture/Module%20View%20-%20Salesforce.com%20Model.uxf Source UMLet diagram]~~. This diagram will be revised soon to include LocalBidirectionalAPI and APIMetricsCollector~~.		[https://www.moonlightdesign.org/thunderforce/svn/trunk/architecture/Architecture/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.
Line 34:		Line 34:
	In general, the methods in the API interface are those that are in the Salesforce.com AJAX toolkit. The AJAX toolkit's implementation will, indeed, exist mostly unchanged as the thunderforce.sforce.Salesforce object.		In general, the methods in the API interface are those that are in the Salesforce.com AJAX toolkit. The AJAX toolkit's implementation will, indeed, exist mostly unchanged as the thunderforce.sforce.Salesforce object.

	To turn Salesforce.com into a bidirectional API with event notification, the ~~BidirectionalAPIPoller~~ will wrap the ~~Salesforce~~ object to implement the ~~BidirectionalAPI~~ interface. This permits future extensibility with both non-polling solutions such as workflow outbound messages and aggregators such as local Salesforce.com cache servers.		To turn Salesforce.com into a bidirectional API with event notification, the nsISalesforceBidirectionalPartnerPoller will wrap the nsSalesforcePartner object to implement the nsISalesforceBidirectionalPartner interface. This permits future extensibility with both non-polling solutions such as workflow outbound messages and aggregators such as local Salesforce.com cache servers.

	To promote performance, the ~~Cache~~ object will store the returned values of method calls into memory and, with the offline functionality, a SQLite database. When notifications of changes from the backing store arrive, the cached return values that might be affected by those changes are invalidated. To balance performance with memory, the cache will manage its use of memory based on call and time statistics.		To promote performance, the nsSalesforceBidirectionalPartnerCache object will store the returned values of method calls into memory and, with the offline functionality, a SQLite database. When notifications of changes from the backing store arrive, the cached return values that might be affected by those changes are invalidated. To balance performance with memory, the cache will manage its use of memory based on call and time statistics.
	*As an example of cache invalidation, a change to an account object invalidates that object, that object's ancestor objects, queries that involve that entity, and searches that involve that entity		*As an example of cache invalidation, a change to an account object invalidates that object, that object's ancestor objects, queries that involve that entity, and searches that involve that entity
	*Queries and searches are special functions that might be handled intelligently in specific update cases to further improve cache performance		*Queries and searches are special functions that might be handled intelligently in specific update cases to further improve cache performance
Line 42:		Line 42:
	In the cache, a write-back flag is included to effectively switch between online mode and offline mode. When write-back caching is enabled, the only the cache is updated. The backing store is not notified of the cached changes until the write-back flag is turned off. When the write-back flag is off, the caching becomes write-through, meaning that the backing store is notified synchronously. Note that event generation is performed by the cache when write-back is enabled. When write-back is disabled, the backing store generates the events that the cache propagates to its listeners. The cache will not, however, propagate events that do not alter the cached state, regardless of whether or not write-back is enabled.		In the cache, a write-back flag is included to effectively switch between online mode and offline mode. When write-back caching is enabled, the only the cache is updated. The backing store is not notified of the cached changes until the write-back flag is turned off. When the write-back flag is off, the caching becomes write-through, meaning that the backing store is notified synchronously. Note that event generation is performed by the cache when write-back is enabled. When write-back is disabled, the backing store generates the events that the cache propagates to its listeners. The cache will not, however, propagate events that do not alter the cached state, regardless of whether or not write-back is enabled.

	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 to the Dreamforce version as soon as possible. The ~~LocalBidirectionalAPI~~ will be implemented for Dreamforce as a naive bidirectional API that only generates events for local changes.		This architectural pattern permits the upper layers to primarily interact with the nsISalesforceBidirectionalPartner interface. As a result, the nsSalesforceBidirectionalPartnerCache class can be implemented in the future to get to the Dreamforce version as soon as possible. The nsSalesforceLocalBidirectionalPartner will be implemented for Dreamforce as a naive bidirectional API that only generates events for local changes.

	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.		The nsISalesforceBidirectionalPartnerPoller presents a unidirectional API as a nsISalesforceBidirectionalPartner 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 entityRefreshIntervals. 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
	*If a large amount of data changed, the poller will notify listeners that possibly the entire state of the Salesforce.com data changed and that they should re-query anything that they are interested in. The ~~Cache~~ object will invalidate its entire cache upon receiving that event		*If a large amount of data changed, the poller will notify listeners that possibly the entire state of the Salesforce.com data changed and that they should re-query anything that they are interested in. The nsSalesforceBidirectionalPartnerCache object will invalidate its entire cache upon receiving that event

	The ~~LocalBidirectionalAPI~~ class simply generates events based on local changes, such as calls to update(), deleteIds(), etc. This will be implemented in the Dreamforce demo and can be used in the full version as an option to enhance local performance, though the ~~Cache~~ class will be needed to suppress duplicate events in the full version.		The nsSalesforceLocalBidirectionalPartner class simply generates events based on local changes, such as calls to update(), deleteIds(), etc. This will be implemented in the Dreamforce demo and can be used in the full version as an option to enhance local performance, though the nsSalesforceBidirectionalPartnerCache class will be needed to suppress duplicate events in the full version.

	The ~~APIMetricsCollector~~ class collects API usage statistics and includes methods for getting the average number of API calls per hour, the total number of API calls performed in the previous 24 hours, the predicted amount of time left before API usage is exceeded, and other useful numbers. In the full version, a special window can show this information.		The nsSalesforcePartnerMetricsCollector class collects API usage statistics and includes methods for getting the average number of API calls per hour, the total number of API calls performed in the previous 24 hours, the predicted amount of time left before API usage is exceeded, and other useful numbers. In the full version, a special window can show this information.

	In the full implementation, the classes will likely be invoked with the following chain of delegates:		In the full implementation, the classes will likely be invoked with the following chain of delegates:
	*~~Cache~~ -> ~~LocalBidirectionalAPI~~ -> ~~BidirectionalAPIPoller~~ -> ~~APIMetricsCollector~~ -> ~~Salesforce~~		*nsSalesforceBidirectionalPartnerCache -> nsSalesforceLocalBidirectionalPartner -> nsISalesforceBidirectionalPartnerPoller -> nsSalesforcePartnerMetricsCollector -> nsSalesforcePartner

	In the Dreamforce implementation, the classes will likely be invoked with the following chain of delegates:		In the Dreamforce implementation, the classes will likely be invoked with the following chain of delegates:
	*~~LocalBidirectionalAPI~~ -> ~~Salesforce~~		*nsSalesforceLocalBidirectionalPartner -> nsSalesforcePartner

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