Re: One (larger) feature request: .Mac improvements

I don't recall seeing much of a response to this post... did I miss them?

I would be very interested in the ability to sync workspaces across 
machines, since I've started to use one as a "get to this later" pile 
which I would like to share between machines. I have tried to "trick" 
OW into using a common Workspaces folder on my iDisk, but so far that 
has not stuck.

Any suggestions?

Thanks,

J

At 12:00 -0700 4/9/06, [email protected] wrote:
>Message: 2
>Date: Sat, 8 Apr 2006 16:18:58 -0400
>From: Rahul Sinha <[email protected]>
>Subject: One (larger) feature request: .Mac improvements
>To: [email protected]
>
>Hi there,
>
>NetNewsWire (in pre-Newsgator NNW 2.0 releases) could synchronise 
>open tabs via .Mac.  Unlike OW's current bookmark syncing, the 
>feature was not only useful if no two instances were open at the same 
>time.  Rather, you could open an instance of NNW in the morning, go 
>to work, open another there (have all your tabs as you had left them 
>before the commute), do what you would, and when you closed up and 
>got home, your (uptime 10+hrs) NNW would have your tabs as you had 
>left them at the close of business.
>
>OW can improve on this; given its support for workspaces, OW could 
>have live open and close matching across .Mac.  (I've never actually 
>tested how long it takes NNW to reflect changes to another paired 
>instance, other than "less than 20 min")
>
>Whatever system is design to keep OW instances from clobbering each 
>other could productively be used to improve OW bookmarks, which 
>currently suffer from race condition problems.
>
>If I have two instances of OW open, and I add a bookmark in one, and 
>then sync, and then add a different one in the other instance and 
>then sync, one of the two is lost.  This shouldn't happen.
>
>I came up w/ a sort of mock up of how this would happen.  The 
>requirements were:
>1) No concurrency errors or race conditions should be possible (as 
>far as one can prevent them)
>2) One instance of OW should be responsible for folding all the 
>changes together, regardless of how many are running at the time
>3) It should be possible for clients to operate in a .Mac blackout, 
>and fold their changes together harmlessly when sync'ing resumes
>3.1) this should be transparent to the user
>4) This process should allow as much information as possible to be 
>preserved, so that the experience of using one OW instance is 
>identical (as much as one can ensure this) to another.  This includes 
>scroll positions, field contents if a form was left unsubmitted for 
>long enough, etc
>5) This process should be extendible in the future to new features/
>types of data, etc
>
>
>-----
>Directory Structure
>-----
>
>iDisk/Documents/Omniweb 5/...
>as is currently so, the structure doesn't impede the current bookmark 
>syncing process AFAIK
>
>[iD/D/O 5/] .../Linked Accounts/User@Machine/...
>allows for all "primary" files to be kept in machine-account unique 
>locations, prevent race conditions.
>
>Inside each of these per-machine-account directories:
>[iD/D/O 5/L A/U@M/] .../Workspaces/workspacename.Omniweb Workspace a 
>bundle that holds workspace-specific info and prefs, as well as 
>bundles representing the tabs of the workspace
>[iD/D/O 5/L A/U@M/] .../Bookmarks/Personal Bookmarks/...
>[iD/D/O 5/L A/U@M/] .../Bookmarks/Favourites/...
>etc.  .../B holds subdirs that correspond to bookmark top-level 
>folders, inside of which are bookmark-representation bundles
>
>Now, in addition to the /L A/U@M/ hierarchy, iD/D/O 5/ contains
>.../Synchronisation/...
>[iD/D/O 5/S/] [email protected] Submission, which is nothing more 
>than a text file containing a number.  Much the way SAMBA "elects" a 
>domain controller, each active OW instance will keep a .E S file in 
>iD/D/O 5/S/ with a number representing its willingness and 
>suitability to act as primary.  Whichever presents the highest number 
>(or in the unlikely event of a tie, the first timestamp) will go into 
>iD/D/O 5/L A/* and construct:
>[iD/D/O 5/S/] Synchronised Results/... A mimic of a U@M directory 
>structure, using aliases where possible (and new bundles/directories 
>where not) to present the sync'ed results of all the U@M 
>directories.  Once finalised, this directory's contents replaces that 
>of each of the U@Ms (unless they had been altered during the creation 
>of iD/D/O 5/S/S R/*) and the whole apparatus waits until there is a 
>need to merge changes.
>
>Most of the time, a change will involve one new bookmark, one closed 
>tab or somesuch.  In this case the synchronisation shouldn't take any 
>time at all; simply copy that information to each U@M and then have 
>each client's iDisk sync up.
>
>-----
>File Representations
>-----
>
>Tabs and Bookmarked sites use one file format, Omniweb Stored Site (a 
>bundle)
>SomeWebpage.Omniweb Stored Site (or O5S if Apple still recommends .3 
>file extensions)
>[SW.O S S] .../SomeWebpage.webloc (URI as a webloc file)
>[SW.O S S] .../com.Omnigroup.Omniweb 5.Stored Site.SomeWebpage.plist 
>(current scroll position, current tab fills, etc) <-- updated less 
>often, obviously
>[SW.O S S] .../Cookies/... A directory to hold all page/site specific 
>cookies
>[SW.O S S] .../Cache/... A directory where OW can dump page/site 
>cache files, and thus preserve them if desired
>
>Workspaces use a different format (Omniweb Workspace) which is also a 
>bundle
>Workspacename.Omniweb Workspace (or O5W ...)
>[WSN.O W] .../Tabs/... A directory containing Stored Site files for 
>each tab open
>[WSN.O W] .../com.Omnigroup.Omniweb 5.Workspace.Workspacename.plist 
>(workspace-specific info, prefs, etc)
>[WSN.O W] .../Snapshot/ if this workspace is NOT constantly 
>snapshoting to alter its current roster, this directory holds the 
>last snapshot's stored site files.
>
>Let me know what you all think :-)
>
>-RS
>
>------------------------------
>
>Message: 3
>Date: Sat, 8 Apr 2006 14:48:57 -0700
>From: DV Henkel-Wallace <[email protected]>
>Subject: Re: One (larger) feature request: .Mac improvements
>To: Rahul Sinha <[email protected]>
>Cc: Omniweb-L List <[email protected]>
>Message-ID: <[email protected]>
>Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>What I think is that would also be handy via Bonjour...


-- 
J Thompson

[email protected] (permanent)
[email protected] (current)

http://nateandsam.org

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________