Attendees: anand_arumug, bassdeal, clsk, j_k9, ttk

Note: All timestamps in UTC.

The meeting's agenda is available here.

As sent to the Mira Development Mailing List on 19/12/2010 with the subject: “Summary of 19/12/2010 Meeting”:

Hi all,

Today's meeting was attended by Alan, Anand, John, Tijoy and myself. You can find a transcript of the meeting here:
http://miragroupware.org/wiki/doku.php/development/communication/archives/101219_biweekly_meeting

I shall address the topics in the order in which they were discussed.

John pointed out some typos on the wiki in the build instructions. I then corrected these typos (sorry for any confusion!).

Tijoy asked if there is a bzr command to see all published branches for Mira. As far as I am aware, the only way of doing this is to visit: https://code.launchpad.net/mira

Anand asked if anyone else has used git-bzr. No-one in the meeting replied, so I presume the answer was “No”. Has anyone else on the list used it?

We first tackled the logging system. Anand has a good first impression of Boost.Log:
- it has been accepted by Boost and is scheduled to be included in a future version
- it uses a simple method of calling the logger
- it is thread safe
- it supports logging levels: trace, debug, info, warning, error, fatal
- it supports defined sources and sinks (including screen and file); the format of the log output to a file can be configured.
Anand had to compile Boost.Log in the same directory as the other Boost libraries (because compiling it from its download directory did not work).
He is going to create some tests/examples with Boost.Log and push them to his personal branch, and he is also going to do a write-up on the wiki on how to use the library.
Finally, he is going to ask the Boost developers when Boost.Log will be included in Boost (as opposed to just being formally accepted) and determine whether it supports rolling logs (in Tijoy's words: to “create new log file periodically depending on file size or time”), and let us know.

With regard to the Network layer, following the discussion in our previous meeting Alan pointed out another serialization library that he has found: http://avro.apache.org/
We decided to return to this topic when Adam is present, because he is looking into the different options.

We then moved on to the Message Center.
Anand asked if the messages are logged automatically. Based on our blueprint, yes, they should be stored and synchronised with the Server.
Anand also asked if users should get a limited space for storage on the Server. I replied that this might be a concern in the future when messages will support attachments etc. (and so space limitations per user should be configurable on the Server), but while they are plaintext this is not an issue.
I mentioned that it will be a bit like an internal email client. Tijoy asked why it shouldn't use an email server already set up. I replied that we discussed this recently [in the last meeting, with Adam] and our intention is to keep it internal; implementing an internal system makes it easier to integrate with the other Mira features, and we do not want to pretend to replace the desktop email client with the Message Center.
Anand asked if anyone has used Office Communicator. Alan replied that the Message Center will only be for exchanging text and files for the foreseeable future. It would be nice to have something like the Office Communicator, but we do not have the man-power to create it yet. I pointed out that real-time chat is provided by the Contacts and Chat panes, and we have plans to provide a Video Conferencing Utility (which would allow public and private conferences). Perhaps the lower-level functionality used by our planned features (e.g. video conferencing) could be integrated into the Contacts pane to provide similar functionality in the future. Thoughts?

Anand indicated that our blueprints do not state the use cases that the Utility is intended to satisfy. This is a good point; use cases should be provided in the future, where appropriate.

With regard to the Notes Utility, Tijoy asked how real-time (i.e. changes from participating users being propagated to others instantaneously) it should be. Alan said that it doesn't need to have extensive real-time support. I replied that a problem might be excessive overlap between a real-time Collaborative Editor Utility and a non-real-time Notes Utility.
Neil Fraser's “Guaranteed Delivery Method” design of differential synchronisation supports real-time editing. Tijoy believes this is scalable to non-real-time editing, too, so we should first implement a true real-time algorithm for collaboration and then adapt it to work in offline scenarios.

It would be worth continuing to discuss some of these topics on the mailing list in order to flesh them out in more detail.

Regards,

Max Bossino
Project Manager
http://miragroupware.org

[16:59] bassdeal joined the chat room.

[17:00] j_k9: Hello bassdeal, ttk :)

[17:00] bassdeal: Hi.

[17:01] ttk: Hello …

[17:01] j_k9: I hope you're both well :) Let's just wait a few minutes to see if anyone else joins us

