MozillaWiki

Mozilla2:Profile Sharing: Difference between revisions

Mozilla2 Discussion

Mozilla2:Profile Sharing (view source)

Revision as of 05:30, 25 November 2004

1,646 bytes removed ,  25 November 2004
More wiki syntax updates (finished). This makes the page much easier to read in the wiki. I hope I didn't step on anyone's toes.
(Just cleaning up the headings (wiki syntax). Not finished.)
 
(More wiki syntax updates (finished). This makes the page much easier to read in the wiki. I hope I didn't step on anyone's toes.)
Line 1: Line 1:
==Proposal: A plan for profile sharing==
==Proposal: A plan for profile sharing==


[mailto:darin@meer.net Darin Fisher]
[mailto:darin@meer.net Darin Fisher]
 
<!--
<div class="para">
  <ol class="toc">
  <li><a href="#overview">Overview</a>
  <li><a href="#quotations">Requirements</a>
  <li><a href="#files">Files to be shared</a>
 
  <li><a href="#other_files">What about other files?</a>
  <li><a href="#scheme">A scheme for profile sharing</a>
  <li><a href="#next">Next steps</a>
  </ol>
</div>
-->


===Overview===
===Overview===
Line 48: Line 34:
* An application should be able to choose the profile data it shares. Moreover, in the case of shared preferences, an application should be able to choose the set of preferences it shares with the platform.  This level of granularity may be appropriate for other shared profile data as well.
* An application should be able to choose the profile data it shares. Moreover, in the case of shared preferences, an application should be able to choose the set of preferences it shares with the platform.  This level of granularity may be appropriate for other shared profile data as well.
* Profile sharing should not mandate the creation of new file formats for the shared profile data.
* Profile sharing should not mandate the creation of new file formats for the shared profile data.
* The profile sharing scheme must be <i>frozen</i> to a degree sufficient to ensure compatibility with future applications.
* The profile sharing scheme must be ''frozen'' to a degree sufficient to ensure compatibility with future applications.


===Files to be shared===
===Files to be shared===


  <p>The existing Mozilla-based applications store a number of different files
The existing Mozilla-based applications store a number of different files
    in their profiles.  Many of these files are application specific.  Some,
in their profiles.  Many of these files are application specific.  Some,
    however, can be generalized to the web-platform, and therefore are likely of  
however, can be generalized to the web-platform, and therefore are likely of  
    interest to other applications built on the Mozilla platform.  These are
interest to other applications built on the Mozilla platform.  These are
    the files that we are most interested in sharing.</p>
the files that we are most interested in sharing.


====Cache====
====Cache====
  <p>The web cache is by far the largest collection of files stored in the user
The web cache is by far the largest collection of files stored in the user
      profile.  Because of its large footprint on disk, sharing the disk cache is
profile.  Because of its large footprint on disk, sharing the disk cache is
      advantageous since it avoids duplicating a web cache for each Mozilla-based
advantageous since it avoids duplicating a web cache for each Mozilla-based
      application.  NOTE: Thunderbird does not enable the disk cache for mail,
application.  NOTE: Thunderbird does not enable the disk cache for mail,
      but extensions like Forumzilla might benefit from Thunderbird having access
but extensions like Forumzilla might benefit from Thunderbird having access
      to a shared disk cache.  Moreover: Seamonkey mail uses the disk cache for
to a shared disk cache.  Moreover: Seamonkey mail uses the disk cache for
      HTTP content loaded into the mail frame.  This gives Seamonkey mail an  
HTTP content loaded into the mail frame.  This gives Seamonkey mail an  
      advantage over Thunderbird when a user revisits a piece of HTML mail.</p>
advantage over Thunderbird when a user revisits a piece of HTML mail.


====Certificates====
====Certificates====
  <p>It is common for corporations to provide certificates to employees for use
It is common for corporations to provide certificates to employees for use
      to sign and seal emails as well as to access internal websites.  Therefore
