January 20th, 2001


Chat forum?

While this message board is good and dandy, do we have any plans for IRC meetings or somesuch said activity for discussion of certain matters? For cases where this isn't sufficient. Otherwise, it could be a hangout for random development discussion away from the distractions of other channels.

Just a disjointed thought...
hulk, strong, party
  • revjim

Memories and metadata

A little while ago I posted an idea. The ability to categorize entries. Then I got to thinking.

We already have a feature like this: memories.

Why not create pseudo-metadata fields for "memory keywords", "memory description" and "memory security". When the entry is presented to the client, it can extract this data from the memories table and present it to the user as metadata (not very difficult). Then... when the entry is submitted, if that metadata is present, it is then converted back to the memories table.

This will allow people to categorize their own stuff, and still add other people's memories in the conventional way. Then... once the ability to style the memories pages is active... everything will work like I discussed before. Since all of this activity will take place in log.cgi... it shouldn't be too difficult to add.

Brad... if you wanna send me the memories table structure and a copy of log.cgi... I could probably hack it together in no time flat.

Synchronous mail sending

A lot of what's slowing down the processing of BML pages is that postfix's sendmail replacement blocks while it sends mail.

I'm thinking I need to either 1) figure out postfix more, 2) switch to qmail or something, or 3) change my send_mail function to instead of piping to sendmail immediately, write the message to a file or in the database and another process running all the time waiting on mail to send... pausing for like 5 minutes or something if there's nothing to do.

Thoughts? Suggestions?
at the window
  • kvance

(no subject)

Good news, everyone! I am posting this with PalmLJ 1.0.0, and so can you. It's up at palmlj.sourceforge.net.

Yes, this /should/ have happened last week, but last week was like one big week-long naptime.

Anyway, grab a palmos emulator or your wireless modem and try it out!

Boy, will I be embarassed if this message comes out all garbled :)

client roadmap?

Awhile back, I mentioned to Brad that we should start to make sure that our software clients are really distributed a lot more like serious software packages.

In other words, people could go to just about any of the popular download sites on the web, find our software, download it, and without having any prior knowledge of livejournal.com, easily set up their journal. I know there is an ability to do this within the Windows client (and presumably LoserJabber), but we should ideally make it much easier... If the install is a new install, we should do a lot more handholding to get the user set up on LJ, and not force them to discover how to do it themselves.

For the first releases that really enable anyone to create a journal from the client alone, I think we should jump to a version # like 1.5 or 2.0, the reasoning being that this version would be the first version we'd really push. People pay a lot more attention to a major release than to version 1.4.7. I can have volunteers from lj_biz work with the developer to make sure their software is downloadable most everywhere. I will also work with the PR dept. to make sure that we have press releases announcing the new version of the software.

I'm also thinking that we should have right button support, especially for the Windows client, which accounts for about 9/10ths of all our client users.

Take a look at how right button support works in Word, for instance:

Think of how that could be applied to the LJ client. Highlight some words, right-click... and you can make something a hyperlink... or change the font... or the size... or italicize... or strikethrough...etc. If we start to add too many features and get a big run-on list, we could always have subcategories: right click, select text formatting, select bold.

Other features we should shoot for, IMHO:
- Support for img tags. I'm always getting people asking me how to add a picture to their journal. Frankly, it should be supported in the client. We should eventually even allow members to upload their pictures to LJ (or maybe even their own webserver) through this feature. We could also add in subfeatures relating to image size, alignment, etc.
- a "preview in browser" button. This would save a temporary file of the person's post as an html document on the user's HD and then open the file with their default browser.

So, any thoughts on all this, or on other features we can add?
at the window
  • kvance

PalmLJ Test Message

Hello. I'm writing this on my actual Palm Vx (on cradle), logged in as kvance, posting to lj_dev. If you can see this, then PalmLJ 1.0.0 is almost done. Hooray! :)
  • Current Mood
    crossing fingers...
  • tmtl

(no subject)

On the subject of attracting more users. If this is something that still wants to be done, how about some LiveJournal-FreeVote integration of some form?

Make users of one resource aware of the other

Project Teams

Mark and I were talking about how to get work effectively and we both agreed that large groups move too slow and don't come to concensus quick enough. We both agreed that we should start breaking ourselves into "teams" like the lj_biz people have done.

However, being part of one "team" doesn't mean you can't provide feedback on the other team's work, it just means you're focused on one project primarily.

The two teams I'd like to form in the next few days are as follows:

S2 - New Style System
I'm going to head up this project. The current style system just sucks. I've been working on specs for a new system that has a custom and simple programming language at its core. The language won't allow infinite loops by not having gotos, whiles, etc... The only control flow structures will be if/else statements and foreach over finite lists. If somebody feels like it, they can write a style in this language.... I'm calling this for now a style engine. However, most style engines (at least the ones we provide) will read in variables definitions that a user has defined. We'll likely provide two engines to begin with... a compatibility engine (written in the new S2 language) to run old styles (things with LASTN_PAGE, etc...), and the new default engine, which will take advantage of everything S2 will do: localization and color schemes specific to styles. (and styles are specific to engines...) In the new system it'll be trivial to add new views, without any work of the engine or style maintainers... only if they want something a lot different will they have to modify things. Even people that don't want to make their own style can go through a customization wizard and answer questions like, "What do you want your 'post a comment' link to say?". I intend to write the language parser and compiler in Java. The "compiler" will simply be turning the AST from the parser and compiling it to, intially, perl code that will run inside the server.... if we change what language the middleware runs later, we can just change the compiler backend to generate Python or C++ instead of Perl.

MyLJ - personal LiveJournal server/sync/backup system
I need a leader for this project, else I'll do it after the S2 project is over. However, I'd prefer to work in parallel, as these two projects don't depend on each other. I want a team to come up with some new protocol modes to let a remote non-interactive client download a user's journal to their local machine, with different backends for storing the data in text files, or in a database. Then, I want a group of people within that team to make different ways to manipulate that data: PHP interfaces, HTML generators (later we could use the S2 system on their local machine), etc...

Both projects will be licensed under the LGPL.

So, who wants to join what projects?
  • muerte

(no subject)

I'd like to get working on the protocol to download someone's entire journal. I'm open to suggestions as to how we would do this, but I'm thinking a simple CSV file would be fine. That would allow client editing/viewing to occur. Should be relatively easy to write. I'm planning on writing an Access frontend that will allow easy searching through your journal. Unless of course there are licensing issues, in which case I can write it in VB and distribute it freely.
  • muerte

(no subject)

I have 5 episodes of Dragonball Z I taped that I was going to watch tonight, but I only got through 2 of them because I kept coming up with some great ideas for this client storage of your LiveJournal. I'm going to work on some prototypes of the client and see if I can get it to download html into a string and then I'll develop a shell of a protocol and let Brad implement.
  • muerte

(no subject)

Here is my proposal for a simple protocal. I like the idea of having the server be dumb and simply export the entries that I tell to it and nothing more. Doing a CSV like dump would be a simple way to get the data to the user. I'm thinking something like a modified export.bml

How about:

# = comment (duh)
<entry></entry> = signify an entry, this would be necessary to facilitate multi line entries
<eof> = for the last line

The first line could contain the "header" with what columns were exported in a comment. That's the way I'm envisioning the data. I think Brad has some different ideas however. Elaborate on what you're thinking about Brad and I'll try and adapt.