?

Log in

No account? Create an account
February 8th, 2002 - LiveJournal Development [entries|archive|friends|userinfo]
LiveJournal Development

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

February 8th, 2002

getevents bug (?) [Feb. 8th, 2002|01:44 am]
LiveJournal Development

lj_dev

[thorshammer]
Hey all,

Quick bug (or something) I noticed.
If I post an entry in Phoenix, and go to edit it via a Desktop Client, the mood shows up. If I post and entry using the Web Client and go to edit it via a Destop Client, no mood.

I checked into it, and found out that the server wasn't sending back the currentmood prop from the web client post, but was for the Phoenix post.

Hope this helps, I'll post the information sent back to me from the server in a lj-cut.
~Chris
Recieved Info from ServerCollapse )
link3 comments|post comment

LJ clusterization - talk* urls [Feb. 8th, 2002|09:26 am]
LiveJournal Development

lj_dev

[badfritz]
hmm, that post, discussing the new style talk* urls for entries in clustered journals, made me think ..

right now, the url of a entry in a clustered journal gets an url like this:

www.livejournal.com/talkread.bml?journal=username&itemid=local_id

while unclustered journals still have the old style urls like that:

www.livejournal.com/talkread.bml?itemid=global_id



a) use numerical id of a journal/user instead of the name ?

journal/user names are not unique over time ..

what if a username is deleted and later reused by a new user ?
or some user decides to pay the fee for renaming their account ?

since the numerical ids of users are unique and dont get recycled, i think they should be used instead to avoid the problems mentioned above.

since comparing integers is faster than comparing strings, the db index tree operations might be a bit faster for integer keys than for string keys. so it might be faster to have only numerical ids for the entries. i dunno how much faster that variant would be, but im sure it wouldnt be slower.

.. some other, far less important ideas ..Collapse )
link5 comments|post comment

Database Questions... [Feb. 8th, 2002|02:47 pm]
LiveJournal Development

lj_dev

[sapphirecat]

Okay, as evan noted, a database-backed system for the client downloads would be ideal. It's also what I was planning, but I've run into a couple of questions.



  1. Do I need to worry about clustering at all? This isn't per-user data.

  2. What names should the tables, IDs, and indices (the globally consistent stuff) have?

  3. Should there be a platform table with a platID and a pretty name for the vanilla index, and another table with all the client data for the by-platform views? Or is the hit rate low enough that trying to optimize the database is a waste of time? (Hell, is splitting a table and running a join on by-platform views even an optimization?)

  4. Addendum: How do I decide limits for the fields? Just pick a random number like 255?

linkpost comment

Admin Console 'help' command, plus little fixes [Feb. 8th, 2002|05:49 pm]
LiveJournal Development

lj_dev

[mart]

This patch primarily adds a 'help' command to the admin console. This is of negligible benefit to people using the web-based interface, of course, and is mostly for those using either the console thingy in LogJam or ljsh, where loading a web browser to view the command reference might be inconvenient or annoying.

I'm not really keen on how I did the wrapping. I'd actually like it better if the admin console returned some kind of basic markup which each interface was free to format in any way desired, but as it is I had no alternative but to do the wrapping server-side as the client has no idea what data it's getting in order to decide whether to wrap it or not, and how to wrap it. I have a better plan for this, which I'll go into shortly. Text::Wrap should probably be loaded outside this subroutine...

It also fixes the spelling of "this" in one of the help texts, and makes the web-based interface to the console escape HTML and BML in the output, since my help command was returning the argsummary with its variables enclosed in pointy brackets thus making them vanish.

My 'better' plan to the wrapping is for an option in the console-calling thing to specify a preferred output width. This can then be wired into the protocol mode so clients can send some number (or in the case of ljsh, send the actual width of the terminal) and have textual output wrapped to that width where possible or relevant. A good default of 80 could be assumed if the client doesn't supply a value. This is more of a workaround than a plan, but never mind.

link8 comments|post comment

navigation
[ viewing | February 8th, 2002 ]
[ go | Previous Day|Next Day ]