lp:~urbanape/bindwood/work-with-folders

Branch merges

Propose for merging

No branches dependent on this one.

Merged into lp:bindwood

Tim Cole (community): Approve on 2009-09-22

Mark G. Saye (community): Approve on 2009-09-22

Diff: None lines api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

32. By Zachery Bir on 2009-09-22

s/itemId/aItemId/ and take an anti-stupid pill for next time

31. By Zachery Bir on 2009-09-18

Create per-profile views with just that profile's bookmarks, and rename the default two

30. By Zachery Bir on 2009-09-18

Merged handle-all-profiles

29. By Zachery Bir on 2009-09-16

Merged in handle-all-profiles

28. By Zachery Bir on 2009-09-16

Descend into subfolders of the three main bookmark folders:
toolbarFolder, bookmarksMenuFolder, and unfiledBookmarksFolder. This
ensures that all bookmarks are synced, not just immediate childred of
these three folders.

We do not yet make any attempt to preserve order or hierarchy with
secondary clients. That's in scope for a future branch.

27. By Zachery Bir on 2009-09-16

Seed each bookmark with the name of the current profile, and use the current profile as a filter when pulling bookmarks.

26. By Zachery Bir on 2009-09-16

Provide a means for creating new design views in a data-driven
fashion, and ensure that views in code always take precedence.

Provide a new design view for deleted objects, and filter deleted
objects from the main view.

25. By Zachery Bir on 2009-09-15

Belt and suspenders when dealing with onItemAdded.

24. By Zachery Bir on 2009-09-15

Small changes to clarify, and add back in some debugging

Mostly, I've made all references to bookmarks "list" -> "folder", for
consistency's sake.

I had a few places where I was still referring to a (now, absent)
Bindwood.pushSettings object. Now, I just use the strings "ENABLED"
and "DISABLED".

Only perform the onItemChanged for regular attributes, not for
annotations.

Make all makeLocalChangeOnly calls explicitly return, in case we need
to assign the results.

23. By Zachery Bir on 2009-09-15

SUMMARY: reorganization and reimplementation to support complete
syncing of bookmarks, and prevent unnecessary network traffic.

This branch fixes bugs #404193, #408282, #406839, and #396186.

Bindwood was not initially implemented to be re-entrant. When we were
first annotating newly created bookmarks in preparation for storage in
CouchDB, the act of annotation caused a change notification, which
then went through and performed additional network checks. Similarly,
when pulling records from CoucDB, if any local modifications were
necessary, those changes would prompt notifications which would turn
around and propagate those changes back over the network, where they
originated.

Now Bindwood operates in one of two modes when it comes to propagating
changes over the network. Only when absolutely necessary, do we save
documents back to Couch. In cases where only a local change is
warranted, we set a flag to avoid network traffic.

Previously, Bindwood operated on the assumption that all methods for
adding a bookmark were like "New Bookmark", i.e., prompting an
onItemAdded event for the initial bookmark, and onItemChanged events
for each subsequent property that is changed. When adding a bookmark
via "Bookmark this Page", however, at least the title and URI are
provided in the onItemAdded event. This information was lost, as we
expected to send it via the subsequent change event. Now, when
onItemAdded is called, we try to glean as much information about the
bookmark as possible (at least title and URI).

Bindwood never made any attempts to keep syncing behavior constrained
to the current profile. This could lead to all profiles' bookmarks
being effectively replicated across all profiles. Now, Bindwood
restricts itself to operating only on the "default" profile. When
launched under a different profile with Bindwood installed, we log an
error message and do nothing. There is room in the future to support
syncing profiles, so long as the profiles are named the same across
machines.