?

Log in

No account? Create an account
An idea for a client - LiveJournal Client Discussions [entries|archive|friends|userinfo]
LiveJournal Client Discussions

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

An idea for a client [Oct. 30th, 2002|01:31 am]
LiveJournal Client Discussions

lj_clients

[deslea]
I have an idea for a client. I'm not a programmer (at least not an applications programmer, anyway) but I thought it may be something relatively easy to create just by tweaking a few things on one of the existing clients.

It all started with this support request. I know quite a few users in this situation - users with friends and family (and especially parents, grandparents, etc) whom they would like to be able to view their entries, but those people are just not net-savvy enough to find their way around their own accounts.

What would be wonderful would be if we could create a client that would display a particular user's entries, but with no capacity to edit them or to post. I know we can't summon friends' entries, but we could get them by having the application log in as the user.

But that's a security risk, right? Well, maybe not. What if there was some way the user could generate a password for this viewing client, derived from the real password and passed through an algorithm? And then it goes back through the algorithm before reaching LiveJournal? That way, the family member, or whatever, gets a password that works with the client, but without compromising the security of the account in any way not allowed by the client (ie, it doesn't let them log in at the site).

I think the biggest logistical problem for something like this would be that of working out how to limit access to entries - that is, something like this would probably want to include friends entries, but not private entries. Is there any way of working around that? Or would the user just have to accommodate that in their posting habits as a trade-off?

I know there are problems with this, but I think there is a certain range of users that could benefit. Do you think it's feasible? And, is anyone sticking up their hand to do it? It seems to me (in my non-programming opinion) that it could probably be done by adapting Visions Semagic, for instance, just by removing the posting/editing/etc options from the menu, changing the window size, and adding the algorithm. What do you think?

Deslea
linkReply

Comments:
From: marnanel
2002-10-29 07:18 am (UTC)
Wouldn't this be better done by adapting the web interface? After all, everyone has a browser; not everyone is savvy enough to install new software.
(Reply) (Thread)
[User Picture]From: deslea
2002-10-29 07:35 am (UTC)
Well, my thought for this specific request was just to set the scheme to Lynx. Unfortunately setscheme doesn't work anymore, and usescheme is limited (when you enter login options, it goes back to dystopia). I probably wouldn't have even suggested it, actually, if setscheme was still an option.

I know if it were my grandmother, I'd just set up the program for her with a shortcut on the desktop and let her just point and click. She'd do that. But she would find the whole browser interface - opening, entering a URL, working out which login options, etc all too daunting. Yes, everyone has a browser. But not everyone knows how to use them.

Like I said, I know we're talking about a quite limited range of users. But in some ways those are the users most in need - the ones with family all over the world, trying to keep in touch, etc. I just thought it was worth putting out there.
(Reply) (Parent) (Thread)
[User Picture]From: kimera
2002-10-29 08:08 am (UTC)

RSS

Wouldn't an RSS/XML feed work? The desktop application could pull the feed, and just like the LJ page the feed would be defined by a query and cookies. I thought someone mentioned RSS a while back.
(Reply) (Thread)
[User Picture]From: deslea
2002-10-29 08:13 am (UTC)

Re: RSS

I was under the impression that the RSS feed couldn't deal with cookies for friends-only posts, but if there's a way of doing it with cookies, I'd be all for that.
(Reply) (Parent) (Thread)
[User Picture]From: kimera
2002-10-29 08:28 am (UTC)

Re: RSS

I've never looked at the LJ code, but it seems to be driven by two things:

1) cookie based conditions
2) queries

If you could write a page/script to check to see if you're logged in before generating the RSS feed, then I would think it wouldn't be much different than the friends page -- that's just a query.

---

Some different than the RSS feed...

I don't have Apache currently installed on my personal server (damned rootkits) or I would hack out what I have in mind, but it sounds like that support problem/issue dealt with the Grandmother not understanding the login page. What if someone -- I half-way volunteer once I get Apache re-installed -- wrote a page that had two fields and a button, a simple login page. The person would login, and then the script would ask LJ if there were any new friends' entries. If there were none, it would say there were no new entries. If there were new entries, it would redirect the browser to...

