"the universe appears lifeless not because complex life is unusual but, rather, because it is always somehow thwarted before it becomes advanced enough to colonize space."
Yeah, if you're looking for it, you can see the phoenix motif all around San Francisco, not just on flags. It's the symbol of the city.. a city risen from its ashes. I quite like it actually, though I agree the actual flag is not the greatest design. He didnt mention it but the gold border is a reference to the gold rush roots of the city, if that wasnt apparent.
I dont think the flag is that hard to find.. it's flying over most government buildings at least. Though I may be inclined to notice these things since I could name the cities for a few of flags on his "bad flag" slide by sight.
Thanks saurik! Yeah that's right, we've tried to make it as easy as we can for developers to use. One of our goals has been to let developers be able to work with data as they do normally if it were just local, while we handle figuring out whats changed.
We provide endpoints for you to monitor all changes across all users - using this you can run a service that could validate each piece of data as it is changed, making updates if necessary, or do things like mirror the entire datastore.
Correct, each object is on a separate timeline for purposes of operational transform. If both clients are connected at the time the changes are made, then it shouldnt be possible to see the second change before the first. We keep an ordered history of all changes to all objects, though for efficiency, if a client that wasn't present when changes were initially made syncs, changes to multiple objects may appear in a different order. For example, a modification to object A, then object B, then object A again, would appear in the correct order for all clients when those changes are made. If a different client then syncs and asks for what's changed, we may group the two changes to object A such that there would appear to be two changes, a change to B then a change to A.
There is currently limited support for keeping a subset of data synchronized (we have plans to improve this) - if you're using the client libraries in an app, we've focused on supporting the common case of keeping all the data per bucket for a user synced. In the case of keeping all data mirrored to a backend, we provide an endpoint per bucket that you can listen to all changes for all users so you can keep the entire data store synchronized.
Ok, with those semantics (and I think I understand the basis implementations that would cause them), do you perform the "resync" step (which has the property that you can at least get the catch-up changes in a single bulk and hopefully fast download for the entire bucket, even with the internal reordering that happened over time) as a single transaction (by locking the persistant store coordinator); and if not, why?
With keeping the objects on separate timelines, do you or can you run into any problems with CoreData inverse relationships? I'd be concerned that my objects would have issues where a change got synced for object A that had it linking to object B, but somehow my application crashed before it got the synchronization for object B sent. I can imagine various reasons why this concern is stupid, including "saurik doesn't understand how CoreData works" (as I only even learned of its existence a couple days ago).
There's currently no explicit lock or transaction, but due to the way we're multithreading, multiple changes are propagated back to your context in one shot.
Core Data relationships (including their inverses) that come over the wire can be lazily resolved by Simperium if necessary.
Yes definitely, you can update directly using the bucket.update() method, and pass in an id and the data object. The better way would be to implement the 'local' callback to return the data, then just call bucket.update(id), and the library will call your 'local' method to retrieve the current state for that id. You can read about the 'local' callback here: https://simperium.com/docs/reference/js/#local
For auth, we'll be adding cross-origin support for https://auth.simperium.com, up till now we've been focused on supporting apps with existing backends which generally use the HTTP API to generate auth tokens from their server.
