foxfirefey: A fox colored like flame over an ornately framed globe (Default)
[personal profile] foxfirefey
After some further refinements by [staff profile] mark, edge patches have been committed! That means they're going out in the next code push! Exciting!

You can see the format here (I recommend JSONView) for viewing):

http://www.dev.memewidth.org/data/edges?user=amy

Names have been replaced with userids, which are then defined with username/type in a different struct.
foxfirefey: A fox colored like flame over an ornately framed globe (Default)
[personal profile] foxfirefey
Now that fdata.bml is in JSON, would it be expedient to make interests.bml into JSON?

Pros: would be easier for Javascript mashups to load, is a standard format for parsing
Cons: would break compatibility with older LJ-based tools, would take up a bit more space than the current file.
foxfirefey: A series of interconnected dots in the shape of an M. (memewidth)
[personal profile] foxfirefey
So far Dreamwidth has been sorely lacking an equivalent to LJ's fdata, the data file that told you the relationships of a user with other users. Our new equivalent to that will be called edges. Because of the new complexity of DW's relationship structure, and due to a desire to use more standards, this data file will be in the JSON format. The bug for it is Bug 857.

I currently have my proposed patch in. It's not committed yet, or live on the site, but I think it probably will be within the next month. If you want a chance to prepare, I have my patch applied on my development server. It's possible that details will change with feedback, though, so be forewarned! My server has open registration, so you can feel free to create accounts and play around, but I've made a small set of test accounts such as this one. You can view an example edge data file here:

http://www.dev.memewidth.org/data/edges?account=amy

Here is an example of a community's edges file:

http://www.dev.memewidth.org/data/edges?account=bonny_bunnies

The data is in one big hash. There is an "account_type" variable, set to the type of the account. That makes it easy to determine what kind of account you are fetching data for. The other base variables are relationship types, such as "watched", "watched_by", or "member_of", that are a hash of arrays--all the accounts with a given relationship are split up into account types.

Any commentary on this planned data file? Problems you want to fix now, before it's implemented? Any plans for it you want to share?

April 2011

S M T W T F S
     12
3456789
10111213 141516
17181920212223
24252627282930

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags