#instantbird log on 01 03 2010

All times are UTC.

00:50:03 <-- stevo has quit (Quit: Ex-Chat)
01:20:46 --> Orny has joined #instantbird
01:22:44 <-- Orn has quit (Ping timeout)
01:34:12 <-- Orny has quit (Quit: KTHXBYE)
04:32:21 <-- vicnet has quit (Quit: Instantbird 0.2b2pre)
12:15:42 --> iLobster has joined #instantbird
12:17:32 <iLobster> Greetings
12:19:48 <iLobster> i apologize for disturbing, but servers are down?
12:29:56 <-- Morian has quit (Quit: Leaving)
12:59:35 --> Troy has joined #instantbird
13:00:21 --> Troy_ has joined #instantbird
13:00:22 <-- Troy has quit (Client exited)
13:00:34 * Troy_ is now known as Troy
13:01:15 <Troy> hi
13:05:23 <Troy> Instantbird can't find the update. What's the problem?
13:10:48 <Even> oO
13:11:01 <Even> It's the instantbird services that are down since yesterday evening.
13:11:11 <Even> We are in an update process od the server that is not going very well.
13:11:50 <Even> But don't be too affraid, we didn't loose any data (as of yet at least ^^)
13:15:04 <Troy> You will fix this?
13:18:11 <-- Troy has quit (Client exited)
13:20:45 --> Troy has joined #instantbird
14:09:08 --> GeekShadow has joined #instantbird
14:17:42 <flo> Troy: yes, Even is working hard to fix the problem, don't worry
14:36:39 <Even> It is nearly OK right now.
14:40:19 <Even> Ok, everything should be running now.
14:41:09 <Even> Troy: try it now. It should be OK.
14:41:17 <Troy> ok
14:41:37 <Troy> Good work!
14:42:05 <flo> it's nice to see the front page loading :)
14:42:43 <Even> Yeah.
14:42:55 <Even> I think I'm even more happy about this than you :P
14:43:01 <-- Troy has quit (Client exited)
14:43:08 <flo> that's very likely :-P
14:43:26 <flo> though for the marketing I do on omegle, having a way to show the project is helpful :-D
14:44:25 <flo> last night I talked with a girl from California who had already heard about the project but had never actually tried the application, and who seemed to have ideas related to IM software
14:44:36 <flo> it was sad to be unable to link to the website...
16:14:51 --> instantbot has joined #instantbird
16:14:51 topic changed by gravel.mozilla.org to "Ask questions about Instantbird here. Official website: http://www.instantbird.com. Latest release: 0.2b1. Read http://blog.instantbird.org/. Nightlies: http://ftp.instantbird.com/instantbird/nightly/latest-trunk/ (testing purpose only), IRC logs: http://log.bezut.info/."
16:14:51 * ChanServ sets mode +v instantbot 
16:46:29 --> devfil has joined #instantbird
16:49:04 <flo> hi :)
16:49:18 <devfil> hi o/
16:50:36 <devfil> flo, you are the main dev of the project, aren't you?
16:50:48 <flo> yes
16:52:05 <flo> any question/suggestion? :)
16:52:53 --> felipec has joined #instantbird
16:54:26 <devfil> flo, yes, what do you think about supporting msn-pecan?
16:55:31 <flo> If I remember well, there's an issue with the way the eventloop is handled
16:55:56 <felipec> msn-pecan needs GLib's mainloop
16:56:24 <flo> we have it only on Linux, and I don't think it's going to change
16:57:25 <felipec> flo: GLib's mainloop can be integrated into other mainloops
16:57:33 <felipec> that's how the Adium guys used it
16:58:08 <devfil> flo, I have the Adium implementation of GLib's mainloop if you need it
16:59:43 <flo> felipec: I think we looked at that a few months ago when we had an email conversation, and we didn't find a plateform indepent way to integrate into the way mozilla handles events
17:00:55 <felipec> flo: yeah, I vaguely remember that
17:01:22 <felipec> but did Adium solved the problem at that time?
17:02:12 <flo> if they do, it's probably by directly integrating into some cocoa stuff that I personally know nothing about. And it would not solve anything on Windows.
17:02:46 <flo> devfil: it may be interesting to look at it, though I'm not sure we can use the same solution.
17:02:50 <felipec> flo: no, it doesn't matter, any mainloop has an _idle() function, right?
17:03:13 <flo> I don't know
17:03:29 <devfil> flo, http://pastie.org/765047
17:03:49 <felipec> flo: so you use some kind of mozilla mainloop, right?
17:05:26 <flo> we implement the libpurple eventloop uiops with nsITimer and nsISocketTransportService
17:09:24 <felipec> flo: yes, so purple_timeout_add is mapped to something using nsITimer
17:09:32 <flo> yes
17:10:31 <flo> the code is in this file: http://lxr.instantbird.org/instantbird/source/purple/purplexpcom/src/purpleTimer.cpp#98
17:13:28 <-- GeekShadow has quit (Quit: The cake is a lie !)
17:14:06 <felipec> flo: yes, so the same way a purple_timeout_add is mapped, the GLib mainloop can be pinged
17:15:56 <flo> Why would you want to ping something to look at sockets? A poll syscall is more efficient, isn't it?
17:17:29 <felipec> flo: a poll blocks the UI
17:17:38 <flo> not when on a separate thread
17:17:54 <felipec> flo: yeah, but libpurple is not thread-safe
17:18:00 <flo> doesn't matter at all
17:18:22 <flo> as long as libpurple function and callbacks are always used on the same thread, that's fine
17:19:01 <felipec> flo: yes, but they wouldn't... if I create a separate thread for msn-pecan
17:19:32 <flo> why would a protocol plugin need threads?
17:19:46 <felipec> flo: to poll
17:20:08 <flo> that's why there's the event loop to monitor inputs
17:20:09 <felipec> flo: the only way to avoid polling, and make sure everything runs on the same thread is to use the mainloop
17:20:19 <felipec> exactly
17:20:36 <flo> you just need to call purple_input_add
17:20:50 <flo> and everything will be fine.
17:21:14 <flo> nsSocketTransportService will do it's job, poll it on a different thread, and we will fire the callback on the UI thread
17:21:59 <felipec> flo: yeah, and what do you I do after I receive the call back?
17:22:06 <felipec> er, what do I do
17:23:18 <flo> you process the available data, or if not enough data is available yet you do nothing and wait for the next time the callback function is fired I guess
17:25:05 <felipec> flo: yeah, but what if I'm not doing the processing?
17:25:19 <felipec> what if I'm using relying on GIO to do it for me
17:25:32 <felipec> like asynchronous DNS resolution
17:25:34 <flo> I don't think GIO is available in Instantbird
17:25:44 <flo> DNS resolution is always asynchronous on Instantbird
17:25:50 <flo> if I remember well
17:26:30 <felipec> probably because libpurple decided to implement DNS resolution in a hacky way
17:26:57 <flo> the way they handle DNS resolution is terrible
17:26:59 <felipec> spawning a new process to do it, and then fetch the result
17:27:25 <flo> the last time I tried that, it turned into a forkbomb
17:27:32 <flo> I ifdef'd out that crappy code
17:27:56 <flo> on windows they do "something" with threads also...
17:28:52 <felipec> in GIO it's implemented properly, no thread, no forks, they don't rely on the system to do the DNS resolution
17:29:18 <flo> Mozilla uses threads I think
17:30:10 <flo> I don't care much about how they actually do it as long as it works without crashing and forking :)
17:31:11 --> Morian has joined #instantbird
17:31:11 <felipec> it works perfectly, and it's quite fast
17:31:24 <felipec> of course it was not easy to implement
17:32:03 <felipec> but of course it requires a GLib mainloop
17:32:50 <flo> but do you really think it's the duty of a protocol plugin to care about how DNS resolution is handled?
17:34:16 <felipec> flo: msn-pecan is not really a protocol plugin... it's slowly becoming a library... libmsn-pecan
17:34:58 <felipec> flo: just like wocky (XMPP library), it uses the best available networking stuff
17:37:49 <felipec> IMO libpurple took the wrong path; they could very easily have used GLib's mainloop and say: look, if you want to use libpurple, wrap GLib's mainloop, but no, they thought wasn't possible, so they had to come up with their own mainloop wrapping functions
17:38:02 <felipec> but of course it's possible, just like Adium did it
17:38:15 <felipec> and now the prpls have to suffer with crappy networking stuff
17:38:42 <flo> I have a somewhat unrelated question: what's the long term goal of your work?
17:39:08 <flo> what's driving you, and making you enthusiast about working on this?
17:41:15 <flo> I'm asking this because you seem to have an opinion of the quality of libpurple that is as bad as mine.
17:41:34 <flo> but you are taking a very different approach to solve the problems
17:41:59 <felipec> flo: I want really awesome MSN support, since there's no MSN library that fulfill my needs, I'm trying to build one
17:42:39 <felipec> flo: I mean, not awesome in just one client, I want this to benefit as many people as possible
17:42:50 <flo> I want an awesome IM client. With acceptable or awesome support for all the major protocols, and easy extensibility for people to create plugins for new protocols
17:44:08 <flo> I tend to think writing in C is too much work for a plugin author
17:44:46 <felipec> flo: indeed, but personally I want this to work also on embedded devices... so C seems to be the only realistic option
17:44:52 <flo> and especially, if the author is not an experienced programmers, the resulting plugins tend to be very crashy (look at the "official" msn plugin, or the QQ plugin, ...)
17:44:59 <flo> why?
17:45:06 <flo> we ported instantbird for WindowsCE
17:45:25 <flo> we have a wince-arm version of Instantbird that works (and it was a real pain to port glib by the way)
17:45:39 <flo> Mozilla has just-in-time compilation of JavaScript
17:46:19 <felipec> flo: of course, but it's using libpurple, which is written in C, which pretty much proves my point
17:46:27 <flo> it doesn't
17:46:27 <felipec> and anyway, that's one client
17:46:32 <flo> all our UI is in XML and JS
17:46:46 <flo> that's one client that works on Windows, Linux, Mac, Windows CE
17:46:46 <felipec> flo: I'm talking about the protocol
17:47:01 <flo> we don't have JS protocol plugins yet
17:47:06 <felipec> flo: you can't write it on Python, or Ruby... it would drain the battery
17:47:10 <flo> but that's one of the most interesting goals for 0.3
17:47:54 <felipec> flo: well, yeah, JS might be a good option... but that would only work on this particular client
17:48:10 <flo> which works on all OSes we care about
17:48:23 <flo> and which is easily extensible
17:48:34 <flo> and doesn't crash as often as pidgin
17:48:54 <felipec> flo: yes, that's good for you, but I have different goals
17:49:18 <flo> that's why I asked about your goals ;)
17:49:28 <felipec> flo: for example, I like msn-pecan being integrated in the N900
17:49:59 <flo> isn't that the platform that mozilla targets with fennec?
17:50:00 <felipec> flo: since it uses Telepathy, all I need is to provide a telepathy CM, and it feels as it was part of the system
17:50:31 <felipec> flo: yeah, but my point is that you don't need a client for Skype, another for Ovi, and another for MSN and the rest
17:51:15 <flo> hmm, I think I didn't get that last point
17:51:43 <felipec> flo: check this http://felipec.files.wordpress.com/2009/12/screenshot-20091224-124402.png
17:52:15 <felipec> flo: you have an integrated UI for all the protocols Telepathy supports (including MSN pecan), and I like that UI
17:52:28 <felipec> flo: some people might prefer Pidgin on the N900... msn-pecan also supports that
17:52:48 <felipec> flo: and some might want Instant Bird... ideally msn-pecan would support that too
17:54:28 <flo> I understand your point of view
17:56:37 <felipec> flo: and I think it's really bad that every client is going for their own solution... miranda, emessene, Kmess, aMSN, etc.
17:56:48 <felipec> they all implement the same thing over and over again
17:57:05 <flo> because there's no compatible API for protocol plugins
17:57:55 <flo> I think I even found a JS library handling MSN somewhere. It didn't seem to be maintained a lot, I don't know how outdated it is.
17:58:05 <felipec> flo: yes, but you can write wrappers... if there was a decent C library, but there isn't
17:58:41 <flo> is there a decent reference somewhere of how the protocol works?
17:59:03 <felipec> flo: so that's what libmsn-pecan is supposed to achieve... the initial target would be to have a libpurple wrapper, and a Telepathy CM
17:59:31 <felipec> flo: there are two sites that cover most of it pretty decently
17:59:55 <flo> it's probably not the first protocol that I'll try to rewrite in JS though
18:00:10 <felipec> flo: hypothetic covers most of the old stuff, which is still valid: http://www.hypothetic.org/docs/msn/
18:00:18 <flo> Facebook seems much more appropriate for a "quick test" as it uses a lot of JSON.
18:00:53 <devfil> flo, about Instantbird+msn-pecan: you are using libpurple and I would like to see msn-pecan supported by Instantbird in order to provide a nice MSN client for Mac, msn-pecan has already a lot of requested features but, for example, Adium is using the libpurple MSN protocol making the same wrong choices of libpurple (as PSM = personal message) and ignoring the features requested by users (in msn-pecan there are a lot of stupid wor
18:00:53 <devfil> karounds because some features are not implemented by the UI), we can try together to provide better MSN support in Instantbird (that would be really appreciated by Mac OS X users)
18:02:43 <felipec> yeah, it's one of the most voted features in msn-pecan's issue tracker: http://code.google.com/p/msn-pecan/issues/detail?id=51
18:03:08 <felipec> but I've never managed to convince libpurple developers that it's needed
18:03:16 <flo> ahah
18:03:32 <flo> the simple fact that you are the person asking is enough to make them say "no" ;)
18:04:09 <felipec> flo: it seems they have a pretty bad case of selective memory :)
18:04:27 <flo> I don't think it's worth arguing with them
18:04:29 <felipec> flo: they also said no when I made a case for nicknames :p
18:04:51 <felipec> yeah, me neither
18:05:02 <flo> when I propose something and they accept it's great, if they don't, I do it anyway (we have a forked libpurple) and just don't upstream it
18:05:25 <felipec> flo: really? interesting
18:05:36 <felipec> flo: have looked at libpurple-mini?
18:05:46 <flo> no, I don't know what it is
18:06:20 <flo> I think the single biggest design error in libpurple is that there's no separate API for UIs and prpls.
18:06:32 <flo> I makes so many functions so confusing...
18:07:08 <felipec> flo: it's a project I maintain... I took libpurple, and added my own build-system and just build what I absolutely need
18:07:44 <flo> we have our own build system
18:08:12 <flo> well, not "our own", but we build libpurple with mozilla's build system
18:08:36 <felipec> yeah, but maybe we can share the patches
18:08:50 <felipec> some other people might find them useful
18:09:20 <flo> my fork is clearly not ABI compatible
18:09:37 <flo> when something annoys me, I ifdef out or remove/rewrite
18:09:53 <felipec> flo: doesn't matter, it can be a separate branch
18:09:54 <flo> I rewrote the way translations and preferences are handled
18:10:48 <-- Troy has quit (Quit: See you later!)
18:11:14 <felipec> there's a bunch of people watching libpurple-mini... I'm not sure why, but maybe they find the patches useful
18:11:35 <flo> where are the patches?
18:13:09 <felipec> flo: http://github.com/felipec/libpurple-mini/commits/fixes
18:14:23 <felipec> flo: there aren't many right now, it's mostly the build-system
18:14:44 <felipec> but that might change... maybe for telepathy-haze, or Adium
18:14:47 <flo> this is the differences between our libpurple and the official 2.6.4 one: http://queze.net/goinfre/diff-current-to-2.6.4.patch
18:15:20 <flo> I see libpurple as a library handling protocols plugins, not as the core of an IM applications
18:16:06 <flo> so when libpurple handles in a way that I don't like something that is not related to protocol plugins, I ifdef it out and rewrite it in the core of Instantbird. For example, storing accounts, preferences, ...
18:18:44 <felipec> flo: yeah, they shouldn't be doing that
18:19:10 <felipec> more than a library it's like a UI scaffold
18:20:14 <flo> the current libpurple is pidgin minus the functions calling GTK functions
18:20:25 <felipec> flo: yeap
18:21:09 <flo> that's great for someone who would want to write a UI for Pidgin with a different toolkit
18:21:18 <flo> not for someone who wants to write a different IM applications
18:22:12 <felipec> flo: indeed, that's why I don't see the point of calling it a library
18:22:38 <flo> it's used by finch
18:22:50 <flo> which uses it as a dynamic library
18:22:55 <flo> so that seems to work :)
18:23:24 <felipec> flo: you can split any application in half, and call the other half a library
18:23:28 <felipec> that would also work :P
18:25:56 <flo> I can do whatever I want and call it however I want. As long as I don't want people to call it the same way as I do, I'm sure it will work :)
18:26:03 <felipec> anyway, another option for msn-pecan might be to hide a GLib's mainloop inside
18:27:40 <flo> using a timer very often to watch sockets is still a very poor usage of the CPU (and of the battery of mobile devices!)
18:29:31 <felipec> flo: that's exactly what GLib does anyway
18:31:48 <felipec> flo: in fact that's exactly what every mainloop does
18:32:15 <felipec> poll at regular intervals
18:32:38 <flo> mozilla polls in a thread and that seems like an acceptable solution to me ;)
18:34:10 <felipec> flo: why does doing it in a thread makes any difference?
18:34:48 <flo> no CPU is used at all by the application until the OS sends a signal (the poll call is blocking)
18:36:16 <felipec> ahh, it's blocking
18:44:12 <felipec> flo: which version of GLib do you use?
18:48:16 <flo> 2.12 I think, minus lots of functions unused by libpurple that we stripped out.
18:48:33 <flo> (it was a pain to port it to wince, so we removed all the files that weren't actually useful)
18:51:08 <felipec> ah, I see
18:53:35 --> GeekShadow has joined #instantbird
19:01:46 <-- GeekShadow has quit (Quit: http://www.mibbit.com ajax IRC Client)
19:02:37 --> GeekShadow has joined #instantbird
19:04:49 <-- GeekShadow has quit (Quit: http://www.mibbit.com ajax IRC Client)
19:05:30 --> GeekShadow has joined #instantbird
19:29:56 --> Troy has joined #instantbird
19:30:45 <-- devfil has quit (Ping timeout)
19:44:30 --> devfil has joined #instantbird
20:00:28 <-- devfil has quit (Quit: Ex-Chat)
20:02:07 --> devfil has joined #instantbird
20:17:52 <-- Troy has quit (Client exited)
20:18:11 --> Troy has joined #instantbird
20:21:01 <-- Troy has quit (Client exited)
20:32:18 --> Troy has joined #instantbird
21:32:46 <-- Troy has quit (Client exited)
22:01:09 <-- GeekShadow has quit (Quit: http://www.mibbit.com ajax IRC Client)
22:25:35 <-- devfil has quit (Quit: Ex-Chat)
22:49:25 <-- iLobster has left #instantbird ()
23:06:04 <-- felipec has quit (Quit: Ex-Chat)