Log in

No account? Create an account
LiveJournal Development [entries|archive|friends|userinfo]
LiveJournal Development

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

May 27th, 2001

Livejournal test server problem [May. 27th, 2001|03:34 am]
LiveJournal Development


I have been trying to set up a LJ test server on http://www.antispin.net so I can play with it. But I have run into a problem that I can't seem to figure out. I can create users and can move around the site without problem, but I can't post to any journals. I get the following error:

* Database error: no itemid could be generated.
Read more...Collapse )
link8 comments|post comment

HTML in strings [May. 27th, 2001|06:15 am]
LiveJournal Development


Update: Changed some wording, added trailing clarification.

This is a point of style, but IMHO HTML tags should rarely be in strings in source code. Instead, it's usually preferable to use functions or object methods to generate tag pairs. This is because

  • It eliminates potential errors in quoting
  • It eliminates potential errors failing to close tags
  • It makes more of the program subject to compile-time verification
  • It allows for easier use of non-interpolatable values in the generated HTML
  • It makes use of whitespace and indentation for readability more convenient
  • It takes advantage of syntax support (highlighting and indentation) in the editor
For example, I believe that

could be better written as

Note that nothing has to be quoted, the computation of $span can be replaced with the result of a sensible function call (which could not be interpolated in a string), the editor can easily indent and highlight the code for readability, and any error in closing tags that the editor didn't pick up would be detected at compile-time. The constant references to $xg, an XML::Generator object, are somewhat unsightly; they could be eliminated, but at the expense of cluttering the LJ namespace with functions with names like "a" and "b". (I've erred on the side of caution here.)

Clarification: I'm not trying to declare that anyone else needs to do this. However, it's a nonobvious technique which has, for me, significantly reduced debugging time and improved my ability to read and maintain existing code, after a very short learning curve. I would recommend it to others, and unless Brad screams bloody murder, I'll be using it in my modifications to the LJ server code.

link10 comments|post comment

Perl dependencies [May. 27th, 2001|06:44 am]
LiveJournal Development


In the cases of simple GPL'd modules, should we consider including the module in the distribution rather than requiring the user to install the module? This would reduce potential for version skew. It would also reduce difficulty of installation. I see no disadvantages other than trivial increase in disk requirements.

For example, in the case of XML::Generator, version 0.90 is a single file that just needs to be copied into the appropriate location. Version 0.91 works fine, but fails "make test" out of the box (I think it has an undeclared dependency on XML::DOM) and thus won't install using CPAN.pm. Also, extremely early versions of XML::Generator were distributed bundled with other XML tools, and could cause library-path problems. It'd be much simpler if we just stuck Generator.pm in an appropriate directory and required it using an absolute path.

That's an extreme case, but any module we rely on is a potential source of trouble if a later version breaks back-compatibility in some way, or breaks the installer. Might as well dodge it when possible. (When possible == when it doesn't need to be compiled, when it's a relatively small number of files, etc.)

Candidates for such inclusion: Time::DaysInMonth, XML::Generator, Class::Singleton, MIME::Lite, Image::Size, HTML::Tagset, maybe GD::Text and GD::Graph.
link3 comments|post comment

Userinfo patch [May. 27th, 2001|07:59 am]
LiveJournal Development


Changes to userinfo:
  • All friends/communities which are friends of the logged-in user are boldfaced, as with interests. (See several posts in suggestions.)
  • Friends and communities are separated into mutual/friend-only/friendof-only categories, with alt-tagged icons indicating which is which. See previous lj_dev post and tribelessnomad's comment in particular.
  • The list of who can post to a community, or which communities a user can post to, has been made more space-efficient and is available even outside of full mode. The obsolete "Shared Journal Access" terminology has been replaced with "Posting Access".
  • A bug which caused the "add as friend" icon to appear even when no one is logged in, or when the user is already a friend of the logged-in user, has been fixed.
  • The code now relies on XML::Generator and Class::Singleton, and a singleton Generator object is available throughout the code. The two packages (one file each) are currently included in the distribution but can be removed and left for separate installation if desired. See my previous two posts.
  • The code also relies on three arrow icons; evan offered to redraw them and make them prettier, but they're okay as is.
Everything is in subdirectories of http://pobox.com/~jaffray/lj/20010512/userinfo/; the big changes are in htdocs/userinfo.bml.diff.
linkpost comment

Adding group mask to checkfriends protocol mode [May. 27th, 2001|09:11 am]
LiveJournal Development


I wrote a quick patch to the protocol to add support for a group mask to the checkfriends protocol mode.

Why? Because while it's nice that my LJ client tray icon can turn a different color when there are new friends posts, it'd be much nicer if it could react differently to different friends posting. When any of my friends post, it could change from black to red; when any of my close personal friends post, it could start blinking red; when my girlfriend posts, it could pop up a window. Different responses to different events.

The mask doesn't make the query any more intense on the server. Nor does it increase the frequency of client polling, as long as it takes a hierarchical approach to masking. (Gradually more restrictive masks for gradually more important events.) The only drawback is the the client might poll for a longer period of time, but that's a minor issue; clients can implement polite behavior, or be required to behave politely.

Anyway, I'd like to see this added to the server, and maybe eventually the clients can add features that take advantage of it.
link13 comments|post comment

s2 ? [May. 27th, 2001|01:23 pm]
LiveJournal Development


[music |Enya - Caribbean Blue]

Is there a journal for S2-type stuff ? in support and other places i keep coming across people who want to do more with styles, and have ideas about it - i dont want to direct them to suggestions...

or is it just an internal project ?
link6 comments|post comment

sourceforge or not? [May. 27th, 2001|01:27 pm]
LiveJournal Development


I want to get everything into CVS soon. Evan was going to help me set it up yesterday but didn't come over.

I have user "livej" registered on sourceforge, but I'd really prefer "livejournal", which seems to be in use from the last time we tried to register and they denied us.

So .... do I set it up myself or use "livej" on sourceforge?

Can anybody bug sourceforge and get them to give us livejournal?
link8 comments|post comment

CVS progress [May. 27th, 2001|05:43 pm]
LiveJournal Development


Evan and I setup CVS ... not on sourceforge.
Things aren't imported yet... I'll explain why in a second.

The following modules will exist:

livejournal -- the server code necessary to run your own LJ server.
ljcom -- BML pages and maintenance scripts that are specific to livejournal.com. these can reference and depend on files in "livejournal", but not vice-versa.
textmessage -- LJ::TextMessage
spellcheck -- LJ::SpellCheck
doc -- documentation tree (XML and makefiles needed to crank out real documentation)

The reason things aren't imported yet is because I haven't separated livejournal files from ljcom files. That'll take awhile... I'm going to document the code as I do it, putting in comments that a script can parse out and make pretty graphviz pictures out of.

I'll post more info later when things are setup and ready to be checked out.
link5 comments|post comment

[ viewing | May 27th, 2001 ]
[ go | Previous Day|Next Day ]