FormNoticeXHR now is triggered on any form labeled with class 'ajax-notice', so those other than the traditional notice form should work as long as they handle the AJAX submission and return a properly formatted notice.
Things to watch out for:
* to determine whether the resulting notice should show on the current timeline, the JS code needs to be able to check the author and such. Keeping the existing vcard bits helps for this!
* the notice form submission stuff clears out inputs from your form -- test to make sure this behaves correctly
* error messages returned from the thingy _should_ come through, but this needs more testing for consistency
* while form components that aren't in a custom form should just be ignored, this should be tested more. (eg there's no location or attachment box for poll or bookmark plugins)
* NoticeListItem isn't currently reachable via autoloader -- touch NoticeList explicitly before calling into it for now.
I was trying to generate URIs for Bookmarks based on (profile, crc32(url), created).
I failed at that. CRC32s are unsigned ints, and our schema code didn't like that.
On top of that, my code to encode and restore created timestamps was problematic.
So, I switched back to using a meaningless unique ID for Bookmarks.
One way to do this would be to use an auto-incrementing integer ID. However, we've been
kind of crabbed out a few times for exposing auto-incrementing integer IDs as URIs, so
I thought maybe using a random UUID would be a better way to do it.
So, this patch sets random UUIDs for URIs of bookmarks.
Had some problems with PuSH and Salmon use of Bookmarks; they were
being required to generate Atom versions of the bookmark _before_ the bookmark was saved.
So, I reversed the order of how things are saved, and associate notices and bookmarks
by URI rather than notice_id.
Form for saving bookmarks that looks like the delicious.com form.
Save a new notice with the right text, but attach a new notice_bookmark
table which marks this as a bookmark. Tags, URLs are kept the same.
