?

Log in

No account? Create an account
May 2nd, 2002 - LiveJournal Development — LiveJournal [entries|archive|friends|userinfo]
LiveJournal Development

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

May 2nd, 2002

ver=X [May. 2nd, 2002|01:18 pm]
LiveJournal Development

lj_dev

[cryo]
There -needs- to be a capabilities result returned at login.

The capabilities needs to tell the clients what protocols it can understand.

I don't want to have to try to make the user specify which version to use for whichever server they are currently using, because they have no idea if deadjournal or whatever has upgraded to whatever capabilities.

This can be a 32bit value that specifies version and other abilities or protocol changes.
This should probably also house lj_fastserver as a capability, since it's lj.com specific, more as a cleanliness issue.
link3 comments|post comment

Journal-wide Security Setting [May. 2nd, 2002|09:15 pm]
LiveJournal Development

lj_dev

[mart]

Lots of users want an option to convert all old entries with x security level to y security level, and this has been discussed lots of times before. I propose the following interim solution...

All accounts should have a "base security" setting. This setting allows choice between private, public and friends-only (not custom security, for simplicity's sake) and would for the most part be a simple matter of adding a check at the start of the journal view generator which refuses to output anything if the journal it relates to has a security setting which the remote user doesn't have access to. In addition to this, talkread and talkpost would need an additional check, and the friends view can simply read in the relevant userprop of all friends before starting and decide if each user's entries will be displayed or not and store it in a hash or some similar structure.

This security setting is more severe than standard security since it applies to the journal as a whole rather than to individual entries. It also does not change entry-specific security, so a post that was posted as public in a private journal will become public if that private journal is made public. This would have to be made clear in the place where this option is given.

Possible caveat put forward by ccupguy: Should community admins be able to set base security on communities which would thereby affect all posts to that community?

So... uuh... discuss, I guess.

Originally accidentally posted in my personal journal. It got three responses while there, all "yaying" the concept, with a reference to foreach_entry (which still hasn't been implemented after all this time) (mtffm) and a benefit that a journal could temporarily be made wholly friends-only while the user manually tweaks older entries en-masse before putting it back to public again. (jarel)
link14 comments|post comment

navigation
[ viewing | May 2nd, 2002 ]
[ go | Previous Day|Next Day ]