[17:02] bassdeal: Finally got this think to build and run this morning on my notebook. Still have problems on my desktop (main development system) at home. I am traveling between VA and NY. In Baltimore now.

[17:02] ttk: Am good…… How have been your weekend so far ..?

[17:03] anand_arumug joined the chat room.

[17:03] j_k9: Weekend has been good - a little chaotic!

[17:03] j_k9: bassdeal: Travelling and online? Your commitment is commendable! :)

[17:04] j_k9: Hi Anand

[17:04] anand_arumug: hello all this is Anand from Dayton, Ohio

[17:04] anand_arumug: Hi Max

[17:04] anand_arumug: Where are you guys located?

[17:04] bassdeal: Well because of all the build problems I have not been able to do much. I don't feel I can contribute much today but wanted to listen what is going on with the project.

[17:05] bassdeal: Baltimore, MD now. Base in Accomac, VA.

[17:05] anand_arumug: @bassdeal we both are in the same time zone

[17:05] j_k9: I'm in London, United Kingdom.

[17:06] j_k9: bassdeal, I'm sorry about the build problems; I wish I could have been of more help :( Any luck on #boost?

[17:07] bassdeal: Yes. I got it working on my Notebook this morning.

[17:07] bassdeal: Which I am using now.

[17:07] ttk: bassdeal , Are you trying to build on Linux or Mac ?

[17:07] bassdeal: Linux.

[17:07] bassdeal: Ubuntu 9.10

[17:08] ttk: I too used Ubuntu 9.10 to build couple of days back…..

[17:08] j_k9: I have built on 10.10 without problems, and before that on 9.04. I've never come across that issue before!

[17:09] j_k9: anand_arumug: Thank you for your instructions for installing Boost. You may have noticed that I added them to the wiki :) They are more comprehensive that my old instructions, and make certain that everything was in its place.

[17:09] j_k9: *is

[17:09] bassdeal: I will have to see the differences between my notebook and desktop when I get home. Both are Ubuntu 9.10

[17:10] anand_arumug: Thanks.

[17:10] anand_arumug: I am in the process of getting my PC with mira dev setup too. The PC runs xubuntu 10.10.

[17:11] anand_arumug: it was nice to see it has the latest qt-sdk and v1.42 of boost

[17:11] bassdeal: I did notice a couple of small typos in the Wiki instructions. It seems the resulting binaries are build_server and build_client not build-server and build-client.

[17:11] anand_arumug: ah! yes :)

[17:12] j_k9: Thank you - I'll make sure that is changed :)

[17:12] j_k9: Please feel free to register your own wiki accounts, by the way. The more people contributing to it, the better!

[17:12] anand_arumug: are we waiting for some more people to join?

[17:12] anand_arumug: whats the agenda?

[17:13] j_k9: The agenda is here: http://miragroupware.org/wiki/doku.php/development/communication/agendas/101219_biweekly

[17:13] j_k9: Alan has notified me that he will be joining in a few minutes, so is it alright if we wait?

[17:13] ttk: sure ….

[17:13] anand_arumug: oh sure

[17:13] anand_arumug: oh! logging is first in the list!?!?!

[17:14] clsk joined the chat room.

[17:14] j_k9: Haha! Don't worry, we don't have to take it in that order :)

[17:14] j_k9: Hi clsk

[17:14] anand_arumug: i have few things to discuss on the notes utility. its a follow up to my question yesterday

[17:14] clsk: Hi

[17:15] anand_arumug: hi Alan (clsk)!

[17:15] clsk: hello Anand

[17:15] clsk: brb

[17:16] j_k9: bassdeal: where did you see the build-server reference in the wiki? Do you mean mira_server and mira_client? (I think you are right, the wiki mentions mira-server and mira-client)

[17:17] bassdeal: Under Building Mira 3rd section and 5th section down.

[17:17] bassdeal: under /instructions

[17:18] anand_arumug: the - and _ confusion might be because of the way i wrote them.

[17:18] j_k9: Thank you - it's changed :)

[17:18] bassdeal: Thanks.

[17:18] j_k9: Sorry for the confusion

[17:18] bassdeal: That was the least of my problems .

