Hi,

(btw, my first try to post this was using a typekey as an openID source and it gave errors on every try)

I've read the code, and I get most of it now, but writing the roster stuff, for example, requires thinking about the storage of the roster itself. Do we use flat files? mysql? Mogilefs?

Or should we just write something and latter after we know the problems we will be facing, we come back and see how to make it all work?

BTW, you plan to stick with CVS, right? is there a mailing list for commits or something like that, to keep track of the djabberd commits?

Thanks,

http://profile.typekey.com/melo/

Hi Melo,

And yes... looks like OpenID is broken. I see what it is. Sorry, we'll fix that.

Roster stuff:
-- the API in DJabberd isn't done. Quick hack only.
-- we need to separate out the XML parsing from the pure non-XML roster API
-- there should be many roster storage plugins... SQLite, MySQL, Pg, etc. And then LiveJournal will have one that has the same API but just does RPC to LJ.

But honestly I don't know what the Roster API will look like because I haven't read the XMPP-IM spec fully yet... just skimmed.

We hate CVS. Move to SVN/SVK is imminent. We'll probably move one module at a time, and starting with DJabberd.

I'll setup a mailing list for discussion and commits. I'd rather use Jabber for discussion than IRC, just to eat our own dogfood.

I'll post more to my journal when I have some of the above implemented.

Are you planning on using SVK for aggregation of your repo's or for something else? I checked it out at one point, but then just went with svn instead.

I am curious to hear your thoughts on them.

Happy Saint Patrick's Day!

You mean Fitspatricks day ;)

Hi, Brad.

How many concurrent users your server is going to handle?

I can't give an accurate number now. However, given that:

-- The incremental memory cost of new connections is very small since it's event-based, not thread-based,

-- the cost of additional idle connections is zero with epoll and kqueue (both of which it supports, on Linux/FreeBSD respectively),

-- Jabber connections are primarily idle. (compared to, say, HTTP, where somebody's always doing something....)

-- we've seen Perlbal (our HTTP load balancer) do 10s of thousands of connections using the same base framework

I wouldn't be surprised to see DJabberd handle 20,- 30,000 connections without a problem, as long as the underlying operating system could handle it (Linux 2.6, enough memory, etc....), possibly a bunch more on nice hardware.

However, I don't want a single box handling all connections, because eventually we want 2 million connections, so DJabberd is being designed to work in a whole farm representing a single domain.

Also, I'm sure there will be some CPU profiling to do initially, and a few things that'll benefit from being written in C, but most the hard work is already being done in C.

You know, with an lj-based jabber server you'll be able to indicate jabber presence on userinfo pages, as long as the user agrees to share their presence with the lj jabber monitor. I can think of all kinds of potential applications for an xmpp server, things like friends page update notifications or comment post notifications. I'm looking forward to having this sort of thing available.

We have a huge growing list of ways we want to integrate it. It's going to get crazy... I can't wait.