Log in

No account? Create an account
Generic LJ Client library - LiveJournal Client Discussions — LiveJournal [entries|archive|friends|userinfo]
LiveJournal Client Discussions

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

Generic LJ Client library [Nov. 10th, 2001|03:52 pm]
LiveJournal Client Discussions


[mood |creativecreative]
[music |The Prodigy - Voodoo People]

Hi there,

since I joined the KJournal project started by credendovides, I started thinking about LJ techniques. That raises the question, whether it would be nice to have a generic library, which handles all the protocol stuff, which'd mean, that new LJ Client developers won't have to wonder about communication issues. That'd also make it easy to spread new features (if there are some to come sometimes), which only need to be implemented once and all clients using that lib could be updated easily.

If there is any interest, please let me know and I'd start a public project (e.g. @ SourceForge). If not, I do not need to do so but can do that for myself at home.

From: evan
2001-11-10 12:54 pm (UTC)
We've discussed it a lot.
I actually wrote one, then removed it.

The problem is that a library wouldn't add much.

HTTP should be done by a real HTTP library, which is platform-specific (Mac OSX and Win32 have them as part of the OS, KDE has its way and GTK people use external libraries).

Request information should be returned as a hash, but C has no fundamental hash type.

You could break down every response into structs, but that's more work and it doesn't get you anything.
Instead of
hash_table_lookup(response, "year");
it'd be
and you'd still need to look up that it's "year" and not "date" or something.
(Reply) (Thread)
[User Picture]From: avva
2001-11-10 02:17 pm (UTC)
Yep. I dealt with this question too, and came to the same conclusion.

The protocol currently is just too simple for a generic library to be useful.

This could change, though I rather would it didn't ;)
(Reply) (Parent) (Thread)
[User Picture]From: youngoat
2001-11-10 02:28 pm (UTC)

Why not c++?

Why not write it in c++ and use an stl map?

And I don't know too much about HTTP, so I may be wrontg, but it seems like HTTP is simple enough that it wouldn't be a major sin to just implement the subset that livejournal requires rather than re-use existing libraries for the sake of portability...

Just a couple thoughts...
(Reply) (Parent) (Thread)
From: evan
2001-11-10 03:06 pm (UTC)

Re: Why not c++?

The protocol doesn't seem too complicated, superficially, but it's pretty easy to have problems.

- proxies (each os has different ways of specifying your proxy server)
- line endings (some clients were just sending \n, which worked until we got the bigip and then suddenly clients stopped working)
- new features (we now need to send a fastserver cookie; not too hard to implement, but something worse could happen later)
- weird situations (mangled responses from the server could cause a crash, which in this case means a lost post)
- blocking issues (do you use threads? select()?)

(Reply) (Parent) (Thread)
[User Picture]From: credendovides
2001-11-10 07:46 pm (UTC)

Re: Why not c++?

Argh, another lost post, #$$^&%#!


My 2 cents.. I agree, the protocol is simple enough. Looking at it from a KDE perspective, it is just a little bit of glue work between the application and the HTTP library. If it were more complex, that would be different. And, for example, for KJournal, it will be implemented in C++, while LogJam uses C, and the two are pretty exclusive, despite being the same language. While the C code COULD be used for both, it would not be considered good C++ code.
(Reply) (Parent) (Thread)
From: evan
2001-11-10 08:13 pm (UTC)

Re: Why not c++?

As I recall, KDE has a really cool HTTP library, too. :)
(Reply) (Parent) (Thread)
[User Picture]From: credendovides
2001-11-11 10:53 am (UTC)

Re: Why not c++?

Yeah, it does. And the best part is, the HTML stuff is not an external program. Konqueror is, for the most part, just an implementation of the KHTML class. So one of the features I have planned is the web links opening the view right inside the client window. I was looking over a KDE tutorial, and one of the programs was a fully featured web browser, including all features of Konqueror (Netscape plugins, javascript, cookies, etc) in under 100 lines of code.

Also, it has HTML text display classes, so having a entry preview is not that far fetched.
(Reply) (Parent) (Thread)
[User Picture]From: mart
2001-12-01 08:08 pm (UTC)

Re: Why not c++?

I argued that HTTP was simple enough when Evan used libcurl in LogJam. A few weeks later, mIRC-LJ broke because my HTTP handler sucked. I don't disagree anymore! ;)

(Not that there's a proper HTTP library for mIRCscript, of course... my handler still sucks, it just sucks less now.)

(Reply) (Parent) (Thread)
[User Picture]From: fuchs
2001-12-02 08:19 am (UTC)

Re: Why not c++?

I started working on this lib idea on my own. I'm working on a plain C version as well as on a C++ and a Java package. I think, I'll publish the first versions of them in about 4 weeks. As I have to do a lot of college work, too, I am not able to work on it as constantly as I would like to.
(Reply) (Parent) (Thread)