http://turbov21.livejournal.com/friends?user=[user]&password=[password]

...so the reader could be logged in and look at the new entries. I'm not sure how reliable this would be without some tinker, though. The first and second time I tried the URL, LJ gave me a cookies error. However, once I logged in, logged out, and refreshed the page I saw my friends' list. I'm not sure if this would ultimately be EASIER, but it's a start.

---

What LJ needs, in my humble opinion as the newbiest newbie in lj_client country, is a way to query friends like we can entries. Then we could feed from the site, and do things like this. That's my opinion anyway. Frank the Goat may want to kick me in the head for suggesting a waste of "ba-a-a-andwidth", but marshalled right it would be a boon to LJ application developers.
(Reply) (Parent) (Thread)
[User Picture]From: deslea
2002-10-29 02:39 pm (UTC)

Re: RSS

I'm not sure how reliable this would be without some tinker, though. The first and second time I tried the URL, LJ gave me a cookies error. However, once I logged in, logged out, and refreshed the page I saw my friends' list. I'm not sure if this would ultimately be EASIER, but it's a start.

I've had the same experience. It's not appropriate for me to comment on the specifics of that request (because no answer has yet been approved), but I trialled a few things and I can tell you I had the same sorts of instabilities. I had several instances of invalid cookies.

What LJ needs, in my humble opinion as the newbiest newbie in lj_client country, is a way to query friends like we can entries. Then we could feed from the site, and do things like this.

From your mouth to God's (or Brad's) ears! I don't know that bandwidth need be an issue. Really, it shouldn't take any more bandwidth to do it through a client than over the web. It seems to me (and keep in mind, I'm support, not development, so I could be totally wrong) that the real issue is just that the protocols haven't been written yet.
(Reply) (Parent) (Thread)
From: thellan
2002-10-29 08:50 am (UTC)
I was thinking about this "problem" but from a different angle. I have been working on a client that does something similar to that. The client does not currently provide any ability to edit or add posts. Its purpose is to monitor LJ using the XML-RPC interface to check for new Journal posts by friends, new comments to your posts, and new comments to your comments. The client notifies you when one of these things happens and can take you straight to the correct web page. I thought to do this in order to reduce the number of times people hit reload on their Friends page and such.

The problem is that currently in the XML-RPC interface, and in the flat interface, support for dealing with comments is mentioned but not implemented, and you are required to have the password for any user who's journal you want to check. It would be nice if there could be an option to get just the public posts for an account if you don't have the password when you do a 'getevents' call or a 'syncitems' call using the interface.

I think this would make doing your idea easier.
(Reply) (Thread)
[User Picture]From: deslea
2002-10-29 02:46 pm (UTC)
I was thinking about this "problem" but from a different angle. I have been working on a client that does something similar to that. The client does not currently provide any ability to edit or add posts. Its purpose is to monitor LJ using the XML-RPC interface to check for new Journal posts by friends, new comments to your posts, and new comments to your comments. The client notifies you when one of these things happens and can take you straight to the correct web page. I thought to do this in order to reduce the number of times people hit reload on their Friends page and such.

Wow! Nothing substantial to say here, but what a wonderful tool! I'd love that.

The problem is that currently in the XML-RPC interface, and in the flat interface, support for dealing with comments is mentioned but not implemented, and you are required to have the password for any user who's journal you want to check. It would be nice if there could be an option to get just the public posts for an account if you don't have the password when you do a 'getevents' call or a 'syncitems' call using the interface.

*nods* I've been looking over the protocol documents and thinking that myself. I must confess, I don't understand why that password is necessary for public events. Is it for technical security reasons, or just logistic ones? ::curious::
(Reply) (Parent) (Thread)
From: thellan
2002-10-29 03:39 pm (UTC)

Re:

I am glad to hear that someone thinks the client will be useful. I have not posted it as available yet because I want to add a little more error handling to it before I release it into the wild, but I will announce it when it is ready.
(Reply) (Parent) (Thread)
[User Picture]From: skywalker404
2002-12-13 02:10 am (UTC)
I'm actually interested in building something like that, probably in Java (for cross platform portability) & simply because I know Java better than C++.

Additionally, I'm also interested in having it preload the entries themselves. [Reasoning for this is I'm a member of a LOT of photographic communities, and because of all the images my friends page loads rather slow; images often end up dying halfway or never even starting. Caching/preloading would solve that.]

