All times are UTC.
00:47:47 <-- mpmc has left #instantbird () 00:56:18 --> nhnt11-testing has joined #instantbird 00:57:01 <-- nhnt11-testing has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 01:04:14 <-- Mook_as has quit (Quit: Mook_as) 01:06:58 <nhnt11> Bah, I broke something in the async logs patch... :( 01:13:12 <clokep> Uh oh. 01:13:36 <nhnt11> I'm seeing txt logs :-S 01:13:56 * nhnt11 finds the issue 01:14:10 <nhnt11> or not :S 01:14:16 * nhnt11 shuts up until he's sure 01:14:26 <clokep> :-\ 01:14:28 <clokep> Tests? :P 01:18:49 <-- rosonline has quit (Client exited) 01:19:08 <nhnt11> Yay, fixed it. It did uncover an issue though, so that's good :) 01:53:56 <-- Rym has quit (Ping timeout) 02:14:45 --> mconley has joined #instantbird 02:23:33 <-- arlolra has quit (Quit: arlolra) 03:16:29 <-- clokep has quit (Ping timeout) 04:07:31 <-- nhnt11 has quit (Ping timeout) 04:08:54 --> nhnt11 has joined #instantbird 04:12:05 <-- mconley has quit (Input/output error) 04:28:51 --> jb has joined #instantbird 05:24:33 <-- EionRobb has quit (Quit: Leaving.) 05:51:43 <-- jb has quit (Ping timeout) 06:16:29 <-- nhnt11 has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 06:16:35 --> nhnt11 has joined #instantbird 06:23:57 --> sawrubh|ib has joined #instantbird 06:39:00 --> jb has joined #instantbird 07:04:18 <-- sawrubh|ib has quit (Ping timeout) 07:06:33 --> mayanktg has joined #instantbird 07:20:23 --> sawrubh|ib has joined #instantbird 07:21:10 --> EionRobb has joined #instantbird 07:26:35 <-- jb has quit (Ping timeout) 07:27:10 --> Mic has joined #instantbird 07:27:10 * ChanServ sets mode +o Mic 07:33:27 <mayanktg> Mic: Hi :) 07:33:36 <Mic> Hello! 07:34:03 <mayanktg> What should be the next step after I'm able to make the video call? 07:34:41 <EionRobb> make funny faces 07:35:25 <mayanktg> EionRobb: I already did that last night XD 07:35:43 <EionRobb> well, you're all finished now 07:36:53 * Fallen|away is now known as Fallen 07:36:57 <mayanktg> hehe 07:50:48 <nhnt11> Video calls are working? :) 07:51:43 <mayanktg> Yup. :) 08:03:13 --> Armada has joined #instantbird 08:04:09 --> flo-retina has joined #instantbird 08:04:09 * ChanServ sets mode +qo flo-retina flo-retina 08:05:44 <flo-retina> mayanktg: next step (after the funny faces) is to show us the code, so that we can make funny faces too :-P 08:08:11 <mayanktg> flo-retina: I already posted my WIP on Bug 1018060. :) Still a lot of work is to be done for the conversion (sdp to xml and vice versa). 08:08:13 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1018060 nor, --, ---, mayanktg, NEW, Voice and video call support in XMPP using WebRTC 08:09:15 <flo-retina> oooh, Mic's review queue will start to compete with mine! :) 08:10:11 <mayanktg> That's why asked for a feedback from him ;) 08:10:25 <flo-retina> mayanktg: when looking at the bug it's not immediately obvious to me what's already working, and what still needs to be done. Can you give a 2-3 lines summary of what's left to do? :) 08:10:41 <mayanktg> Yes. 08:14:04 <sawrubh|ib> flo-retina: how can I test xmpp file transfer with a single person, I know how to connect to a MUC, but not to a single person 08:14:05 <mayanktg> flo-retina: I need to share messages between the two clients before one of the two makes a video call request. The conversion from ml to sdp and vice versa needs more sample to gain more accuracy as different devices have different SDP offers and they have variation in how they choose ports (a=rtcp-mux). 08:18:25 <mayanktg> flo-retina: What needs to be done is : 08:18:25 <mayanktg> * currently the call is auto answering (notification should be added for the callee). 08:18:25 <mayanktg> * fix the _targetResource issue (I've just started working on this). 08:18:25 <mayanktg> * I need more sample offers and answers to improve the conversion. 08:18:25 <mayanktg> * The call shouldn't need a conversation before. It could be done even if there had been none before the connection. 08:18:25 <mayanktg> * UI as per the prototype we built few weeks ago. 08:20:28 <flo-retina> sawrubh|ib: do you mean you don't know how to start a private conversation with XMPP? 08:21:32 <sawrubh|ib> what I wanted to do is keep two xmpp users (two instances of IB) and then send files between them 08:21:54 <flo-retina> mayanktg: ok, thanks :) 08:22:05 <flo-retina> mayanktg: and likely code reviews (will likely take several iterations) and more tests 08:22:07 <sawrubh|ib> but I only have one account sawrubh@ck3kr.de so do I need two xmpp accounts or having different resources will differentiate these two clients 08:22:49 <flo-retina> mayanktg: to start a call when there's no current conversation, are you planning to send the offer to several resources, and make the call with whoever answers first; and send a cancel message to the others? 08:23:09 <sawrubh|ib> nvm, I'll create another account I guess 08:23:28 <flo-retina> sawrubh|ib: using different resources _should_ work, but really sounds like a way to shoot yourself in the foot for initial testing. 08:23:31 <flo-retina> so yes, create a second account 08:25:09 <mayanktg> flo-retina: I don't think it would be a good idea. I only need to send the offer to a single person (who is online and I have his conversation window open). So when I click the video call button on the conversation it sends the offer to him and call is initiated. 08:25:40 <flo-retina> mayanktg: sending to several resources is still sending to a single person 08:29:16 <flo-retina> mayanktg: you still need to work on capabilities discovery 08:29:26 <flo-retina> you don't want to send your offer to a resource that doesn't support WebRTC 08:30:10 <mayanktg> flo-retina: Ok. Could you make it more clear. I'm confused with this line "....and make the call with whoever answers first;" What if some other client accepts. Could you clear it please. :| 08:30:40 <mayanktg> Yes. we have XEP 0030 for the service discovery. I'll work on it. 08:32:10 <mayanktg> We have discussed earlier about this. When the account will be connected we will ask resource information (device capability) from the buddies. And enable/disable the calls accordingly. 08:32:19 <flo-retina> is it more clear with "whoever" replaced by "whichever resource"? 08:32:47 <mayanktg> yes! I have understood it now :) 08:32:47 --> jb has joined #instantbird 08:33:14 <flo-retina> "What if some other client accepts." as soon as you get one answer, you cancel the offer for all the other resources 08:34:05 <mayanktg> Yup it cleared my doubt. 08:34:31 <flo-retina> btw, you probably need to also work on finishing/stopping/cancelling a call. 08:34:37 <flo-retina> (I assume you haven't yet) 08:35:01 <mayanktg> No. The call disconnect feature hasn't been added yet. 08:36:51 <flo-retina> once we have working xmpp video calls, it will be fun to make it work on IRC too :) 08:37:23 <sawrubh|ib> will we be the first to do that? 08:37:27 <mayanktg> I should set the priority regarding what should be my net step. 08:37:37 * nhnt11 imagines Instantbird video chat meetings 08:38:21 <nhnt11> Is video MUC one of the GSoC goals? 08:38:48 * nhnt11 guesses not 08:39:00 <-- chrisccoulson has quit (Quit: OSError: [Errno 130] Owner died) 08:39:15 --> chrisccoulson has joined #instantbird 08:39:41 <mayanktg> No..But if time is left we will start working on video IRC. I remember it was on the proposal. 08:41:29 <nhnt11> Hmm. Video chat over WebRTC could be really useful to talk to people on the same network, when internet bandwidth is limited 08:41:38 <flo-retina> nhnt11: video MUCs is not on the roadmap 08:42:10 <nhnt11> flo-retina: It'd be a sizable project on its own right? 08:42:16 <flo-retina> nhnt11: we could try to have videos with 3 people in the call (maybe 4), but more isn't reasonable 08:42:18 <nhnt11> I imagine the UX is not at all trivial 08:42:45 <flo-retina> nhnt11: UX isn't the problem. The problem is that WebRTC works with P2P connections, and the only way to have a (large) conference call is to have a server relaying the media 08:42:54 <nhnt11> 3-4 people is still pretty decent. 08:43:02 <nhnt11> Hmm. 08:43:15 <flo-retina> with 3 people, you can still cheat, and have every participant establish a P2P link with every other participant 08:43:28 <flo-retina> with 4, it can work if participants have a lot of bandwith 08:43:40 <flo-retina> after that... forget it (or switch to audio only) 08:43:45 <nhnt11> like, if they're all on the same network ;) 08:44:04 <flo-retina> (and audio mixing is a problem in itself, because each connection will have a different lag, so people may not be talking in the same order everywhere) 08:44:49 <nhnt11> flo-retina: Are there no standard protocols developed yet for WebRTC over a relay server? 08:45:09 <flo-retina> afaik Firefox doesn't support BUNDLE yet 08:45:34 <flo-retina> (BUNDLE allows for several video and several audio stream inside a single PeerConnection; and for adding/removing streams during the connection) 08:45:42 <nhnt11> Interesting 08:48:04 <nhnt11> flo-retina: Is it really that unreasonable to have more than 2 active connections? What if we lower video quality? 08:48:36 <nhnt11> I know it's definitely not scalable to large numbers, but I would figure we could squeeze in 5 people.. 08:48:44 * nhnt11 supposes his guesses are pretty baseless though 08:49:02 <flo-retina> nhnt11: lots of people have low upload bandwidth 08:49:13 <flo-retina> do you think your connection lets you upload 3 video streams in real time? 08:49:35 <nhnt11> My connection is sucky enough that I don't video chat at all 08:49:38 <nhnt11> :( 08:49:48 <nhnt11> That should change soon though :) 08:49:50 <flo-retina> there are also interesting NAT traversal issues 08:49:53 <mayanktg> Guess what I found searching for BUNDLE . WebRTC SDP eamples http://tools.ietf.org/id/draft-nandakumar-rtcweb-sdp-01.html#rfc.section.5 :-] 08:50:05 <flo-retina> If A can talk to B and B can talk to C, that doesn't mean A can talk to C. 08:50:22 <nhnt11> Interesting! 08:50:28 <flo-retina> (could just be that B's firewall is less annoying that the other two's, and lets P2P connections be established more easily) 08:51:40 <flo-retina> with just that problem (A and C not seeing each other), the participants will likely understand what's going wrong 08:52:03 <flo-retina> with more participants, if any link can go wrong without user-visible reason, it has potential for a really messy call ;) 08:53:52 <nhnt11> Sounds like fun :D 08:55:04 * Fallen is now known as Fallen|away 08:55:59 <flo-retina> yeah, people answering questions that haven't been asked, etc... 08:56:13 <flo-retina> and the mess being different for each of the participants :-D 09:01:48 * Fallen|away is now known as Fallen 09:13:32 <Mic> Oh, lots of requests indeed... 09:13:44 <flo-retina> :) 09:13:45 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 09:14:21 <Mic> Can you copy the summary that you wrote to the bug maybe? 09:15:23 <mayanktg> Yes. I'm making a note on the Bug too. 09:15:45 <Mic> If "some other client accepts" then we've successfully reached the remote user. That's not as bad as you made it sound ;) 09:16:11 * Mic should better read all of the log before commenting as it seems ;) 09:16:37 <-- gerard-majax__ has quit (Ping timeout) 09:18:28 <nhnt11> flo-retina: If I just had a |yield;| in the middle task, would that work like an executeSoon() on the remainder of the task? 09:18:35 <nhnt11> oh, he's gone.. 09:18:52 --> BWMerlin has joined #instantbird 09:24:58 <-- mayanktg has quit (Ping timeout) 09:29:59 --> mayanktg has joined #instantbird 09:39:09 * Fallen is now known as Fallen|away 09:41:49 --> sonny has joined #instantbird 09:42:30 --> flo-retina has joined #instantbird 09:42:30 * ChanServ sets mode +qo flo-retina flo-retina 09:45:31 --> sonny1 has joined #instantbird 09:46:07 <flo-retina> nhnt11: yes. 09:46:21 <flo-retina> hmm 09:46:26 <flo-retina> not sure actually 09:46:38 <nhnt11> Well it's not much use to me either way 09:46:42 <flo-retina> how does task behave is yield doesn't yield a promise? 09:47:03 <-- sonny has quit (Ping timeout) 09:47:20 <flo-retina> maybe yield promise.resolve(); if something needs to be there 09:47:29 <nhnt11> My test queues some messages to be written, and then tests reading them. The problem is that since all the I/O is async, at the time of the getLogsForConversation call, no files would have been created, and an empty enumerator is returned 09:47:48 <nhnt11> aleth doesn't like yielding on each logMessage call, because that's not how production code uses it 09:48:10 <nhnt11> So now I'm queuing all the messages, then yielding on the promise queue... 09:48:22 <nhnt11> It's not really different though 09:48:44 <flo-retina> shouldn't getLogsForConversation also return a promise? 09:48:56 <flo-retina> (and that promise should wait for all stuff to have happened?) 09:49:11 <nhnt11> Um 09:49:32 <nhnt11> flo-retina: getLogsForConversation does return a promise, but the async stuff that's happening is the DirectoryIterator stuff 09:49:36 <nhnt11> to get the list of files in the log dir 09:49:58 <nhnt11> It doesn't wait on pending messages to be written 09:50:20 <nhnt11> What if the I/O is blocked on something? We shouldn't delay displaying whatever logs we /do/ have because of that 09:50:40 <nhnt11> The scenario in a test is quite different 09:51:03 <nhnt11> I don't see anything wrong with yielding until the messages are written :-/ 09:51:16 <nhnt11> There's already another test to ensure the queuing is working properly 09:51:47 * nhnt11 can't think of a way to do this without yielding somewhere 09:51:48 <flo-retina> for the tests, can you have a promise that resolves once all the queue I/O operations are finished? 09:52:03 <nhnt11> flo-retina: You mean once all the I/O operations for that log file 09:52:04 <nhnt11> ? 09:52:07 <nhnt11> If so, yes. 09:52:12 <nhnt11> That's what I've just done for the next patch 09:52:17 <flo-retina> for that log file, or for all the log files in the queue 09:52:38 <nhnt11> Well I guess I could wait for all the log files in the queue, there's a way to get all the keys of a map right? 09:52:40 <flo-retina> for the test you just need a way to have whatever you started before complete before you start reading the results, don't you? 09:52:43 * nhnt11 googles 09:52:53 <nhnt11> Yes, that's why I'm yielding 09:53:05 <nhnt11> Ah yeah, Map.prototype.keys() 09:53:13 * flo-retina hasn't read the code recently, and may be giving not-so-actionable suggestions :-/ 09:53:54 <nhnt11> flo-retina: Dunno if it's enough, but here's some context: https://pastebin.mozilla.org/5402078 09:54:36 * flo-retina should really push his webrtc patch to try before talking more 09:54:56 <nhnt11> The logMessage on line 5 will queue an append operation 09:55:33 <nhnt11> gFilePromises.get(logWriter.path) is a promise that will resolve after all pending operations at that point are complete. 09:56:42 <nhnt11> FYI, I'm probably not going to be online tomorrow (maybe in the evening) 09:57:00 <flo-retina> tomorrow is Saturday ;) 09:57:15 <nhnt11> I figured I'd mention it anyway 09:57:27 <flo-retina> yeah, thanks :) 09:57:48 <nhnt11> Oh and I likely won't be online on the 21st and the 22nd. 09:58:08 <sawrubh|ib> nhnt11: MozCamp? 09:58:21 <flo-retina> bugzilla squashing party? :-D 09:58:29 <nhnt11> sawrubh|ib: No idea what that is. 09:58:30 <flo-retina> (that's what I have on my calendar for these days) 10:00:03 * Fallen|away is now known as Fallen 10:03:33 <nhnt11> Meh, I don't agree with aleth that we should count the number of sessions 10:03:52 <flo-retina> number of sessions? 10:04:34 <nhnt11> Hmm, I mean session messages 10:04:49 <nhnt11> There's one for every "bad" log file 10:05:31 <nhnt11> (Why should we test that the correct number of "bad" log files exist? As long as the correct messages are there, and enumerated by day correctly) 10:06:27 <nhnt11> oh wow 10:06:38 <nhnt11> I've dropped a line in my async logs patch 10:06:51 <nhnt11> No wonder :] 10:08:03 <nhnt11> Hmm so there'll be one session message per log file. 10:08:51 <sawrubh|ib> hmm, so I need to have a conversation or something open with the person I wanna send the file to, otherwise I'm not sure how to give him the notificationbox to accept the file 10:09:01 <sawrubh|ib> also I think I'll get that targetResource issue 10:10:06 * sawrubh|ib takes a look at how to hook onIQStanza to conversation.xml code to open a notificationbox 10:12:02 <flo-retina> nhnt11: I'm not sure what aleth is asking you 10:12:14 <flo-retina> shouldn't you check in the test that each log file starts with a session message? 10:12:43 <nhnt11> Each file? 10:13:12 <nhnt11> imILog.getConversation() adds a session message for each log file 10:13:13 <flo-retina> by 'session message' do you mean the header indicating info about the conversation, or system messages? 10:13:19 <nhnt11> No. I mean system messages 10:13:30 <nhnt11> This: https://mxr.mozilla.org/comm-central/source/chat/components/src/logger.js#344 10:14:19 <flo-retina> aaaah, aren't these the magic messages that aleth added for section scroll in the log viewer? 10:14:28 <nhnt11> I think so, yeah. 10:14:37 <flo-retina> if so, aleth knows better than anybody else how they should be dealt with 10:15:02 <-- EionRobb has quit (Connection reset by peer) 10:15:09 <nhnt11> Yeah. I was confused because I missed line in my async refactoring: https://mxr.mozilla.org/comm-central/source/chat/components/src/logger.js#358 10:15:20 <nhnt11> So I thought session messages were added only for bad log files 10:15:42 * flo-retina didn't even remember these messages existed 10:16:02 <flo-retina> that probably means aleth's stuff was magic enough (ie. it worked) that I didn't have to ever look at them again :) 10:16:48 --> EionRobb has joined #instantbird 10:23:23 --> rosonline has joined #instantbird 10:25:20 --> gerard-majax__ has joined #instantbird 10:52:32 <-- mayanktg has quit (Ping timeout) 10:54:57 --> Hadi has joined #instantbird 11:08:15 <-- rosonline has quit (Client exited) 11:12:56 <-- sonny1 has quit (Ping timeout) 11:15:48 --> aleth has joined #instantbird 11:15:48 * ChanServ sets mode +o aleth 11:18:11 <aleth> flo-retina: Thanks for the review! Now I need to look at the patch again so that I can understand the comments ;) 11:18:43 <flo-retina> aleth: hello :) like I said, I wasn't fully awake yesterday evening. Long day... 11:19:07 --> mpmc has joined #instantbird 11:23:30 --> sonny has joined #instantbird 11:27:02 <-- sonny has quit (Ping timeout) 11:35:36 <nhnt11> aleth: By the way, test output isn't really hard to read 11:35:44 <nhnt11> But I can add messages, shouldn't be a problem 11:36:01 <aleth> nhnt11: I don't know what it looks like with Asserts, that's why I asked. 11:36:22 <nhnt11> aleth: It echoes the test being done, like "test" == "test" 11:36:32 <aleth> With the do_... I found it helpful with the last test I wrote to add messages, but if it's not needed, no problem. 11:36:50 * nhnt11 shrugs. I didn't need them. 11:38:53 <-- EionRobb has quit (Quit: Leaving.) 11:39:17 <aleth> nhnt11: Btw the benefit and drawback of modules is that they don't go through XPCOM. 11:39:58 <nhnt11> aleth: I think the log parser /should/ implement an xpcom interface 11:40:04 <nhnt11> Does that mean it can't be a module then? 11:40:17 <nhnt11> Can't I have an object in the module that implements the interface like clokep said? 11:40:25 <aleth> Well, it depends on whether that interface is part of imILogger.idl or not 11:40:42 <nhnt11> What? What does imILogger.idl have to do with this? 11:40:57 <nhnt11> Should the log sweeping code be part of the logs service? 11:40:59 <aleth> I should probably look at your etherpad first ;) 11:41:03 <nhnt11> hmm, that would make sense.. 11:41:20 --> clokep has joined #instantbird 11:41:20 * ChanServ sets mode +o clokep 11:41:52 <aleth> nhnt11: But take a look at https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/Using so you understand the choices available. Note the shared scope. 11:42:23 <nhnt11> Interesting. 11:42:26 <nhnt11> I likely don't want that. 11:43:28 <aleth> "a given module will be shared when imported multiple times" is key 11:43:41 <nhnt11> yeah 11:44:04 <nhnt11> Stuff may not behave well when we have multiple consumers doing log sweeping for their own purposes 11:44:35 <aleth> Isn't the "sweeping" part a once-only process? 11:44:45 <nhnt11> aleth: What about exporting a prototype, and let the consumer create a new object? 11:44:49 <-- Mic has quit (Ping timeout) 11:44:55 <nhnt11> Once only, for a given consumer 11:45:12 <nhnt11> The stats service and log indexing code do different things with the logs as they're parsed 11:45:32 <aleth> nhnt11: If you want an example of that, look at the tagmenu for example 11:45:40 <aleth> You don't export a prototype. 11:46:46 <nhnt11> you export a "factory" that generates objects for you? 11:46:50 * nhnt11 looks at the tagmenu 11:47:17 <nhnt11> I now see modules as having "static" content ;) 11:48:19 <nhnt11> I think the log sweeping code should just live in the imILogger service, btw 11:51:18 <nhnt11> I'm going to file a bug for moving the log parser to its own file (or logger.js) 11:54:48 <sawrubh|ib> wow, this is so much fun 11:55:20 <sawrubh|ib> clokep: Morning 11:56:49 * gerard-majax__ is now known as gerard-majax 11:59:03 --> sonny has joined #instantbird 11:59:53 <aleth> flo-retina, nhnt11: Btw iirc OS.File has support for lz4, see https://bugzilla.mozilla.org/show_bug.cgi?id=854169 11:59:56 <instantbot> Bug 854169 nor, --, mozilla29, dteller, RESO FIXED, [OS.File] Bindings for lz4 12:01:10 <nhnt11> Nice, seems undocumented 12:01:20 <aleth> It's marked doc-neeeded 12:01:26 <aleth> So it's just recent ;) 12:01:28 <nhnt11> ah yeah 12:02:03 <aleth> But compression is probably best left to followups 12:03:39 --> mayanktg has joined #instantbird 12:06:35 <clokep> nhnt11: It sounds to me like you're describing a service. 12:06:51 <clokep> sawrubh|ib: That's good you're having fun. :P 12:06:51 <nhnt11> clokep: Yeah. It should probably live in the logger service 12:07:01 <nhnt11> BUT, I think I can simplify it to a module with Tasks ;) 12:07:16 * nhnt11 is going to work on that next 12:07:24 <sawrubh|ib> clokep: yes, it's like a puzzle, I should be able to send a IBB initiator and reply thingy soon 12:07:32 <nhnt11> (Even if we want to make it a service, it needs tasks to it's not redundant effort) 12:07:37 <clokep> I don't understand why you're pushing for a service. 12:07:44 <clokep> s/service/module/ 12:07:56 <sawrubh|ib> nhnt11: did you intentionally mention e-ven there? ;) 12:08:00 <nhnt11> I'm not really pushing for anything in particular 12:08:20 <nhnt11> sawrubh|ib: I'm assuming that's rhetorical 12:08:42 <aleth> clokep, nhnt11: The idea was for nhnt11 to understand the range of choices available (eg, you can also have a module imported into logger.js, etc...) 12:10:43 <nhnt11> clokep: The reason it makes sense as a module is that it doesn't maintain any useful data, or listen for events and act on them, or anything. 12:10:57 <flo-retina> aleth: isn't the lz4 compression used by OS.File something custom that nothing else reads? 12:11:07 <nhnt11> All it would do is, on request, iterate through all log files and fire a callback on each one's contents 12:11:11 <flo-retina> nhnt11: you want xpcom if your stuff should be usable both from C++ and from JS. 12:11:13 <instantbot> c++ is e-- ah, nevermind. 12:11:23 <flo-retina> nhnt11: if you only care about it being called from JS, a JS module is easier 12:11:25 <nhnt11> flo-retina: Why would this be used from C++? :S 12:11:26 <nhnt11> Yeah 12:11:41 <clokep> nhnt11: Those reasons seem unrelated to whether it shuld be a module or something else. :) 12:12:08 <nhnt11> clokep: Idk, from what I've seen services are things that run in the background doing useful things regardless if they have consumers 12:12:33 <aleth> flo-retina: Idk what they used exactly, but I don't think lz4 is that rare. 12:12:34 <nhnt11> The log sweeping stuff happens very very rarely, why make it a service? 12:12:37 <clokep> Some services in Mozilla are essentially just factories. 12:12:52 <nhnt11> If it's included in logger.js, fine. Otherwise, it should be a module 12:13:00 <clokep> I think you're thinking of services like OS level services. 12:13:14 <nhnt11> clokep: A service is started at startup right? 12:13:18 <clokep> No. 12:13:57 <aleth> Heh, looks like I wasn't wrong in thinking there was some confusion about Services and modules somewhere then ;) 12:13:57 <clokep> It's just a name. 12:13:58 * nhnt11 doesn't know, then. 12:14:01 <clokep> There's nothing special about it. 12:14:05 <flo-retina> aleth: also, is this compressing a single file (I think so) or a bunch of separate files could also be compressed? 12:14:21 <nhnt11> If it can be a service without using memory when it's not going to be used, great. 12:14:30 <flo-retina> aleth: one of the key reasons I suggested a ZIP file is that we can easily read only one file it contains, and use the jar: protocol. 12:14:47 <aleth> flo-retina: I don't know, I think it's used for the JSON storage but I've not looked into it. I stumbled over the feature in the code when trying to fix an OS.File bug 12:15:43 <nhnt11> aleth: Btw, did you read in the logs about yielding on logMessage in tests? 12:15:52 <flo-retina> nhnt11: a service is just a xpcom component that will stay around forever and will never be automatically destructed. 12:16:24 <flo-retina> aleth: yes, I think the point of that OS.File feature is to store large JSON files (eg. session restore data) more efficiently 12:16:44 <flo-retina> the stats service could maybe benefit from it 12:16:44 <nhnt11> I think I should first answer "Should the log parsing code live in logger.js or in its own file?" 12:16:56 <flo-retina> nhnt11: how many times to you plan to ask that question? 12:17:10 <aleth> It doesn't seem the most important question ;) 12:17:28 <flo-retina> logger.js is the file that handles everything related to logs in the back-end. Why would parsing every go somewhere else? 12:17:39 <nhnt11> Well, the whole discussion of "should it be a module or a service" is redundant if it's going to live in logger.js. 12:17:42 <nhnt11> Yeah exactly 12:18:02 <nhnt11> I just meant that discussing whether it should be a module or a service wasn't useful 12:18:03 <nhnt11> :-/ 12:18:04 <flo-retina> "a module or a service" doesn't fully make sense. 12:18:16 <flo-retina> it could not be a module, but still not be a service either :-P 12:18:55 <nhnt11> ok, then s/whether it should be blabla/what it should be/ 12:20:25 <aleth> nhnt11: is that logmessage discussion obsolete (ie can't I just review your patches) 12:20:41 <nhnt11> yeah you can. 12:20:48 <nhnt11> i'm attaching a new tests patch 12:22:55 <nhnt11> Sorry for all the bugmail btw 12:23:18 <nhnt11> Damn, missed some commas... 12:43:07 <-- aleth has quit (Ping timeout) 12:43:14 <clokep> My...build seems to be in a loop of rebuilding the backend. :-S 12:45:25 <sawrubh|ib> clokep: yeah, that's a bug 12:45:36 <sawrubh|ib> you need to clobber and it should be fixed, someone broke mach 12:48:40 <clokep> sawrubh|ib: Just did, thanks. 12:49:25 <sawrubh|ib> clokep: so according to http://xmpp.org/extensions/xep-0096.html#protocol-tech we need to implement both XEP65 and XEP47 right? 12:50:25 <sawrubh|ib> do we have XEP65 implemented (most probably the answer is no but just confirming)? I'm working on implementing a basic version of XEP47 right now 12:51:57 <clokep> sawrubh|ib: Do you have a bug #? 12:52:09 <sawrubh|ib> about the mach issue? 12:52:09 --> qheaden has joined #instantbird 12:52:15 <clokep> Ye. 12:52:17 <-- flo-retina has quit (Ping timeout) 12:52:24 --> flo-retina has joined #instantbird 12:52:24 * ChanServ sets mode +qo flo-retina flo-retina 12:52:24 <clokep> sawrubh|ib: No. 12:52:33 <clokep> We have nothign to do with file transfer implemented. 12:52:34 --> aleth has joined #instantbird 12:52:34 * ChanServ sets mode +o aleth 12:52:36 <clokep> Atul did some work on it last year. 12:52:44 <sawrubh|ib> no, I don't have the bug number. 12:55:02 <-- sawrubh|ib has quit (Ping timeout) 12:56:13 --> sawrubh|ib has joined #instantbird 12:56:26 <-- mayanktg has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 12:57:00 --> mayanktg has joined #instantbird 13:01:59 <aleth> sawrubh|ib: bug 1024023 13:02:02 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1024023 nor, --, ---, nobody, NEW, Add File Transfer Support for JS-XMPP 13:02:18 <sawrubh|ib> clokep: https://bugzilla.mozilla.org/show_bug.cgi?id=984528 13:02:20 <instantbot> Bug 984528 nor, --, mozilla33, wlachance, RESO FIXED, Rename manifestdestiny -> manifestparser 13:02:35 <sawrubh|ib> aleth: what about it? I've filed that bug :) 13:03:32 <aleth> sawrubh|ib: oh sorry, I didn't realize you'd already filed a bug, so I thought it must be the old one ;) 13:04:11 <flo-retina> sawrubh|ib: clokep marked the bug where Atul worked as a dup of yours 13:04:19 <flo-retina> sawrubh|ib: so the number is visible on the bug aleth linked ;) 13:04:57 <sawrubh|ib> yes, I know, I'll take a look at Atul's code 13:05:12 <sawrubh|ib> I was asking if there had been any implementation besides that, but I have the answer :) 13:05:39 <-- mayanktg has quit (Ping timeout) 13:05:42 --> mayanktg has joined #instantbird 13:05:49 <aleth> mayanktg: What are you working on now? 13:06:01 <mayanktg> The video stream at the callee's end isn't initiated if a use two separate Ib instances for each account. It works fine when I run the two account on same instances.i.e If I sign in from account A in profile Ib1 and B in Ib2, after exchanging a few messages when I try to call B, I receive an error at B stating |video cannot be started| The addstream() fails. (The callee is hence unable to create an answer) :-/ 13:06:32 <mayanktg> Sorry I tried to send this message before, my connection was lost. 13:06:40 <sawrubh|ib> mayanktg: maybe some issue related to 'resources' 13:06:56 <flo-retina> mayanktg: are you on Linux? 13:07:04 <mayanktg> flo-retina: yes 13:07:22 <mayanktg> sawrubh|ib: I guess its not. Because I'm able to send the stanzas. 13:07:25 <flo-retina> mayanktg: try using fake: true in one of the 2 gUM calls. 13:07:34 <mayanktg> Ok. 13:07:38 <flo-retina> mayanktg: IIRC Linux doesn't let 2 different processes access the camera simultaneously 13:07:54 <flo-retina> using a second machine (if you have one) could also help of course :-) 13:10:18 <-- sonny has quit (Ping timeout) 13:11:37 --> sonny has joined #instantbird 13:13:14 <mayanktg> flo-retina: What I get now is varying color stream local stream at both the ends :-/ 13:14:44 <flo-retina> that means you put fake: true on both ends 13:18:02 <mayanktg> I just checked the error log and I'm still getting the same error (video stream initialization failed) at the callee's end. I'm using the same getVideo method where I make the gUM call. 13:19:00 <flo-retina> what's the error? 13:22:35 <mayanktg> Ahh ..its fixed. But I'm getting varying colors at both end ...both for local stream and remote stream. 13:23:23 <flo-retina> that's the intended effect of fake: true 13:23:53 <mayanktg> flo-retina: Ok. Then how would we fix it? :-o I'm sharing a screenshot.. 13:24:09 <flo-retina> use 2 different machines 13:24:16 <flo-retina> but I already said that 13:25:05 <mayanktg> Ok. Understood that. 13:25:14 <aleth> mayanktg: Nobody is ever going to use it this way unless they're a developer testing the feature ;) 13:27:04 <mayanktg> hehe.. btw here's the screenshot http://i.imgur.com/5Us6Me6.png . yuck :S 13:27:56 <-- sawrubh|ib has quit (Ping timeout) 13:27:58 <flo-retina> what are the black pixels at the top? 13:28:00 <mayanktg> What should I approach next? 13:28:17 <flo-retina> why is the local video in the top left corner? :) 13:28:32 <flo-retina> didn't the patch I gave you put it at the lower right corner? 13:29:15 <flo-retina> why is there so much empty space between the camera icon and the XMPP icon? :) 13:29:17 <mayanktg> I removed the resize video method from it, bcause it wasn't included in the "create call". 13:29:31 --> sawrubh|ib has joined #instantbird 13:29:48 <flo-retina> so is it no longer dynamically resizing the videos if you resize the window? 13:29:52 <mayanktg> It is a button like we have in Fx toolbar. 13:30:07 <mayanktg> No. I'll add it with the UI. 13:30:10 <flo-retina> doesn't mean you can't change the padding/margin 13:30:20 <aleth> Do we really want the video to fill all of the available space, so it's no longer possible to send text messages? 13:30:28 <flo-retina> aleth: no 13:30:52 <sawrubh|ib> aleth: so both IBB and SI have this Offer and Result thing, where one sends the 'offer' and waits for the 'result', so we send a SI offer, get a result, then send an IBB offer and then get the result and then start the transfers? 13:30:57 <mayanktg> No. We will have to divide the video:chat area in some aspect ratio I guess. 13:31:14 <aleth> flo-retina: iirc there's a bug waiting for review about the buttons, so that's probably where the discussion of that should go. 13:31:27 <flo-retina> aleth: yeah, yeah, I should do my reviews, I know :-P 13:32:00 <aleth> flo-retina, mayanktg: Probably a dedicated browser element for the video call part rather than injecting into the convbrowser too... 13:32:20 <flo-retina> aleth: why? 13:33:35 <aleth> flo-retina: well, not necessarily, but it may be an easy way to allow the user to resize the relative space the video and the text part take up 13:34:36 <aleth> mayanktg: What do you propose the UI to look like? Do you have a mockup somewhere? 13:34:53 <mayanktg> Yeah.Wait...I'm sharing it 13:35:30 <aleth> How will we notify the user of incoming calls? What if IB doesn't have focus/is minimized/another conversation is focused? 13:36:28 <mayanktg> aleth: http://i.imgur.com/UcxFIju.png 13:37:05 <aleth> That top-right square is the video call close button (X) ? 13:37:36 <aleth> What do the buttons do? 13:38:06 <-- mayanktg has quit (Ping timeout) 13:38:36 --> mayanktg has joined #instantbird 13:39:40 <mayanktg> sorry. Powercut here. The one inside the top-right corner of video call is full-screen button. 13:39:50 <mayanktg> *video pane 13:41:03 <mayanktg> The erson can end the call from the panel given in second prototype. 13:42:10 <mayanktg> There are buttons for (audio call, video call, file transfer and target switcher). 13:42:44 <aleth> How about having the webcam icon turn green while a call is active? 13:43:06 <mayanktg> Yeah. That's what we are supposed to do :) 13:44:08 <aleth> I'm not sure the panel is actually needed - click the button again to terminate the call, and have a context menu over the call area for the other stuff maybe? 13:44:28 <mayanktg> There won't be any button if the client doesn't support webRTC. If the call is established the button would turn green. 13:44:34 <clokep> Bah, bug 1021684 looks like it's going to be a PITA. 13:44:36 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1021684 nor, --, ---, nobody, NEW, Update box.com Filelink implementation to new APIs 13:44:44 <clokep> I wa shoping to finish it this morning, but haven't made any progress. 13:44:48 <aleth> Anyway, this needs input from lots of people and some investigation of whether there is a "standard" expected UI for this 13:45:00 <aleth> clokep: does it involve oauth messes? 13:45:14 <clokep> aleth: Of course. 13:45:27 <-- sonny has quit (Ping timeout) 13:45:27 <clokep> And files not being available to use messes. ;) 13:46:00 <mayanktg> It was a prototype I made as per flo-retina on 19th May if I remember. 13:46:02 <mayanktg> :) 13:46:22 <mayanktg> It can be altered what suits the best 13:46:25 <aleth> mayanktg: It's a good one to work from for now :) 13:46:47 --> sonny has joined #instantbird 13:47:42 <flo-retina> aleth: let's not discuss UI in confusing ways please :) 13:48:09 <-- mayanktg has quit (Ping timeout) 13:48:20 * aleth wasn't trying to be confusing... 13:48:57 --> mayanktg has joined #instantbird 13:50:16 <mayanktg> aleth: yes. What should I work on today? Improving the UI as per the given prototype and also adding resize video to it? 13:51:23 <flo-retina> clokep: could we just let calendar have its fork of OAuth2.jsm? 13:52:23 <aleth> mayanktg: That would be OK, and/or call termination I guess 13:52:25 <clokep> flo-retina: Sure. 13:54:32 <mayanktg> I will do some UI stuff today so that it at least gets presentable. After then I will go for the termination feature. 13:55:59 <mayanktg> Also I had doubts regarding memory usage during WebRTC Calls. I will find how its managed and give a read to it. 14:00:53 <sawrubh|ib> mayanktg: does you patch involve changes to xmpp.jsm? 14:05:06 --> Rym has joined #instantbird 14:10:45 <mayanktg> sawrubh|ib: Yes. They do 14:11:21 <mayanktg> I have added two new functions at xmpp.jsm. Why? 14:14:07 <sawrubh|ib> clokep: can we have some discussion if you are free? 14:14:37 <clokep> sawrubh|ib: OK. 14:15:00 <sawrubh|ib> clokep: can you come to the etherpad? 14:15:24 <sawrubh|ib> last section 14:15:48 <clokep> sawrubh|ib: Link 14:15:58 <sawrubh|ib> clokep: https://etherpad.mozilla.org/ib-filelink-week4 14:16:35 <sawrubh|ib> I wanted to discuss how to structure the code so that more modularity and reusability is there 14:19:13 <clokep> OK. 14:23:43 <clokep> I'll start reading in a moment. 14:28:27 <sawrubh|ib> aleth: a question for you at the end of that etherpad 14:28:39 --> mconley has joined #instantbird 14:30:46 <-- jb has quit (Ping timeout) 14:33:05 <clokep> sawrubh|ib: I'm not sure what that section talks about, flo-retina knows XMPP much better than me. I need to step away for a second. 14:33:29 --> iamjayakumars has joined #instantbird 14:34:08 <sawrubh|ib> flo-retina: https://etherpad.mozilla.org/ib-filelink-week4 last section 14:36:16 <-- aleth has quit (Ping timeout) 14:36:31 --> jb has joined #instantbird 14:37:32 --> aleth has joined #instantbird 14:37:33 * ChanServ sets mode +o aleth 14:37:52 <-- Rym has quit (Ping timeout) 14:39:53 --> Rym has joined #instantbird 14:49:04 <-- jb has quit (Ping timeout) 14:50:01 <-- clokep has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 14:50:06 --> clokep has joined #instantbird 14:50:06 * ChanServ sets mode +o clokep 14:59:32 <-- iamjayakumars has quit (Quit: ) 15:02:10 --> jb has joined #instantbird 15:04:51 --> iamjayakumars has joined #instantbird 15:18:29 <flo-retina> sawrubh|ib: what's the question? 15:18:35 <-- sonny has quit (Ping timeout) 15:19:05 <sawrubh|ib> flo-retina: what's happening in this section : http://xmpp.org/extensions/xep-0096.html#registrar The section above that already tells how we start a file transfer by sending a iq stanza with a 'si' child, why do we need this then? 15:22:49 <flo-retina> sawrubh|ib: that section seems to define how XMPP URIs can handle sending files 15:23:03 <flo-retina> URIs like xmpp:romeo@montague.net/orchard?sendfile and xmpp:romeo@montague.net/orchard?recvfile;sid=pub234;mime-type=text%2Fplain;name=reply.txt;size=2048 15:24:19 <sawrubh|ib> what does that mean? How is that different from what I'm doing? 15:24:35 * sawrubh|ib will read the XMPP URI spec probably 15:24:57 <flo-retina> sawrubh|ib: that's about writing links that can be clicked, like mailto:name@server.com links 15:25:04 <flo-retina> you don't care about any of this 15:27:33 <sawrubh|ib> cool :) 15:36:42 --> sonny has joined #instantbird 15:41:08 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 15:42:37 <-- BWMerlin has quit (Quit: BWMerlin) 15:44:15 <-- Rym has quit (Ping timeout) 16:05:37 --> Rym has joined #instantbird 16:11:19 <-- gerard-majax has quit (Ping timeout) 16:14:41 <-- iamjayakumars has quit (Client exited) 16:16:48 <-- sawrubh|ib has quit (Ping timeout) 16:17:51 --> iamjayakumars has joined #instantbird 16:18:43 --> sawrubh|ib has joined #instantbird 16:18:50 --> Mic has joined #instantbird 16:18:50 * ChanServ sets mode +o Mic 16:28:41 <-- iamjayakumars has quit (Ping timeout) 16:29:26 --> iamjayakumars has joined #instantbird 16:38:19 <-- aleth has quit (Ping timeout) 16:43:24 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 16:46:44 <-- jb has quit (Ping timeout) 16:51:14 <-- Hadi has quit (Connection reset by peer) 16:55:47 --> jb has joined #instantbird 16:55:51 --> aleth has joined #instantbird 16:55:51 * ChanServ sets mode +o aleth 17:00:11 --> gerard-majax has joined #instantbird 17:07:57 --> Hadi has joined #instantbird 17:07:59 --> Mook_as has joined #instantbird 17:13:11 <clokep> sawrubh|ib: How goes it? 17:13:53 <sawrubh|ib> The actual sending of the data on the IBB, Atul's code can be reused 17:14:03 <sawrubh|ib> I'm writing the service discovery part 17:14:20 <sawrubh|ib> jumping between the XML api and spec 17:14:27 <sawrubh|ib> but I'm not facing any problems right now 17:16:28 <clokep> sawrubh|ib: OK. Just make sure it's well written code. 17:17:05 <sawrubh|ib> I'll try :) 17:17:23 <sawrubh|ib> can't guarantee in the first WIP I post soon though :D 17:17:59 <aleth> Make sure you don't use any sync file I/O ;) 17:18:12 <sawrubh|ib> ok 17:31:42 <sawrubh|ib> I wonder if sublime has any shortcut to where I was after doing a search 17:31:59 <sawrubh|ib> I mean go back to where I was before starting the search 17:32:35 <-- jb has quit (Ping timeout) 17:33:30 --> unghost has joined #instantbird 17:33:50 <sawrubh|ib> also I guess we have no support for XEP30 right now 17:33:51 <-- aleth has quit (Ping timeout) 17:35:38 --> aleth has joined #instantbird 17:35:38 * ChanServ sets mode +o aleth 17:36:27 <clokep> I don' tknow what that is. 17:36:36 <clokep> I believe aleth has told you I only have IRC RFCs memorized. :P 17:38:05 <sawrubh|ib> that's the service discovery XEP 17:38:43 <aleth> sawrubh|ib: If you implement that, do it in a separate patch so mayanktg can use it too 17:39:12 <sawrubh|ib> I was doing that but not in a separate patch 17:39:33 <sawrubh|ib> btw interesting news, mayanktg and I are gonna be bitrotting each other's patches I guess :( 17:39:42 <mayanktg> :P 17:40:10 <sawrubh|ib> clokep, aleth: any idea how does one decide the id in http://xmpp.org/extensions/xep-0030.html#example-1 17:40:31 <aleth> I think mayanktg knows the answer to this one ;) 17:41:00 <sawrubh|ib> I mean not extract, but assign or generate? 17:41:09 <sawrubh|ib> mayanktg: yo ^ 17:41:11 <mayanktg> sawrubh|ib: hehe. You have to create one yourself. ie.e generate one 17:41:23 <clokep> sawrubh|ib: Only if you the touch the same parts of the same file 17:41:29 * mayanktg sighs at his keyboard. 17:42:19 <-- aleth has quit (Ping timeout) 17:42:54 <clokep> mconley: I just sent a r? your way, if it isn't obvious you can ignore every change that is inside of im/ those are Instantbird only. 17:43:29 <mconley> cool 17:43:30 <sawrubh|ib> mayanktg: I know I have to generate one, but is there a specific format like there's one mentioned in...finding.. 17:43:35 <mconley> clokep: I'll have a peek tonight. Thanks. 17:43:40 <clokep> mconley: Thanks so much! :) 17:43:48 <sawrubh|ib> gah, it's so easy to misplace these spec links 17:44:29 * sawrubh|ib wonders if that's his patch clokep sent for m-conley's review 17:44:38 <mayanktg> sawrubh|ib: I was finding it too. But unfortunately I culdn't find one which specifes what should ID be like. At different XEPs ID's have been used differently. 17:45:40 <mayanktg> sawrubh|ib: The only one I could find was about message thread ID's which states that they SHOULD be newly generated http://xmpp.org/extensions/xep-0201.html#new 17:46:00 <sawrubh|ib> mayanktg: see http://xmpp.org/extensions/xep-0047.html#create, they mention clearly the sid should be a NMTOKEN datatype 17:46:35 <sawrubh|ib> so what should I go with? setting all id's as 'sawrubh1' ;) 17:46:40 <-- sonny has quit (Ping timeout) 17:46:52 <clokep> sawrubh|ib: You should have gotten an email. ;) 17:47:18 <clokep> sawrubh|ib, mayanktg: I'd suggest that you just use an incrementing counter to start with. 17:48:32 <mayanktg> clokep: Ok. 17:48:39 <clokep> It's easy. ;) 17:48:45 <sawrubh|ib> r- :( 17:48:52 <clokep> sawrubh|ib: Did you see WHY I gave you that? 17:48:55 <clokep> It's a trivial nit. 17:49:11 <clokep> Plus I have those questions, which can probably be in follow ups. 17:49:12 <sawrubh|ib> yeah, but still i crie everytiem 17:49:17 <sawrubh|ib> (a dolan reference) 17:51:33 <sawrubh|ib> clokep: thanks for summarizing it 17:57:14 <-- iamjayakumars has quit (Quit: ) 17:58:20 --> aleth has joined #instantbird 17:58:20 * ChanServ sets mode +o aleth 17:58:28 <Mook_as> sawrubh|ib: http://tools.ietf.org/html/rfc6120#section-8.1.3 ? 17:59:37 <-- sawrubh|ib has quit (Connection reset by peer) 18:10:30 --> sonny has joined #instantbird 18:12:38 --> sawrubh|ib has joined #instantbird 18:13:13 <-- sonny has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 18:14:16 <sawrubh|ib> mayanktg: I'll send a Service discovery patch in 15 minutes 18:15:00 <mayanktg> yay :) 18:15:02 <aleth> You can file a separate bug for it too. 18:15:16 <aleth> That way it can land early and you can both use it... 18:15:53 * sawrubh|ib files a bug 18:22:09 --> jb has joined #instantbird 18:24:19 <instantbot> New Chat Core - XMPP bug 1025150 filed by saurabhanandiit@gmail.com. 18:24:20 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1025150 nor, --, ---, nobody, NEW, Implement Service Discover in XMPP (XEP-0030) 18:26:02 <Mic> Huh? 18:26:15 <Mic> Don't we need service discovery for things like user icons already? 18:26:56 <sawrubh|ib> Mic: I don't see it implemented *scratches head* or have I missed it 18:27:00 <Mic> I mean something should be there already, shouldn't it? Or maybe we're not following the spec here. 18:27:06 <Mic> Let me check. 18:27:26 <sawrubh|ib> I don't see anything in onIQStanza in response to a 'get' type iq stanza 18:27:38 <sawrubh|ib> and all service discovery stanzas are get types so I assumed 18:32:41 <Mic> http://xmpp.org/extensions/xep-0054.html#support 18:33:29 * sawrubh|ib checks xmpp.jsm 18:34:24 <sawrubh|ib> Mic: there is only one entry in http://dxr.mozilla.org/comm-central/search?q=disco_info&case=true&redirect=true, I'm pretty sure it's not implemeted 18:34:42 <Mic> I've found that too. It's not used anywhere as it seems. 18:35:10 <sawrubh|ib> yes, I had checked it exhaustively (in order to be saved from implementing it ;) ) 18:35:35 <clokep> Just try not to duplicate work. 18:35:47 <clokep> It's kind of bad that you guys both depend so closely on this. :-\ That's our bad. 18:36:29 <Mic> Is this a kind of replacement for XEP-0030? 18:36:33 <Mic> http://xmpp.org/extensions/xep-0115.html#intro 18:36:58 <Mic> It's called "Entity Capabilities". 18:38:38 <aleth> interesting. 18:38:49 <aleth> "Clients must be able to participate even if they support only XMPP Core [11], XMPP IM [12], and XEP-0030." 18:42:22 <aleth> So they likely don't contradict each other ;) 18:43:23 * mayanktg giving it a read. 18:43:33 <sawrubh|ib> seems like we're good to go ahead with the implementation then? 18:48:08 <-- aleth has quit (Ping timeout) 18:49:44 --> aleth has joined #instantbird 18:49:44 * ChanServ sets mode +o aleth 18:55:27 <mayanktg> So we should be implementing XEP 0115(Entity Capabilities) instead of 0030(Service Discovery) right? 18:57:18 <aleth> "Clients should not engage in the older "disco/version flood" behavior and instead should use Entity Capabilities as specified herein." sounds like the answer is "yes" 18:58:21 <mayanktg> Okays...0115 it is then. :) 18:58:58 <sawrubh|ib> :/ 18:59:07 <sawrubh|ib> 0030 sounded easy ;) 19:00:11 <-- chrisccoulson has quit (Quit: OSError: [Errno 130] Owner died) 19:00:28 <aleth> It sounds like 0115 refers back to 0030, so you didn't waste time. 19:05:08 --> mayanktg-ph has joined #instantbird 19:17:05 --> mpmc has joined #instantbird 19:25:23 <-- aleth has quit (Ping timeout) 19:27:08 <sawrubh|ib> rosters are buddy/contact lists kind of like addressbooks ? 19:28:31 <clokep> Yes. 19:30:35 <sawrubh|ib> one interesting observation, so both of these XEP's seem to be last updated in 2008, then how come one came earlier than the other? 19:30:52 <clokep> The older one was probably updated to point to the newer one? 19:30:55 <sawrubh|ib> I mean 30 must have come very early to be 85 less than 115 19:31:40 --> aleth has joined #instantbird 19:31:40 * ChanServ sets mode +o aleth 19:32:23 * sawrubh|ib gets some water and sits down for some reading 19:35:32 <clokep> I tink they have release histories at the end. 19:38:25 <sawrubh|ib> if they thought 0030 was causing disco/version floods, why not just say so clearly somewhere uptop, 115 is mentioned right at the end 19:38:45 <sawrubh|ib> imho it should be made more clearer which xep is preferrable 19:40:50 <clokep> That's not something to complain to us about. :-\ 19:54:40 --> clokep_work has joined #instantbird 19:54:40 * ChanServ sets mode +o clokep_work 19:54:42 <-- clokep_work has quit (Input/output error) 19:56:31 <clokep> sawrubh|ib: Can you mark what that bug blocks? 19:57:05 <sawrubh|ib> context? 19:58:11 <clokep> sawrubh|ib: The bug you just filed about service discovery. 19:58:54 <sawrubh|ib> so it blocks my implementation of file transfer in xmpp and mayanktg's bug too 19:59:01 * sawrubh|ib adds his own bug 19:59:03 <-- aleth has quit (Ping timeout) 19:59:59 <-- Mic has quit (Ping timeout) 20:00:06 --> Mic has joined #instantbird 20:00:06 * ChanServ sets mode +o Mic 20:03:18 <-- Hadi has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 20:06:08 <sawrubh|ib> mayanktg: what's your bug number? 20:08:08 <mayanktg-ph> sawrubh: 1018060 20:12:04 <sawrubh|ib> clokep: sorry, wrong field 20:17:50 <clokep> No big deal. 20:28:32 <nhnt11> hi 20:28:36 * nhnt11 sees an r+ 20:45:30 <sawrubh|ib> huh, so in order to check for support for XEP-0115, we need to send a service discover information request, I have a feeling that kind of defeats the point 20:47:33 <sawrubh|ib> http://xmpp.org/extensions/xep-0115.html#support or am I missing something here 20:53:29 <-- mayanktg-ph has quit (Quit: ) 21:00:13 * sawrubh|ib reads it more closely, a second time 21:03:04 --> flo-retina has joined #instantbird 21:03:04 * ChanServ sets mode +qo flo-retina flo-retina 21:19:42 <-- sawrubh|ib has quit (Ping timeout) 21:20:35 --> sawrubh|ib has joined #instantbird 21:28:22 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 21:43:31 <sawrubh|ib> flo-retina: awake? 21:43:37 <flo-retina> vaguely 21:45:13 <sawrubh|ib> ok, so it turns out, we needed service discovery for file transfers (and mayanktg needs it for WebRTC) so we need to implement it, after discussion (and reading through the confusing XEP's) we decided we won't implement XEP30 as that has this problem of disco/version flooding 21:46:02 <sawrubh|ib> where you send such discovery requests to your large roster resulting in huge bandwidth and scalability issues, so they introduced this XEP115 which we decided to implement 21:46:37 <mayanktg> http://xmpp.org/extensions/xep-0115.html 21:47:13 <sawrubh|ib> interestingly, we saw http://xmpp.org/extensions/xep-0115.html#support! now that says that in order to start using XEP115 for capabilities discovery we need to first use XEP30(service discovery) to figure out of the other client supports 115 or not 21:47:25 <sawrubh|ib> which according to me defeats the whole purpose 21:48:25 <sawrubh|ib> so what should we do? 21:50:14 <sawrubh|ib> PREFACE: 115 sends a 'c' childnode in the presence stanza, I see the solution as :check in the presence stanza if there is this c node, if yes then the other client supports it, if no, then it doesn't. If we support it then we would be listening for the c node otherwise we would happily ignore it I guess, so that makes everyone happy 21:50:30 <sawrubh|ib> does all of this make sense :) 21:57:46 * Fallen is now known as Fallen|away 21:58:57 <flo-retina> sawrubh|ib: I think you are making this seem a lot more complicated than it actually is 22:00:40 <flo-retina> I haven't re-read this today, but from what I remember, 0030 explains how you can ask a client what it supports, and 0115 says that you should cache that information to avoid querying it all the time when most of your contacts are using the same clients anyway. 22:01:07 <sawrubh|ib> I was just trying to give a quick overview of everything that's happened upto this point 22:01:25 <sawrubh|ib> flo-retina: yes, that's correct 22:02:28 <sawrubh|ib> my question was do we need to implement service discovery too since I think that's what http://xmpp.org/extensions/xep-0115.html#support says we should do to 'Determine Support' 22:02:30 <flo-retina> so isn't it clear that you need to implement both together? 22:03:13 <sawrubh|ib> hmm, I was thinking that either one of them had to be implemented and was self sufficient 22:04:24 <sawrubh|ib> I think doing what I suggest in my last message (the solution is...) might make 115 self sufficient and then we won't require 30 22:04:25 <flo-retina> Isn't it clear from the discussion above that 0115 requires 0030; and that 0030 without 0115 is spammy? 22:05:35 * flo-retina is rereading 0115 to ensure what he just said makes sense 22:07:06 <flo-retina> sawrubh|ib: if you read http://xmpp.org/extensions/xep-0115.html#howitworks 22:07:07 <sawrubh|ib> it's not clear to me why 115 should require 30 (and if it does, can my suggestion help remove that requirement), also if 30 without 115 is spammy, then why not just use 115 (given we can make it not depent on 30 - which I'm proposing) 22:07:22 <flo-retina> "At this point, your client has no idea what the capabilities are of someone with a verification string 'QgayPKawpkPSDYmwT/WM94uAlu0='. Your client therefore sends a service discovery query to Romeo, asking what his client can do." 22:07:40 <flo-retina> isn't "Your client therefore sends a service discovery query" saying "use 0030" at this point; and only at this point? 22:07:42 <sawrubh|ib> or is it that every client needs 30 as the fallback mechanism for people who don't support 115? 22:08:05 * sawrubh|ib re-reads what was just said 22:08:11 <flo-retina> I think you should just read the XEPs 22:08:17 <sawrubh|ib> I did, twice 22:08:24 <flo-retina> then you need a third reading 22:08:28 <Mic> sawrubh|ib: you can't know if the other client supports XEP-0115 unless you ask what features it supports. 22:08:40 <flo-retina> Mic: that's not correct either 22:08:44 <Mic> That's done using the mechanism in XEP-0030 ? 22:08:48 <flo-retina> nope 22:09:19 <Mic> OK, I'll read it too :) 22:10:41 <flo-retina> Mic: short summary: 0030 is a way to ask a client what it supports. 0115 is a way for a client to advertise as part of its presence information a hash that indicates its capabilities. If that hash is present, you _know_ that 0115 is supported. 22:10:41 <flo-retina> Now if you've already seen that hash before, there's no point in querying the capabilities of that entity; you know it already from your local cache. If you don't have that hash in your cache, you use 0030 to query the capabilities. 22:10:46 <flo-retina> Mic: is that clear? 22:12:00 <-- sawrubh|ib has quit (Ping timeout) 22:12:49 --> sawrubh|ib has joined #instantbird 22:13:11 <flo-retina> sawrubh|ib: are my last 2 sentences clarifying it for you too? 22:13:55 * sawrubh|ib checks the logs 22:14:48 <Mic> flo-retina: yes, it's obvious now. 22:14:54 <flo-retina> ah! :) 22:14:58 <sawrubh|ib> yes, it's clear now. 22:15:29 <sawrubh|ib> why wouldn't someone just write that on top of that XEP in those words :P 22:15:50 <flo-retina> sawrubh|ib: the XEPs are very clear. You just need to read them carefully 22:16:02 <Mic> I think it's a bit surprising to include *all* information in one hash but well... 22:16:11 <flo-retina> sawrubh|ib: the XEPs are designed to be unambiguous to guarantee client interoperability. They are not tutorials. 22:16:37 <flo-retina> Mic: that's what's specified. Google talk does something different of course... 22:17:00 <sawrubh|ib> flo-retina: different as in? 22:17:52 <-- jb has quit (Ping timeout) 22:19:09 <flo-retina> sawrubh|ib: I can't find the documentation page right now :( 22:20:58 <flo-retina> ah, found it! 22:21:00 <flo-retina> sawrubh|ib: https://developers.google.com/talk/call_signaling#Capabilities 22:21:55 <flo-retina> they added an ext="voice-v1 video-v1 camera-v1" attribute to the c node of XEP-0115 22:22:47 <sawrubh|ib> and here I was explaining to you what a c node is used for e_e 22:23:14 --> EionRobb has joined #instantbird 22:23:26 <flo-retina> sawrubh|ib: you know I've touched the XMPP code before, right? ;) 22:23:37 <flo-retina> I've also read lots of XEPs ;) 22:24:06 <sawrubh|ib> btw I think I'll be better able to contribute to the talk on how Hangouts broke interoperability and XMPP and stuff better now 22:24:21 <sawrubh|ib> flo-retina: :) 22:28:59 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 22:31:32 --> wnayes has joined #instantbird 22:48:29 <-- Mic has quit (Quit: Instantbird -- http://www.instantbird.com) 22:58:25 <-- mconley has quit (Connection reset by peer) 22:58:46 --> mconley has joined #instantbird 23:06:31 <-- sawrubh|ib has quit (Quit: sawrubh|ib) 23:18:34 <-- wnayes has quit (Ping timeout) 23:22:09 --> wnayes has joined #instantbird 23:32:35 <-- Mook_as has quit (Quit: Mook_as) 23:35:49 --> BWMerlin has joined #instantbird 23:44:10 <-- Armada has quit (Connection reset by peer) 23:50:55 <-- mayanktg has quit (Ping timeout) 23:51:08 --> mayanktg has joined #instantbird 23:57:08 <-- mayanktg has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 23:57:59 <-- unghost has quit (Quit: Ð£Ñ Ð¾Ð¶Ñ Ñ Ð¾Ñ Ð²Ð°Ñ (xchat 2.4.5 или ÑÑаÑÑе)) 23:58:28 <-- mconley has quit (Input/output error) 23:58:56 --> mconley has joined #instantbird