to sign and seal emails as well as to access internal websites.  Therefore
      there is need for Firefox and Thunderbird to share certificates to avoid
there is need for Firefox and Thunderbird to share certificates to avoid
      having to manage separate certificate databases.  Lack of certificate
having to manage separate certificate databases.  Lack of certificate
      sharing may even be seen as a barrier by some enterprises upgrading to the
sharing may even be seen as a barrier by some enterprises upgrading to the
      new apps from Seamonkey or maybe IE+OE (assumption: IE and OE access
new apps from Seamonkey or maybe IE+OE (assumption: IE and OE access
      certificates from a central database managed by the operating system).</p>
certificates from a central database managed by the operating system).
 
  </div>


====Cookies====
====Cookies====
  <p>Cookies are an important part of the web-platform.  By supporting shared
Cookies are an important part of the web-platform.  By supporting shared
      cookies, we enable other applications to inherit user identity when they
cookies, we enable other applications to inherit user identity when they
      access web sites.  This could be used by Forumzilla, for example, to make
access web sites.  This could be used by Forumzilla, for example, to make
      it so that the view of slashdot.org is properly configured per the
it so that the view of slashdot.org is properly configured per the
      user's preferences for that site as configured using Firefox.</p>
user's preferences for that site as configured using Firefox.
  </div>


====Preferences====
====Preferences====


  <p>Sharing preferences is perhaps the main use case for profile sharing.  The
Sharing preferences is perhaps the main use case for profile sharing.  The
      standard example is a user's proxy settings which all Mozilla-based
standard example is a user's proxy settings which all Mozilla-based
      applications need in order to connect to the internet.  Allowing users to
applications need in order to connect to the internet.  Allowing users to
      avoid having to re-enter these settings for each application would be very
avoid having to re-enter these settings for each application would be very
      beneficial.  Moreover, when the user needs to make changes to the proxy
beneficial.  Moreover, when the user needs to make changes to the proxy
      settings, the user will appreciate the fact that those changes will be
settings, the user will appreciate the fact that those changes will be
      reflected to all Mozilla-based applications.  An independent options  
reflected to all Mozilla-based applications.  An independent options  
      dialog for shared preferences might make sense, but this is probably a
dialog for shared preferences might make sense, but this is probably a
      detail best left for another proposal ;-)</p>
detail best left for another proposal ;-)
  </div>
</div>
 


===What about other files?===
===What about other files?===


  <p>Most of the other files in the profile are application specific.  For example,
Most of the other files in the profile are application specific.  For example,
    bookmarks, history, address book, etc. are all very specific to individual
bookmarks, history, address book, etc. are all very specific to individual
    applications.  Some files, like the fastload file and localstore.rdf are also
applications.  Some files, like the fastload file and localstore.rdf are also
    application specific since their contents will depend on the application that
application specific since their contents will depend on the application that
    generated them.</p>
generated them.


  <p>In the future, it may be desirable to share some of these files with other
In the future, it may be desirable to share some of these files with other
    similar applications or with other instances of the same application.  But,
similar applications or with other instances of the same application.  But,
    again the primary focus of profile sharing is to support the Mozilla toolkit.
again the primary focus of profile sharing is to support the Mozilla toolkit.
    And, that means starting with sharing the web-platform specific profile data.</p>
And, that means starting with sharing the web-platform specific profile data.


  <div style="border: 2px solid green; padding: 0.5em;">
<div style="border: 2px solid green; padding: 0.5em;">
    <p><strong>Note from bsmedberg:</strong>
'''Note from bsmedberg:'''


    <p>to reduce the app-author-barrier to shared profiles, I intend to provide a RDF
to reduce the app-author-barrier to shared profiles, I intend to provide a RDF
        datasource that does sharing. This will probably not be my fancy database-driven
datasource that does sharing. This will probably not be my fancy database-driven
        datasource, but something that uses a simple N-triples format and keeps all the
