?

Log in

No account? Create an account
January 23rd, 2001 - LiveJournal Development — LiveJournal [entries|archive|friends|userinfo]
LiveJournal Development

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

January 23rd, 2001

Wanted: VB Developers [Jan. 23rd, 2001|08:47 am]
LiveJournal Development

lj_dev

[muerte]
If you know anyting about VB and would like to be a part of the Windows MyLJ (LJ-Sync) team post a message here. Currently I'm looking for someone who knows the RTF control pretty well, someone to help me develop a library of functions for the client, someone to help make the GUI look perty, and someone to help with backend technologies.
link9 comments|post comment

E-Mail to LJ [Jan. 23rd, 2001|08:48 am]
LiveJournal Development

lj_dev

[tsutton]
I'm at work and I had this idea... well maybe crazy idea (perhaps good), what about E-mail to LJ feature to update your LJ?

It could be something like this...

From: (my e-mail address, it could check with the server for validation)
To: emailtolj@livejournal.com
Subject: (subject line)

In the message body

Userid: (myuserid)
Password: (pass)
Mood: (mood keyword)
Picture: (picture keyword)
Text: (my text posting)

END:

Once you type in the END: command, LJ stops processing after the end line, because some of the people has a sig. at every outgoing email, which could mess up this.

What do you think? Comments?
link6 comments|post comment

MyLJ: let's get it on [Jan. 23rd, 2001|09:47 am]
LiveJournal Development

lj_dev

[revjim]
Brad has implemented the syncitems mode and the syncitems method for getevents. piman is working on Brad's initial Perl script. (Piman, when you get a chance, would you please post your intentions with that script so we know exactly what you are doing will entail?)

I have the following list of scripting languages (in my head) that SHOULD have MyLJ libraries written for them: PHP, Perl, Miva, ASP/VB, ASP/Active Perl, Cold Fusion, Java, C, and (heh, just for you martmart) mIRCscript.

The libraries should facilitate allowing a remote site to update LiveJournal, all a remote site to browse LiveJournal entries.

They should be written in a modular fashion, with as much abstraction as possible to allow for future changes, uses beyond the original thoughts of the developers, and more flexibility on the part of the users of these libraries.

If you would like to volunteer to write module code for any of the above languages... please comment here.
link9 comments|post comment

bookmarks [Jan. 23rd, 2001|10:05 am]
LiveJournal Development

lj_dev

[revjim]
Think back to before the web... do you remember what a bookmark did then? It... kept your place in your book, so you could pick up reading where you left off.

All of this syncitems talk has caused me to think of a new possible LJ feature.

BOOKMARKS.

Create a special form of the lastn and friends views that displays all journal entries (from oldest to newest) that have been updated since a specific time. Create a table in the database with the following fields:
userid
ownerid
viewtype
timestamp

If a user is logged in, he/she could book mark his/her position. The database would store the bookmark location (in the form of the last updated time of the item being bookmarked). the next time the user viewed that journal in bookmark mode, only the entries posted or updated since the last bookmark was made would be displayed. And, they would be viewed from oldest to newest. This allows users to read when they like, as much as they like, bookmark where they leave off, and come back for more later, never having to worry about missing a post.

To make this work REAL well, user styles should include a bookmark link down by the "Comments?" link or on the talkpost.bml page along side the memories links and whatnot.

Another name, other than bookmarks should be used for this feature as, due to the use of the meaning the word bookmarks has taken on since the birth of the web, users would be confused as to what functionality this feature provided.

Comments, suggestions, discussion?
link3 comments|post comment

another protocol thought.... [Jan. 23rd, 2001|12:29 pm]
LiveJournal Development

lj_dev

[revjim]
syncitems and getevents should allow a "getuser" variable. A username and password are still allowed to be sent. This would allow remote sites to gather data on multiple people (for instance... a group of software developers all use livejournal to keep track of their updates) without requiring the user names and passwords of each of those users. If a username and password are supplied... then standard livejournal security rules fall into effect based on the permission levels of that user in regard to the particular entries/users. However... it should also be accepted to not supply a username and password (as long as the getuser parameter is supplied) which will inform livejournal to only display the entries that are publically viewable.

I hope this makes sense.

Comments?
link4 comments|post comment

(no subject) [Jan. 23rd, 2001|12:58 pm]
LiveJournal Development
lj_dev
[evan]
A preliminary Python interface to the syncitems protocol.

Documentation and source (including a sample program) are available from http://students.washington.edu/eeyem/software/pylj.

Screenshot, of sorts:
$ ./LiveJournal.py
Running demonstration:
Making request as test/test...
First sync'd item: LJSyncItem Type[L] ID[668] Action[create] Time[1999-05-04 17:31:50]


Comments?
link3 comments|post comment

(no subject) [Jan. 23rd, 2001|06:33 pm]
LiveJournal Development

lj_dev

[muerte]
Can I make a request to change the protocol for getevents and syncitems? Can you add an option "returnrecords" or something like that, that lets the client decide how many records to download at a time. You should set it so that it never goes over a max, but it would allow less. You had suggested that 250 be the limit, which seems ok. But if you're on a slow dial up line even that could take quite a while. I'm thinking of employing an option "connect speed" in my client that affects how many items it downloads at a time.

14.4 would be 20
28.8 would be 40
56 would 100

etc...

Is that possible or frivilous?
link3 comments|post comment

navigation
[ viewing | January 23rd, 2001 ]
[ go | Previous Day|Next Day ]