USE CASES
---------

1.0 Client Startup
------------------



1.1 List backends
-----------------



Every backend provides exactly one "root folder", which is a "virtual"
folder containing the provided folder. The root folder may contain
messages, although it isn't recommeneded.


1.2 Select folder
-----------------

Example: The user clicks on a folder icon or navigates through the
list to a folder and presses [space].

Expected response: The UI should list all messages in the folder in a
message view.

If the folder is the root folder, no action may be taken.



1.3 Open folder
---------------

Example: The user double-clicks on a folder icon or presses [space] on
an already selected folder

Expected response: If the folder isn't selected already it should get
selected. The UI should expand the folder and show sub folders with
folder names and message count.

If the folder is the root folder and the backend is a client-server
based, this usually signals that it is time to connect to the server
and get the list of child folders.

Q: How do we know if we should get all child folders or just the
subscribed? Who keeps the list of subscribed folders?



1.4 Close folder
----------------

Example: The user clicks on an expanded folder icon or presses [space]
on an already open folder.

Expected response: The ui should hide sub folders.


Extra: All subfolders and their messages may be pruned by the engine
to minimize memory consumption.


1.5 Select message
------------------



1.6 Compose message
-------------------


1.7 Send message
----------------


























































	
Benefits:
---------

- Removed complexity from the backend
	





UI:
---
Folder* f = engine->provider->GetRootFolder();
f.Open();


ENGINE:
-------

class Message {

      // called from backend or from message composer
      SetBody/Part/

      SetMessageHeader
      SetMessageHeaders

      // called from ui or from message sender backend

      GetBody/Part/
      GetMessageHeader
      GetMessageHeaders
}

class Folder {

}


Folder::Open() {
  backend->Open(this);
}



Q: What if the backend needs to store additional information in a
   Folder or a Message?

Q: Is there any backend that's capable of retreiving messages already
   sorted in a folder? IMAP?


MESSAGEPROVIDE (BACKEND):
-------------------------

class Backend {

      status_t Open(Folder* folder) {
      }
      

};
DESIGN
------

All ACTIONS is made to the provider. This is to avoid having each
instance of Folder, Message, etc keep a back reference to the provider
in case it has to be consulted (e.g. client server protocols).

All ATTRIBUTES that can be assumed is stored on the client side in the
backend is stored in each object, Folder, Message, etc.



	


threader
  arranges messages in hierarchy based on reply-chains

treebuilder
  arranges folders in hiearchy based on names

  	







provider

  getrootfolder


folder

  folder* getfolder(idx)
  open
  close
  getname	

---------------------------------
  
IProvider		

  


----------------------------------
  

FOLDER
------
  list hierarchy
  list subscribed




	



         IFolder
            |
       +----+----+
       |         |
    Folder --o FolderImpl
                 |
		 |
	      IMAPFolder   

	

class IFolder {



};

class Folder : public IFolder, FolderImplObserver {
public:

  Open() {
     m_impl->Open();
  }


private:

  FolderImpl* m_impl;
  
};

class FolderImpl : public IFolder {


protected:

  Update() {
     m_observer->Changed()
  }

private:

   FolderObserver* m_observer;

}

class IMAPFolder : public FolderImpl {

  Open() {
      // connect to server
      // query for child folders
      Update();
  }

private:

  char* internal_name;
  
}