[17:18] ttk: Is there a bzr command to see all published branches ? I was trying to see Alan's branch , but couldnt figure out a way

[17:19] j_k9: You can download the branch with: bzr branch lp:~mira-dev/mira/login-system

[17:19] j_k9: The only way to see all published branches for Mira, as far as I am aware, is: https://code.launchpad.net/mira

[17:21] anand_arumug: you can pull the changes from his repo if he has made it public.

[17:21] ttk: so lp:mira is 0.2 official branch ?

[17:22] j_k9: ttk: It is, but it is very outdated, e.g. Alan's login-system branch has made some major developments which have not yet been merged into lp:mira

[17:22] ttk: Hmm , I should sync to Alan's branch

[17:22] anand_arumug: you can branch off of 0.2 and pull his changes.

[17:23] anand_arumug: has anyone used a git-bzr bridge? something similar to git-svn?

[17:26] j_k9: Sorry Anand, it doesn't look like it! Is there a reason you're asking?

[17:26] anand_arumug: i'm familiar with git so i thought its easy if there was a bridge like git-svn

[17:27] anand_arumug: i found this git-bzr but not sure how to integrate it with git. so thought some one in this group might know of it?!

[17:28] j_k9: Hopefully we'll be able to mull that question over so that if anyone has, they can answer at some point. Are we ready to begin the meeting? :) We can have more questions at the end.

[17:29] anand_arumug: i guess so.

[17:31] j_k9: I think we should start with the design topics. Anand, are you still interested in working on the logging system?

[17:31] bassdeal: I am ready.

[17:34] ttk: Are we ready to talk about logging system ?

[17:35] anand_arumug: oh sure

[17:35] j_k9: Yes, I think we might as well start on that. We can leave the Administrative topic till the end.

[17:35] anand_arumug: i'm playing with Boost.Log now

[17:35] j_k9: anand_arumug: Were you able to look into log4cpp or Boost.Log in more detail?

[17:35] j_k9: Ok

[17:35] j_k9: First thoughts?

[17:36] anand_arumug: I haven't tried log4cpp yet

[17:36] anand_arumug: setting up boost.log took me sometime. i was trying to compile it from the dir where i downloaded it instead of in the same dir as other boost libs

[17:37] anand_arumug: i think it will be better if we go with boost.log since it is accepted and will be included in future version of boost

[17:37] anand_arumug: but i'll give my verdict sometime this week.

[17:37] j_k9: Ok, that's great. Would you also please put any tests you create in your personal branch? Some of the other developers might like to review them to see how Boost.Log works.

[17:38] anand_arumug: sure. my plan is to try some examples and use it as part of the 0.2 branch i have

[17:38] anand_arumug: and do a write up on the wiki on how to use it.

[17:38] clsk: Will it? I see it was accepted a long time ago and it still hasn't been integrated into boost

[17:38] anand_arumug: in the mean time if any of you want to try it out you can download it from http://sourceforge.net/projects/boost-log/files/boost-log-1.0.zip/download

[17:39] anand_arumug: and the docs are at: http://boost-log.sourceforge.net/libs/log/doc/html/index.html

[17:39] anand_arumug: @clsk that will be a question in boost mailing list.

[17:40] anand_arumug: we can post it and see what we get as reply

[17:40] j_k9: That would be brilliant. Also, the method that Boost.Log uses to call the logger looks just as simple as our proposed 'debug « logLevel « “Log message”;' so I don't think we need to create a wrapper.

[17:40] anand_arumug: yes.

[17:41] anand_arumug: we can define source and sinks so we can log it either to the screen/file/both.

[17:41] anand_arumug: the screen & file are already integrated.

[17:41] j_k9: Great, that's what we want

[17:41] j_k9: anand_arumug: Would you be able to ask the Boost team about the probability that Boost.Log will be accepted and let us know their response?

[17:41] anand_arumug: sure i'll

[17:42] j_k9: Thank you.

[17:43] j_k9: Also, from my brief review of Boost.Log's documentation, it looks like it would be possible to format the logs to a file with the structure proposed in the specification. Is that correct?

[17:43] anand_arumug: yes.

[17:44] ttk: Does boost support configurable log level ?

[17:44] anand_arumug: ah! yes.

[17:45] ttk: great