However, without the ability to load the entries themselves, this is a problem. I'm thinking about trying to add some protocol code myself specifically to allow retrieval of entries, though I'm not really sure where to start. I assume I'd need to learn Perl (which I've been meaning to do anyway) and perhaps BML? I don't know much about how LJ's backend is built.
(Reply) (Parent) (Thread)
From: thellan
2002-12-13 10:10 am (UTC)

Re:

The client I was working on was in Java.

As far as preloading entries and/or images, I do not think that would be very difficult. In the client, I cache several different types of data so that I can minimize the amount of bandwidth used by the client, both on the user's computer and on the LJ servers.

The biggest problem with a client of this sort is the lack of support for the RPC calls needed in the LJ code. The current RPC calls do not allow a user to check for new comments and things like that. However, there was mention recently of changing or adding new functionality to the RPC functions.

The RPC functions are written in Perl, BML (Better Markup Language) as far as I have been able to tell is used to write the webpages, kind of like php or asp. There is also a library of calls that are used, I think they are mostly for accessing the DB and generic things, I am not sure whether it is written in Perl or C++.

As far as the client I was working on is concerned, I just recently started a new job and have been very busy so it has moved to the back burner. I intend to continue working on it once my schedule has settled down again. In the mean time, I would be glad to put up a webpage with the Java code and the XML files on it. I would be glad to answer any questions about it or if you are interested we could work together on it and add the features you were talking about.

Feel free to email me (I believe my email is on my userinfo page) or reply to this to let me know what you think.
(Reply) (Parent) (Thread)
[User Picture]From: rog
2002-10-29 01:58 pm (UTC)
I belive the client you are talking about is called a web browser. It is very easy to use after spending 5 minutes with someone who knows how to use it.

Even easier, put a URL shortcut in the middle of the desktop?

Don't understand why someone needs to login at all??? I nanna wants to read it, make it public.
(Reply) (Thread)
[User Picture]From: deslea
2002-10-29 02:28 pm (UTC)
Because many people don't want to put pictures of their children in public entries, for valid security reasons.

Because people who aren't net-savvy, especially older people, are intimidated by language they don't understand that power users take for granted - things like "Don't bind to IP address" or "browser session" or dialogue boxes that ask them if they want to accept cookies.

The fact is, I've come across several users asking, one way or another, for something along these lines. I don't think it's necessary or helpful to question the validity of their motivations. I'm just asking if anyone has the know-how and interest to make it happen. If you don't, fair enough.
(Reply) (Parent) (Thread)
[User Picture]From: kimera
2002-10-29 03:59 pm (UTC)

ugly hack

This still needs a puller and parser to fully work, and you should look at the page source not the actual page, but might this work: http://www.livejournal.com/users/turbov21/friends

I entitled the friends format for this test_friends_feed and made it public if anyone is interested. I'm not a markup language expert (and it shows), but couldn't design a Perl script (using LWP, which uses cookies) to pull and format a page for someone based on their login information at a third-party location?

As I said, I'll try to work on a parser when I get home, but I welcome anyone who can beat me to it. :) (And, ah, yes, it leaves your friends page unreadable.)
(Reply) (Thread)
[User Picture]From: markpasc
2002-10-30 08:59 am (UTC)

Re: ugly hack

At this point you may as well use real RSS, as you suggested above. There should be zero problem with the cookies thing above: have the client check to see if it's logged in (like fetching http://www.livejournal.com/ and looking for "Hello, username!"), and if not, log in and save the cookie.

RSS 1.0 or 2.0 with a namespace for the LJ-specific tags would be pretty ideal. Style #90827 is an RSS 0.92 style for friends pages, so you might use it as a starting point. I can try to hack it into an RSS 2.0 feed more comparable to your test style if you're interested.
(Reply) (Parent) (Thread)