Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
mozilla-labs-weave
Home
About this group
Join this group
Message from discussion How about data format versioning per engine?
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Daniel Mills  
View profile  
 More options May 20 2009, 4:56 pm
From: Daniel Mills <thun...@mozilla.com>
Date: Wed, 20 May 2009 13:56:14 -0700
Local: Wed, May 20 2009 4:56 pm
Subject: Re: How about data format versioning per engine?
Print | View thread | Show original | Report this message | Find messages by this author
On May 16, 2009, at 8:12 AM, Wladimir Palant wrote:

> but only if all data comes from the Weave extension itself. As soon as
> other extensions start registering their engines there will be
> trouble.

I don't think this is quite correct--if an extension adds a sync  
engine, Weave would ask that engine to re-sync at the same time that  
it asks other built-in engines to resync.  So it really is no different.

The problem is if Weave gets used to put data on the server that is  
not for synchronization (it's data that lives only on the server).  
Then a server wipe would be very bad.  Currently we don't have any  
data like that, but we may in the future.

Versioning specific engine data does make sense anyway, for cases when  
a specific engine's data changes but the overall server data format is  
the same.  I wonder how to best implement that though.  Maybe just an  
extra metadata record somewhere?

There is other metadata we need to upload per-engine, currently we  
sync keys with set names ('keys/pubkey' for example), but I think we  
should use a guid and save a record pointing to where the pubkey/
privkey, etc are.  That way if you ever delete the key it would be  
obvious when data was encrypted with a non-existant key.  We could put  
this metadata in the same place as the above version.

Dan


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google