[17:45] anand_arumug: it already has the following: trace, debug, info, warning, error, fatal

[17:45] j_k9: Excellent. So, are there any outstanding questions or issues regarding the proposed logging system with Boost.Log? (We can evaluate it further after looking at Anand's tests and receiving the response from the Boost team regarding its future integration.)

[17:46] ttk: Am sure boost loggin is thread safe and support rolling logs

[17:46] ttk: ?

[17:46] anand_arumug: you can even set filters to decide which log levels you want to log into your sink (aka file)

[17:46] anand_arumug: yes it has threading support.

[17:46] anand_arumug: if u want u can disable them too.

[17:47] anand_arumug: by rolling logs do u mean append to existing log file and not create/overwrite a new one?

[17:48] ttk: I mean create new log file periodically depending on file size or time

[17:48] anand_arumug: hmm?!?! I dont know. but i'll check that and update back.

[17:49] j_k9: Thank you, Anand. :) Let's move on to the Network layer redesign.

[17:50] j_k9: It's a shame that Adam isn't here, because he was looking into this task. Alan (clsk), is there anything you have thought of regarding the redesign proposal since we last spoke about it?

[17:52] clsk: hm nothing new

[17:52] clsk: I've been looking at google's library. How it works and all that

[17:53] clsk: I found another serialization library http://avro.apache.org/

[17:53] clsk: but haven't really had a chance to look into it

[17:55] anand_arumug: whats this library for?

[17:56] anand_arumug: can Alan/Max give a brief background on what this network layer is about?

[17:57] clsk: client↔server comms

[17:57] j_k9: The Network layer handles all communications between Client and Server, using a selection of predefined messages: http://miragroupware.org/wiki/doku.php/development/blueprints/net_protocols

[17:58] j_k9: The problem, I believe, is that the current implementation interprets each “\r\n” or “\n” as a new message. Is that right, Alan?

[17:59] clsk: yes

[17:59] anand_arumug: Thanks, Max. This is what I was looking for.

[17:59] anand_arumug: can you pls add this link to the launchpad blueprint for network layer. couldn't locate it there.

[18:00] j_k9: anand_arumug: It is there, it's just considered “implemented” :) See: https://blueprints.launchpad.net/mira/+spec/net-protocols-client-server

[18:00] j_k9: But I agree that they should be linked as parent/child

[18:01] anand_arumug: sorry i was looking at this: https://blueprints.launchpad.net/mira/+spec/network-layer

[18:01] j_k9: clsk: Can I just ask how the serialization library is to be used? Will this be used to create the structure for the new network messages?

[18:01] clsk: in the same way we discussed in our last meeting

[18:05] j_k9: Is there anything else that needs to be said about the Network layer redesign in this meeting, then?

[18:06] j_k9: The reason I asked is that there was a lot of uncertainty in the last meeting. So many ideas were thrown in (which is, in itself, great) that it seemed like we didn't settle on any.

[18:06] anand_arumug: its all greek and latin to me now.

[18:07] j_k9: I'm thinking hieroglyphics :)

[18:07] ttk: I think we should have Adam to discuss about network layer…..

[18:07] j_k9: Ok, well let's agree to return to this topic another time, when Adam is present. I believe he is looking into the different options.

[18:08] anand_arumug: by the next meeting i should have some time to atleast glance over the blueprints. so that i can understand what we are talking.

[18:09] j_k9: The Message Center is the next item on the agenda, but I think we can move past it for the same reason as the Network layer. Is that alright?

[18:10] anand_arumug: is this the chatting facility provided in the client?/

[18:10] clsk: yes

[18:11] anand_arumug: i have a question on this feature

[18:11] j_k9: Yes: like an internal email client. It is not real-time.

[18:11] j_k9: Ok, go ahead :)

[18:11] anand_arumug: are the messages logged automatically for future reference?

[18:12] anand_arumug: by logged i mean saved up in a folder specified by the user or into a default folder?

[18:12] j_k9: Good question. I see the benefit of storing them on the Server: if you use Mira Client on two computers, you will see the same messages across both.

[18:13] j_k9: So yes, I think messages should be stored as the user specifies and this should be synchronised with the Server.

[18:13] anand_arumug: so how much space does each user get in the server?

