We're planning to get Atom-based full-timelime export/import going soon,
which will make it much easier to pick up an existing account and move
it to another server with your old posting history intact.
Related to this, we want to clean up how we deal with sorting of notices
on timeline views so it's consistent, efficient, and doesn't do weird
things when you suddenly import a couple thousand old messages from
another server!
Currently most of our timeline sorting is done based on notice id
number, which increases as new notices come into the system. ID numbers
are nice for this because they're uniquely ordered within the system (no
two notices have the same ID, so there's never any confusion). But
imported notices will have "old" timestamps with "new" ID numbers...
I think I've worked out how to make human-friendly time-based sorting
work efficiently in the database while remaining compatible with how
client apps using the Twitter-compatible API expect to use the
'since_id' and 'max_id' parameters.
In most cases this should work 'naturally' for new messages, while
allowing older messages to still be accessed:
http://status.net/wiki/Sorting_changes
By all means give me feedback if something stands out and looks
horribly, horribly wrong before we go doing this. :D
-- brion vibber (brion @ status.net)
_______________________________________________
StatusNet-dev mailing list
StatusNet-dev@lists.status.net
http://lists.status.net/mailman/listinfo/statusnet-dev