datasource, but something that uses a simple N-triples format and keeps all the
        data in memory.
data in memory.


    <p>The IPC interfaces should be frozen for 2.0
The IPC interfaces should be frozen for 2.0


    <p><i>darin: Agreed.</i>
''darin: Agreed.''
  </div>
  </div>
  </div>


Line 133: Line 112:
====The IPC daemon and the transaction manager extension====
====The IPC daemon and the transaction manager extension====


    <p>The <a href="http://lxr.mozilla.org/mozilla/source/ipc/ipcd/">IPC daemon</a>
The [http://lxr.mozilla.org/mozilla/source/ipc/ipcd/ IPC daemon]
      was developed for the purpose of being used to enable profile sharing.  It
was developed for the purpose of being used to enable profile sharing.  It
      serves as a central process that clients can connect to in order to  
serves as a central process that clients can connect to in order to  
      communicate with one another or to communicate with code running in the
communicate with one another or to communicate with code running in the
      IPC daemon itself.  The IPC daemon is extensible via a simple "plug-in"
IPC daemon itself.  The IPC daemon is extensible via a simple "plug-in"
      <a href="http://lxr.mozilla.org/mozilla/source/ipc/ipcd/daemon/public/ipcModule.h">API</a>.</p>
[http://lxr.mozilla.org/mozilla/source/ipc/ipcd/daemon/public/ipcModule.h API]
 
    <p>The main benefit of the IPC daemon is that it can be used to synchronize
      access to shared profile data.  It provides basic locking functionality
      that does not depend on filesystem or operating system locking primitives
      (that are known to be buggy in some cases).
      Moreover, via the
      <a href="http://lxr.mozilla.org/mozilla/source/ipc/ipcd/extensions/transmngr/">transaction manager</a>
      IPC daemon extension,
      the IPC daemon can be used to actively synchronize in-memory and in-process
      copies of databases.</p>


The main benefit of the IPC daemon is that it can be used to synchronize
access to shared profile data.  It provides basic locking functionality
that does not depend on filesystem or operating system locking primitives
(that are known to be buggy in some cases). Moreover, via the
[http://lxr.mozilla.org/mozilla/source/ipc/ipcd/extensions/transmngr/transaction manager]
IPC daemon extension, the IPC daemon can be used to actively synchronize in-memory and in-process copies of databases.
        
        
    <p>Details on the transaction manager design are available
Details on the transaction manager design are available
      <a href="http://www.mozilla.org/projects/embedding/profileSharing/transaction-manager-tech-spec.html">here</a>.
[http://www.mozilla.org/projects/embedding/profileSharing/transaction-manager-tech-spec.html here].
      The transaction manager is a good solution for the problem of sharing preferences
The transaction manager is a good solution for the problem of sharing preferences
      and cookies since it minimally perturbs the backends for those modules.  The
and cookies since it minimally perturbs the backends for those modules.  The
      transaction manager API provides synchronized reading and writing as well as
transaction manager API provides synchronized reading and writing as well as
      notifications about changes to the databases.</p>
notifications about changes to the databases.
      
      
    <p>A client of the transaction manager simply attaches itself to a named queue,
A client of the transaction manager simply attaches itself to a named queue,
      waits for permission to get read access to the corresponding files in the
waits for permission to get read access to the corresponding files in the
      profile, reads those files, and then listens for change notifications on  
profile, reads those files, and then listens for change notifications on  
      that queue.  When the process makes changes to its copy of the database, it
that queue.  When the process makes changes to its copy of the database, it
      posts those changes to the queue so other processes can update their in-memory
posts those changes to the queue so other processes can update their in-memory
      copies.  When a process wishes to write its in-memory copy to disk, it again
copies.  When a process wishes to write its in-memory copy to disk, it again
      requests permission from the transaction manage and upon receiving permission
requests permission from the transaction manage and upon receiving permission
      it writes the files out to disk.  The transaction manager makes sure that
it writes the files out to disk.  The transaction manager makes sure that
      a client requesting write access receives all changes to the database before
a client requesting write access receives all changes to the database before
      granting it write access.  In that way the transaction manager ensures
granting it write access.  In that way the transaction manager ensures
      integrity of the serialized databases and protects against data loss.
integrity of the serialized databases and protects against data loss.
      Inotherwords, an application could not inadvertantly stomp over the data
Inotherwords, an application could not inadvertantly stomp over the data
      set by another application unless it ignored notifications from the
set by another application unless it ignored notifications from the
      transaction manager.</p>
transaction manager.


    <p>The transaction manager's protocol is very simple and is not at all profile
The transaction manager's protocol is very simple and is not at all profile
      specific.  It can even be used to synchronize memory-only databases that are
specific.  It can even be used to synchronize memory-only databases that are
      not persisted to the profile.</p>
not persisted to the profile.


====Supporting a shared disk cache====
====Supporting a shared disk cache====


    <p>The disk cache cannot be shared easily or efficiently using the transaction
The disk cache cannot be shared easily or efficiently using the transaction
      manager.  We really have two choices when it comes to sharing the disk cache.
manager.  We really have two choices when it comes to sharing the disk cache.
      We could develop an IPC daemon extension that manages the cache's data structure,
We could develop an IPC daemon extension that manages the cache's data structure,
      with a protocol that clients use to gain read or write access to particular
with a protocol that clients use to gain read or write access to particular
      sections of files on disk (recall that some disk cache files are stored in  
sections of files on disk (recall that some disk cache files are stored in  
      the block files).</p>
the block files).
        
        
    <p>Another solution for sharing the disk cache involves utilizing the IPC
Another solution for sharing the disk cache involves utilizing the IPC
      daemon only to manage reader/writer locks.  Then each client process would
daemon only to manage reader/writer locks.  Then each client process would
      acquire the appropriate lock(s) and proceed to access the data structures
acquire the appropriate lock(s) and proceed to access the data structures
      of the cache directly.  This probably involves mapping and unmapping
of the cache directly.  This probably involves mapping and unmapping
      the _CACHE_MAP_ and _CACHE_00X_ files frequently.  It remains to be seen if
the _CACHE_MAP_ and _CACHE_00X_ files frequently.  It remains to be seen if
      this would be prohibitively costly in terms of performance.  This solution
this would be prohibitively costly in terms of performance.  This solution
      also locks down more of the cache format since future applications will
also locks down more of the cache format since future applications will
      need to store files in the cache in a format that older applications can  
need to store files in the cache in a format that older applications can  
      still understand.</p>
still understand.


    <p>The IPC daemon module solution doesn't have as many constraints since we can
The IPC daemon module solution doesn't have as many constraints since we can
      hide many of the details of the cache data structure behind an IPC protocol.
hide many of the details of the cache data structure behind an IPC protocol.
      This may be enough of a reason to go with this kind of solution.</p>
This may be enough of a reason to go with this kind of solution.


====Supporting shared NSS databases====
====Supporting shared NSS databases====


    <p>The NSS .db files can be shared by creating a library with the name
The NSS .db files can be shared by creating a library with the name
      <code>SHLIB_PREFIX"rdb."SHLIB_SUFFIX</code>.  NSS will open this library
<code>SHLIB_PREFIX"rdb."SHLIB_SUFFIX</code>.  NSS will open this library
      and look for a symbol named <code>rdbopen</code>.  It should have the
and look for a symbol named <code>rdbopen</code>.  It should have the
      following signature:
following signature:


      <pre class="code">
DB *rdbopen(const char *appName, const char *prefix, const char *type, int flags);


  DB *rdbopen(const char *appName, const char *prefix, const char *type, int flags);
The only description of this API that I could find (outside of the source itself) is
      </pre>
[http://www.mail-archive.com/mozilla-crypto@mozilla.org/msg05139.html here].


    <p>The only description of this API that I could find (outside of the source itself) is
To share these .db files, we will likely need to link the mozdbm library into
      <a href="http://www.mail-archive.com/mozilla-crypto@mozilla.org/msg05139.html">here</a>.</p>
an IPC daemon module and invent a protocol to communicate with it. This
protocol would not need to be specific to certificates or NSS.


    <p>To share these .db files, we will likely need to link the mozdbm library into
However, implementing support for sharing this database puts an
      an IPC daemon module and invent a protocol to communicate with it.  This
additional constraint on the IPC daemon's client API.  It requires that API
      protocol would not need to be specific to certificates or NSS.</p>
to be thread-safe since NSS may query its databases on any thread and in
 
particular from the socket transport thread.
    <p>However, implementing support for sharing this database puts an
      additional constraint on the IPC daemon's client API.  It requires that API
      to be thread-safe since NSS may query its databases on any thread and in
      particular from the socket transport thread.</p>


===Next steps===
===Next steps===


  <ul>
* Agree on general plan for profile sharing</li>
  <li>Agree on general plan for profile sharing</li>
* Agree on location for shared profile data. Maybe something like this:<br>~/'''.mozilla-common'''/''&lt;profile-name&gt;''/ <br>~/.firefox/''&lt;profile-name&gt;''/ <br>~/.thunderbird/<''&lt;profile-name&gt;''/
  <li>Agree on location for shared profile data. Maybe something like this:
* Bring shared preferences and cookies online first (target 1.8 easily).</li>
 
* Bring shared certificates and cache online next (post 1.8 likely).</li>
    <p>
* What about ensuring that the cache is stored locally?  Need system API help.</li>  
 
    ~/<span style="color: blue;">.mozilla-common</span>/<i>&lt;profile-name&gt;</i>/ <br>
    ~/.firefox/<i>&lt;profile-name&gt;</i>/ <br>
    ~/.thunderbird/<i>&lt;profile-name&gt;</i>/ <br>
 
    </p>
 
  </li>
  <li>Bring shared preferences and cookies online first (target 1.8 easily).</li>
  <li>Bring shared certificates and cache online next (post 1.8 likely).</li>
  <li>What about ensuring that the cache is stored locally?  Need system API help.</li>
 
  </ul>
 
 
<br>


  <div style="border: 2px solid green; padding: 0.5em;">
<div style="border: 2px solid green; padding: 0.5em;">
    <p><strong>Note from bsmedberg:</strong>
'''Note from bsmedberg:'''


    <p>We need to specify how profile locking and profile sharing interact. In particular,
We need to specify how profile locking and profile sharing interact. In particular,
      can the profile lock files contain "locator" information to other apps that are already running
can the profile lock files contain "locator" information to other apps that are already running which need to share profile information?
      which need to share profile information?


    <p>Example:
Example:
    <ul>
* One instance of firefox begins running. There is no profile.lock, so it writes an "IPC locator" into that file: "socket: ./sharing.socket" or something like that.
      <li>One instance of firefox begins running. There is no profile.lock, so it writes
* A second instance of firefox is started. It sees that profile.lock already exists, so it reads the file, and tries to use the IPC mechanism to talk to "socket: ./sharing.socket".
          an "IPC locator" into that file: "socket: ./sharing.socket" or something like that.
      <li>A second instance of firefox is started. It sees that profile.lock already exists, so it
          reads the file, and tries to use the IPC mechanism to talk to "socket: ./sharing.socket".
    </ul>


    <p>By adding new "locator" types in the future we could support special situations like a central profile
By adding new "locator" types in the future we could support special situations like a central profile server, or multiple machines sharing a profile through TCP sockets.
      server, or multiple machines sharing a profile through TCP sockets.
   
   
    <p><i>darin: This sounds like an excellent idea to me.</i>
''darin: This sounds like an excellent idea to me.''
   </div>
   </div>
Kipphoward
6

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/156"