[18:14] j_k9: There is currently no limitation. Do you think a limitation on Message Center messages (in terms of size) might be more appropriate when we support attachments to those messages?

[18:14] j_k9: At the moment, I can't see plaintext taking up so much space to become a problem (unless we end up with an infinite loop somewhere, which might be fun…).

[18:15] anand_arumug: i'm wondering on the impact if the number of users and the number items thats stored by each user increase

[18:16] ttk: If the messaging center behaves like an email client shouldnt it be using the email server already setup…..

[18:16] anand_arumug: the projects for which this collaboration tool will be used is high

[18:17] anand_arumug: and i think we should design features in such a way that administering the server should not become a huge problem

[18:18] j_k9: ttk: The benefit of keeping it internal is that it will, in the future, be integrated with the other features of Mira. We also have no intention of replacing the desktop email client - it is impossible to be a groupware platform and an Outlook/Thunderbird replacement in one :) Having said that, messages that are internal to the system should be as feature-rich as possible.

[18:19] anand_arumug: has anyone used the Office communicator?

[18:19] anand_arumug: especially integrated to office email and sip server?

[18:19] ttk: I use Office Communicator every day…

[18:19] j_k9: anand_arumug: I agree about the limitation, but again, I don't see this as a problem until we start supporting attachments. Even if we have a Server with 50 users, each with 1000 plaintext messages; say each message is 5KB, that's a total of about 240MB - peanuts :)

[18:20] anand_arumug: The reason I raised that point is, what are hoping this message center to be?

[18:20] anand_arumug: is it just for plain text messages or will it become something like the office communicator?

[18:21] anand_arumug: are we going to integrate other types of media?

[18:22] anand_arumug: One thing I find our blueprints lack is the use-cases the utility intend to satisfy

[18:22] j_k9: Sorry, I'm not familiar with Office Communicator. What do you think the Message Center should be?

[18:23] anand_arumug: especially in the context of collaboration.

[18:24] clsk: anand_arumug: at least for the forseeable future, the message center will only be for exchanging text and files

[18:25] clsk: it would be nice to have something like office communicator, but we don't have the man-power to do it yet

[18:25] j_k9: Real-time chat is provided by the Contacts and Chat panes, and video conferencing is intended to be accomplished by a Utility (which would allow conferences public to the Workplace or private between Workplace Members).

[18:27] anand_arumug: i understand. it will be nice if we have a clear list of use-cases each utility is aiming to provide. Because if you look at the big picture here on how mira is going to be used as a collaboration tool amidst the tools that people are familiar.

[18:28] j_k9: Perhaps, in the future, we could develop the Contacts and Chat panes into an Office Communicator equivalent, i.e. allow more than just IM text chat: also video conferencing, screen sharing, etc. What do you think?

[18:29] anand_arumug: my point is we should be complementing to those tools otherwise mira might be seen as just another tool to do the same thing.

[18:30] clsk: anand_arumug: True. I understand what you're saying. There have been many great ideas that have been presented in discussions since we started the project, but nobody has had the time to impolement them.

[18:30] anand_arumug: sorry to raise questions like these when we are into development.

[18:31] j_k9: anand_arumug: That's ok! It's good to raise them, it keeps us in check.

[18:31] j_k9: It's worth bearing in mind that the idea behind Mira is to provide a complete internal collaborative environment. In other words, to some extent to integrated most of the features of some of the tools that people already use.

[18:31] clsk: implement*

[18:32] j_k9: *integrate

[18:32] anand_arumug: good point clsk. are we going to integrate them or implement them?

[18:33] clsk: hmm what?

[18:34] anand_arumug: are we going to integrate the tools that are already there and are familiar to users or are we going to implement them?

[18:35] anand_arumug: when we say collaboration it could mean different to different types of projects. it could mean different in the context of a software team and it could mean different for a media company team.

[18:35] clsk: depends on the case

[18:36] clsk: anand_arumug

[18:36] clsk: anand_arumug: have you read our documentation?

[18:37] anand_arumug: to some extent.

[18:37] j_k9: We don't want to reinvent the wheel, so we will integrate whatever Open Source components are available to provide the features that we wish to support. Other than that, implementing is what we have done (and, I suppose, continue to do).

