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)