January 31st, 2001

And how!

Web-based checkfriends

Needed something to keep me awake during the day at work, so I made this (plain text download) PHP-based checkfriends script. Kind of useless.. but I ended up going overboard and making a LJ protocol handler of sorts.. Take a look if you like, it seems to work okay. It's a bit ugly, though.

I even added comments.. Ooo, ahhhh..

Edit/Create Style Pages

Hi. Let me quickly introduce myself since I'm a new member and that. I'm Scott Freeman and I like to think I'm pretty good with creating LiveJournal Styles that people can use on their Journals. I have created the "Tabular Indent" style, and have a few more up my sleeve.

Anyway, I have got an idea for the edit/create style pages.

I have developed a whole load of styles (about 4 so far), a few one-page-only styles, and have another one on the go. That is 19 items in total, and the dialogue list only shows 10 at a time, and messily so.

My idea is to have four dialogue lists side-by-side (or in a 2x2 formation?), each one showing just last_n, day, calendar and friend views. That way, all the last_n pages will be grouped, making it easier to select and edit styles.

Also, I wonder if it's possible to alter the size of the text boxes on the fly? That is, the user can choose a combo box option before clicking on the "proceed" button to decide if the boxes will be small, medium, large or king-size. Some projects I am working on are very simple and will only need small boxes, but others need large (or king-size).

Could the %%userpic%% for the last_n also represent the current picture for that %%event%%, as the friends page already does? Also, there doesn't seem to be a %%userpic%% on the friends, day and calendar pages, so you can't put the owners default picture at the top of the page as you can on last_n.

Also, there's no link to "create style" on the sidebar, one has to go to "edit style", and follow the link from there. Just a minor whinge that isn't too important.
  • Current Mood
    okay okay
  • fubarpa

Style system idea

I'm sitting here and a thought came across my mind. I know that for the most part the current style system is based on HTML and BML. I don't find the current interface very good. I've tried editing styles in UltraEdit32 ( a text editor ) and then doing a cut / paste from the editor into the style system. What would really be cool is if there would be a way to edit the style completely within a client, and then upload it using this client. You could also include some form of a test / preview option so people can see how the style will look before they go and upload it to the server.

Like I said, I'm not sure what direction the new style is going, but I'd thought I would throw this out there as an idea.

Fuck sourceforge!

Sourceforge can kiss my ass:
"When all the code that you want to host on SourceForge is Open Source, you are welcome to reapply."

I didn't say a damn thing about them hosting non-open code. I said we we're in the process of opening up a bunch of our code.

Somebody should take down those fucker's site.... their code is so bad. Ever download the sourceforge code and look at it? I only looked at a few parts, and found a number of security holes.

piman --- you want to reapply? Don't mention anything about non-open code at all .... say the project is for livejournal clients and libraries, clients under the GPL and libraries under the LGPL. Mention anything else about future plans and they'll get confused because they're dumb and deny the project.

Even if we do run our own CVS, it'd be nice to have 'livejournal' reserved on sourceforge for the future, or as a mirror site to release binaries.

What I'm working on....

Here are the current things I'm working on:

BML profiling, rewrite, cleanup --- I've been doing a bunch of profiling on BML and found some really slow parts. This was basically my first Perl project and its core hasn't been touched in years. I've kept adding crap onto it, but the parser sucks. I'm rewriting it now ... simple project, but necessary. In the process I'm documenting everything, then I'll make an official release. (Whitaker--- don't wet yourself)

ProFTPd + MySQL Auth --- setting up ProFTPd so people can upload clients and stuff to certain areas without having user accounts on the server. (anything that prevents me having to do stuff for people is good .... I hate getting email)

Test Server --- finishing setting up my test server. I have everything on there, but I have to get it all running and playing nice together.

Then, once all that's done, I intend to work on the new style system. I've been working on ideas lately, but no code's been written. :-/

I'm getting sick of people mailing me with large fluffy future project ideas with no implementation plan whatsoever.

Does somebody want to work on the ProFTPd thing for me? I've been tinkering with it, and it looks easy enough, but I haven't written the .conf file yet that uses MySQL..... Here's what I need, if anybody wants to do it for me:
  • ./configure line that includes building the MySQL PAM modules
  • the CREATE TABLE code, with one insert statement for a sample user
  • the .conf file with the following properties:
    • each user is in a chroot jail at /usr/devftp/username
    • standalone server (no inetd)
    • no real users can log in (only authenticate against MySQL table .... say, "devftp")
  • piman

CVS, central storage, etc

Okay, LJ used to just be 3 or 4 clients. But since the new protocol stuff, more operating systems supported, more platforms supported, etc. (I see new 9 projects on the lastn page here with ideas for a lot more), is it time to get a central place for development? I personally like the idea of having a "LiveJournal CVS server", with all the clients, protocol documentation, and released server code. Likewise, I see client web pages spread across a lot of different servers, and as more code is released, this will get even more complicated to maintain.

So does the idea of a "LiveJournal Code" page and CVS server appeal to anyone else? Could LJ run this itself (on the new server, maybe), or would it be better done by someone else? (SourceForge being the obvious place, since I bet a lot of people here already have SF accounts). It might also be a little bit more publicity if we have a single point of development.
  • piman

The new sourceforge project description [submitting now]

A central point for development of LiveJournal clients, server code, and utilities, released under the GPL and LGPL. LiveJournal is an online journaling service at http://www.livejournal.com. Several free clients are available for many platforms, and the protocol to create clients is also open.

This project was turned down a short while ago due to a misunderstanding. Only the existing free code will be part of the SourceForge project, and that free code does form several complete programs. What little proprietary development exists will be done elsewhere.

UPDATE: They turned down the account and still created the project, so the name is taken!

Permission Denied
This project's administrator will have to grant you permission to view this page.
  • piman

(no subject)

Okay... I have just sent a rather... pointed.. email to the person listed as the director of sourceforge. The kind of email that should get us a very quick, if not polite, reply, and an equally quick resolution to the situation.

BML Profiling

I rewrote the BML parser ... so much better now: smaller, cleaner, understandable, and commented!

Here are my profile runs:

Old -- what I started with. Profiling the expansion of 14 pretty large BML pages. Note that bml_block is at 50% ... ouch. This made me suspect my parser was bad, but bml_block is a pretty light function. Still ... what hurts is that 15% for do_line.

After, 1 -- with the new parser. little better. do_line is totally gone now... deleted that function. the parser is more iterative now than it was before. but why is bml_block still so high? oh, damnit --- i have an eval call in there for _CODE blocks.

After, 2 -- moved the eval inside a new function, eval_code, which bml_block calls. now you can see it's really the eval that's slow (which makes sense --- that's perl parsing the perl in the BML)

I'm not done yet, but I gotta go for a bit. I'll continue to post results as the night goes on. There's a lot of obvious stuff to fix still, but I really wanted to rewrite the parser first, since it was so ugly.