[18:37] clsk: prehaps going through some logs of previous meetings and mailing list might be of help as well

[18:37] anand_arumug: ok

[18:38] bassdeal: Sorry for the interruption. This has been very educational for me. I have to go since I have a 6-8 hour drive to upstate NY. I plan on studying more up on the docs and the code. If there is a small task that needs to be done I would like to try it to work out the change procedure.

[18:38] clsk: have a good trip bassdeal

[18:38] anand_arumug: have a safe drive bassdeal

[18:38] anand_arumug: hopefully it doesn't snow!

[18:38] bassdeal: Thanks.

[18:38] j_k9: bassdeal: Thank you for joining! Have a good journey :)

[18:38] bassdeal: Later.

[18:39] bassdeal left the chat room. (Quit: Leaving.)

[18:39] j_k9: Is there anything else to be said about the Message Center, or shall we move on?

[18:39] anand_arumug: clsk/jk_9: can you give me the link to past meeting logs?

[18:39] j_k9: http://miragroupware.org/wiki/doku.php/development/communication

[18:39] anand_arumug: thanks.

[18:40] anand_arumug: we can move on

[18:40] j_k9: Ok, let us discuss the Notes Utility.

[18:41] j_k9: I know that a few of us have some questions, so let's start with Tijoy. ttk: do you have any concerns, in particular?

[18:41] ttk: Sure .. I have to leave in another 10 minutes…. but you guys can continuee and i will catch up later….

[18:42] ttk: Couple of things to discuss about Notes are … How real time it should be ?

[18:43] clsk: I don't think it needs to have extensive real-time support

[18:43] j_k9: Yes, that's a good question. In other words, we either update with the Server every time the user presses 'Save' (if online), or in real-time.

[18:43] j_k9: clsk: The problem is that there would otherwise be too much overlap between Notes and Collaborative Editor, don't you think?

[18:43] j_k9: We would have two text editors, one real-time, the other not.

[18:44] ttk: Yes , That's my next point

[18:44] clsk: right

[18:45] ttk: By real time , i mean changes from particpating users should be propagated to others in real time .. so every one see the latest …

[18:45] ttk: Most real time web based editors sync every second or so

[18:45] j_k9: Fraser's design support this. Can this be reconciled with the possibility that a user could be offline for weeks, then resync with changes?

[18:45] j_k9: *supports

[18:46] ttk: Yes , I think so …

[18:46] ttk: But it's a real time editor … but that's the not the way i see notes

[18:46] j_k9: I think so too. I suppose it would only be as good as our fuzzy diff's/patches, OR we use manual conflict handling.

[18:47] j_k9: ttk: Right, precisely. That is why we had the distinction in the first place.

[18:48] j_k9: What is your opinion? Should we have two different editors, or one? If just one, how could we accomplish this?

[18:48] ttk: Ok , Does it make sense to build real time collaborative editor first and adapt it function as notes too ?

[18:49] j_k9: Hmm, so what do you mean… Don't allow the editor to be used by offline users?

[18:49] j_k9: (at first)

[18:49] anand_arumug: are those two different things with different use cases?

[18:50] ttk: My take on this one .. Notes is not so real time , but editor is .. So if we code an algorithm for notes first i doubt we can re-use it for editor

[18:50] j_k9: anand_arumug: One is like Gobby (real-time, http://gobby.0x539.de/trac/), the other is like a static note (better suited when changed rarely, e.g. a meeting transcript).

[18:51] ttk: but if we have a true real time algorithm for collaboration first , we can adopt it work for offline scenarios …

[18:52] j_k9: ttk: I think that would work. When we extend it to offline scenarios, that is when we could bring in manual conflict handling where the fuzzy diff/patch isn't possible (because too many changes have occurred).

[18:52] ttk: Am sorry guys , i have to leave now….

[18:53] ttk: Please do carry on … I will catch up later …

[18:53] anand_arumug: integrating a versioning system like git with notes utility will be easier.

[18:53] clsk: bye ttk

[18:53] anand_arumug: bye ttk

[18:53] j_k9: ttk: Thank you for joining. :)

[18:53] j_k9: ttk: I agree with your proposal, so let's discuss it on the list a bit more to see if it would work.