XML-RPC log time

[murklins]

A few days ago I asked some XML-RPC questions, one of which was about how to obtain the entry log time (the server-based creation time) through the protocol. It turns out there isn't a way!

The getevent call returns the eventtime parameter, which is the poster-specified datetime, not the log time. The syncitems call returns a list of all the items that have been created or updated for a user, along with the server time -- but once an item has been updated, it only returns the update time, and the create time cannot be obtained.

pauamma thought there would be value in returning the log time and the update time separately, and I agree, but suggested we get some opinions on that change here. So: thoughts?

Comments

[afuna]

Hm, I like the sound of that. I don't know the reasoning behind the original behavior, but while I can see the time of last edit being useful for RSS feeds, I don't think it's as useful for the protocol in general.

So, um, yeah, I think it would be useful to have the date that the entry was created.

Morning Rambling

[murklins]

Yeah, see I don't really know how other people are using the protocol, but I guess it could be implemented in a backward compatible way just by adding a "createtime" param in addition to the "time" param. This would make the response more bulky, but would still allow clients to display the update time, since I suppose they could be using the call's time param that way. Also, pretty much every client application that relies on syncitems saves the most recent time param returned by syncitems and uses it in their next syncitems call, so the update time is definitely necessary to the protocol just to keep that working.

As I've meditated on this in my past few days of minimal internet connectivity, I've become unconvinced that the syncitems call is the best place for the log time, though, because syncitems is specifically for figuring out what things are different since the last time syncitems was called, and the create time of an entry doesn't really figure into that functionality. Adding the log time to the response there doesn't make sense to me, but maybe I don't have good instincts -- I naturally expected it to be in the getevents response, where it definitely is not.

A slightly-related curiosity: LJ's response currently includes a (not documented?) param that DW's does not seem to, timestamp, and I thought that might be what I was looking for (if I were migrating things from LJ, which I am not), but then it turned out that is just a timestamp-style version of the eventtime param, so not useful in any way, which would explain why DW cut it from the protocol.

Re: Morning Rambling

[afuna]

We haven't cut anything from the protocol *g* but I bet that LJ added it after we forked from them or something.

I'll let this sit a short while longer, and if no one objects, I'll do some poking to see if it's okay to have this in the protocol (:D)

Re: Morning Rambling

[afuna]

Talked to mark, and he says that adding logtime to getevents is fine!

(Filing the bug as we speak)

[murklins]

Addendum to the slightly-related curiosity paragraph: When I talk about LJ's timestamp param, I am talking about its getevents call, not syncitems.

[afuna]

http://bugs.dwscoalition.org/show_bug.cgi?id=2673

(And if no one grabs it soon, I'll take it *g*)

[murklins]

Yay! I hope it proves useful to people, like it would have been useful to me when I was migrating scans_daily to Delicious. :D

[afuna]

Ehehe, I guess we're a bit late? How did you manage without it anyway?

[murklins]

Nah, I never expected to wait on a DW code change, scans_daily was coming up on their 5000 tag limit just way too quickly. Getting the posts in with the correct time was less important than just getting them in there at all, so I used the user-specified time info, even though it makes them slightly out of order.

[afuna]

Hee, gotcha. I hope that this does help the next person who needs it then!