Design for Simias iFolder Linux Client
From iFolder
From Boyd's Blog, 'http://blog.timothy.ws/2006/09/ifolder-linux-client-brain-dump.html'
Simias was originally created as a generic data store where you could create collections of information and store them. Simias handles synchronizing the collections from machine to machine. Simias allows you to share collections of data with other users and controls the access levels each user has to the collections (Administrator, Read/Write, Read Only).
iFolder iFolder 3 is built on top of Simias. Each iFolder is essentially a Simias Collection. The iFolder Simias Collection contains nodes of data that represent files on a computer. Simias synchronizes these nodes of data between computers. A separate synchronization module uses these nodes to actually synchronize the files the nodes represent.
- [ ] iFolder Client
- [ ] Runs in two (2) processes
- [ ] Simias Process
- [ ] Runs an embedded web server
- [ ] Provides WebServices API to access Simias Database
- [ ] Provides WebServices API to access
iFolder-specific calls (which then manipulate the
Simias Database to do iFolder-specific tasks)
- [ ] Web server opens access over a random socket
- [ ] Socket port is written to
~/.local/share/simias/.local.if and this is
how the iFolder GUI Client knows how to make
WebService calls
- [ ] Simias Event Server
- [ ] Broadcasts messages over an open socket
- [ ] Example events:
- [ ] NodeCreated
- [ ] NodeDeleted
- [ ] NodeChanged
- [ ] CollectionSync
- [ ] FileSync
- [ ] These events each contain more detail about
the node/collection
- [ ] iFolder GUI Process
- [ ] Overview
- [ ] Is a WebService Client to talk with the
WebServices running in the Simias Process
- [ ] MVC Architecture
- [ ] I made a fairly big effort to move to true MVC in
3.4 by attempting to separate the data from the
Gtk widgets and have some notion of controllers
handle the heavy lifting.
- [ ] History: The older GUI code used to hook up
directly with SimiasEventBroker and the GUI would
end up being out of sync because there'd be
multiple copies of the data (i.e., two different
dialogs would have their own copy in memory of an
iFolder)
- [ ] iFolder 3.4 has most dialogs using the
Controllers, but there are still places that need
to be cleaned up
- [ ] Modules
- [ ] Simias Event Broker
- [ ] Source:
src/LinuxClient/library/SimiasEventBroker.cs
- [ ] Purpose:
- [ ] Registers as a Simias Event Client
- [ ] Receives events from the Simias Event
Server
- [ ] Relays the events to the rest of the GUI
by forcing events to be handled on the
main GUI thread (you can't modify
anything in Gtk without being in the main
thread)
- [ ] Notes:
- [ ] All GUI windows/widgets should not use
SimiasEventBroker directly. You should
use a Controller class instead.
- [ ] DomainController
- [ ] Source:
src/LinuxClient/library/DomainController.cs
- [ ] Purpose:
- [ ] Manages the master list of Domains
(iFolder Accounts) in memory
- [ ] Provides API for connecting to new
accounts, removing accounts, and
authentication to accounts
- [ ] Example APIs:
- [ ] AddDomain
- [ ] RemoveDomain
- [ ] AuthenticateDomain
- [ ] LogoutDomain
- [ ] ActivateDomain
- [ ] InactivateDomain
- [ ] Propogates Domain events to the rest of
the GUI
- [ ] Example events:
- [ ] DomainAdded
- [ ] DomainDeleted
- [ ] DomainHostModified
- [ ] DomainLoggedIn
- [ ] DomainLoggedOut
- [ ] Notes:
- [ ] All GUI widgets/windows should register
with DomainController to get events about
Domains
- [ ] iFolderController & iFolderData
- [ ] Sources:
- [ ] src/LinuxClient/library/iFolderController.
cs
- [ ] src/LinuxClient/library/iFolderData.cs
- [ ] Purpose:
- [ ] Manages the master list of iFolders in
memory
- [ ] Access the list by calling:
- [ ] Gtk.ListStore ifolders =
iFolderData.GetData().iFolders;
- [ ] ListStore is all ready to be used
in a Gtk.TreeView or Gtk.ListView
or any other widget that uses a
TreeModel.
- [ ] Provides APIs for creating, reverting,
deleting iFolders
- [ ] Example APIs:
- [ ] CreateiFolder
- [ ] GetiFolder
- [ ] ReadiFolder
- [ ] RevertiFolder
- [ ] DeleteiFolder
- [ ] Propogates iFolder events to the rest of
the GUI
- [ ] Example events:
- [ ] iFolderAdded
- [ ] iFolderDeleted
- [ ] iFolderChanged
- [ ] Notes:
- [ ] All GUI widgets/windows should register
with iFolderController to get events
about iFolders
- [ ] I was in the process of migrating
iFolderData into iFolderController but
ran out of time and had to leave it the
way it was. It would be more clean to
remove iFolderData and move it into
iFolderController.
- [ ] GUI Modules
- [ ] iFolderWindow
- [ ] The main iFolder Window
- [ ] Uses hacked-together custom widget
iFolderIconView which was intended to
be similar to Gtk.IconView but isn't
quite fully implemented. Sorry, this
was my first attempt at writing a
custom widget and it didn't turn out
exactly right. It's not too bad
though.
- [ ] Uses Gtk.TreeModelFilters to filter
out iFolderData.iFolders (ListStore)
into different sections depending on
the SearchEntry.
- [ ] Arranges the iFolders by Server
- [ ] LogWindow
- [ ] Shows a synchronization log
- [ ] PreferencesWindow
- [ ] Set main application preferences
- [ ] Add/Remove accounts
- [ ] AddAccountWizard
- [ ] Uses a Gnome.Druid to step a user through
connecting to an iFolder Server.
- [ ] This should be modified to NOT use Gnome
if you want to have the code run in
Windows.
- [ ] iFolderPropertiesDialog
- [ ] Properties for an individual iFolder are
shown here
- [ ] iFolderPropSharingPage allows the user to
set up sharing
- [ ] Modal Dialogs (dialogs/windows that should be on top
and prevent interaction with all other iFolder
windows)
- [ ] Problem:
- [ ] Windows in iFolder can be opened from
multiple places
- [ ] If you just mark a dialog as "modal",
users are still able to access the tray
icon and open other windows
- [ ] Solution:
- [ ] Modal Dialog Registration
- [ ] Util.cs contains methods of checking for an
existing modal dialog that spans the entire
iFolder application (so that the tray and
other windows can check for them)
- [ ] If you want to open a new modal dialog, you
have to first register it with the Util.cs
method. If successful, you can go ahead and
show the dialog. If not, you should force
the existing modal dialog to come to the
front.
