#instantbird log on 06 13 2014

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