| components.conf |
|
2347 |
| EwsClient.h |
|
475 |
| EwsFolder.cpp |
|
21385 |
| EwsFolder.h |
Generate or retrieve an EWS API client capable of interacting with the EWS
server this folder depends from.
|
3372 |
| EwsIncomingServer.cpp |
Creates a new folder with the specified parent, name, and flags.
|
10075 |
| EwsIncomingServer.h |
|
2019 |
| EwsMessageChannel.cpp |
A listener for a message download, which writes the message's content into
the relevant message store.
Once the message has been downloaded and written into the store, this
listener will also use the provided docshell or stream listener, if any, to
display or stream the message's content from the store (using
`EwsOfflineMessageChannel`). If both a docshell and a stream listener are
provided, only the docshell is used.
|
17736 |
| EwsMessageChannel.h |
A channel for streaming an EWS message out of the relevant message store.
The message URI is expected to use the form:
x-moz-ews://{user}@{server}/{Path/To/Folder}/{MessageKey}
Note that no specific encoding is applied to the folder path (besides the
standard URL path encoding).
Translating this URI into a message header (which we can use to stream the
message's content from the message store) is done through calling
`EwsService::MessageURIToMsgHdr`.
Design considerations on the form of "x-moz-ews" URIs: it includes the
message key in the path to follow RESTful semantics. The message is the
resource the URI is pointing to, "located" to the path preceding its key
(i.e. the path to the folder). Some alternatives that were considered are:
* Setting the key as a query parameter, however we seem to use query
parameters to control how the message is fetched and/or rendered/streamed,
not which message the operation is about, so it would be inconsistent with
the rest of the code.
* Following the lead of `[protocol]-message` URIs, with the message key
located in the "ref" part of the URI. However, this does not work well for
displaying messages, as the DocShell does not take this part of the URI
into account to decide whether it matches with a document that's already
currently rendered (so it doesn't need to render it again); this would
lead to every message in a folder being considered the same document.
|
4741 |
| EwsMessageCopyHandler.cpp |
|
18161 |
| EwsMessageCopyHandler.h |
A handler for a single copy/move operation, the source for which can be
either a file or a folder.
An instance of `MessageCopyHandler` is created for each copy/move operation,
but a single copy/move operation can target multiple messages.
It iterates over each message in the queue sequentially and
1. streams it from the relevant message service
2. creates a new item on the server for the message
3. creates a local copy of the message
4. triggers step 1 for the next message (if there is one)
The current process of copying or moving a message from a folder is the
following (assuming no failures, and excepting signaling start/stop/progress
updates to the source folder and the copy listener):
1. A consumer requests an array of messages to be copied to an EWS folder
(`EwsFolder::CopyMessages()`).
2. The EWS folder class instantiates a copy handler, and instructs it to
start the operation (`MessageCopyHandler::StartCopyingNextMessage()`).
3. The copy handler instructs the message service relevant to the first
message in line to stream said message's content to the handler
(`nsIMsgMessageService::CopyMessage()`).
4. Once the full message content has been streamed, the message service
then signals to the copy handler that it has finished streaming the
message's content (`MessageCopyHandler::EndCopy()`).
5. The copy handler instructs its EWS client to begin creating an item for
the message on the EWS server (`IEwsClient::CreateMessage()`). It is
called with an instance of `MessageCreateCallbacks`, which performs
database operations and notifies the copy handler about the operation's
progress.
6. Once the item has been created on the EWS server, the EWS client
instructs its callbacks instance to save the message's content to the
relevant local database and message store
(`MessageCreateCallbacks::OnRemoteCreateSuccessful()`).
7. The EWS client then notifies the copy handler (through its callbacks)
that the new message has been successfully created, both on the EWS
server and locally (`MessageCopyHandler::OnCreateFinished()`).
8. If the operation is a move, the copy handler deletes the source message
on the source folder.
9. The copy handler repeats this process from steps 3 onwards until every
message in the original array has been copied or moved.
10. Once the operation has completed, or if there has been a failure
during the operation, the copy handler notifies the source folder and
the global copy service about the end and final status of the
operation (`MessageCopyHandler::OnCopyCompleted()`).
When copying from a file, the same process is followed, apart from a few
changes:
* Step 3 is skipped, as the copy handler already holds a copy of the
message's content (in the file).
* Step 8 is skipped, as we're always dealing with a copy operation when
the source is a file.
* Step 9 is skipped, as we're always dealing with a single message when
the source is a file.
|
8581 |
| EwsProtocolHandler.cpp |
|
3103 |
| EwsProtocolHandler.h |
|
549 |
| EwsProtocolInfo.cpp |
|
4382 |
| EwsProtocolInfo.h |
|
534 |
| EwsService.cpp |
|
11612 |
| EwsService.h |
Retrieves the message at the given URI, downloading it first if requested,
then optionally converting it to the desired output format.
When fetching a part of a message (e.g. to save an attachment), the URI's
query is expected to describe which part to isolate and what the output
format should be. This query is processed by the stream converter, and thus
will be ignored unless `aConvert` is true.
|
3270 |
| IEwsClient.idl |
A client for communicating with a Microsoft Exchange server via Exchange Web
Services.
This interface is intended to provide an abstraction of EWS operations to
bridge the foreign function interface between the components of a Thunderbird
mail protocol implementation and a single implementation of those EWS ops.
With the exception of initialization, all client operations are intended to
be asynchronous, with implementations of the callback interfaces used to
handle the results of the operations or handle errors.
|
8055 |
| IEwsIncomingServer.idl |
IEwsIncomingServer is intended as a workaround for limitations in the folder
lookup service.
EWS folders require an EWS client object in order to fetch new messages. The
folder itself, however, does not have access to all of the details needed to
create such a client. This information is part of the incoming server.
Due to depending on the folder lookup service to create new folders, it is
not possible to give the folder a direct handle to its associated server, so
we are forced to go through XPCOM.
|
922 |
| moz.build |
|
830 |
| nsEwsOutgoingServer.h |
|
652 |