Attendees: badri, j_k9, neeraj, shilpa

Note: All timestamps in UTC+2

This meeting's agenda is available here.

As sent to the Mira Development Mailing List on 25/05/2010 with the subject: “Summary of 24/05/2010 Meeting”:

Hi all,

Monday's meeting was attended by Badri, Neeraj, Shilpa and myself. You can find a transcript of the meeting here:
http://miragroupware.org/wiki/doku.php/development/communication/archives/100524_weekly

I shall address the topics in the order in which they were discussed. The meeting agenda is available here:
http://miragroupware.org/wiki/doku.php/development/communication/agendas/100524_weekly

Neeraj, Shilpa and I unanimously concluded that shifting the weekly meetings from Mondays at 23:00 UTC to Wednesdays at 23:00 UTC, beginning with the last meeting in June (Wednesday 30th June), would be more convenient for all of us. Alan and Badri: would you be ok with this day and time?

Neeraj and Shilpa would like to work on the Database back-end for the Directory layer together. We agreed that they would need to wait until Alan has finished restructuring the Directory layer before doing this, as they would need to tie in the NEW higher-level Directory layer API with the underlying Database back-end functions.
The SOCI library is looking particular appealing as the base for this feature because it already supports MySQL, Oracle and PostgreSQL. If Neeraj and Shilpa so desired, they could work on creating a wrapper for the SOCI library to use in Mira in a separate Launchpad branch under ~mira-dev (so that they can both push their commits to the repository) and then, once the Directory layer had been updated by Alan, work on upgrading the interaction of this wrapper with the Directory layer which calls it. However, both have decided to work on independent projects first (as mentioned below) because they are smaller in magnitude and will not be delayed due to restructuring.

Neeraj will start by continuing his work on encrypting the authentication system to improve its security (at the moment, the authentication details are transferred in plaintext). He is going to email the mailing list with a proposal of his own, based on Alan's original one:
“A three-way handshake is proposed. First, the Client sends the username to the Server. The Server replies to the Client with the unique salt used for that username. The Client then replies with the password (encrypted using the salt).”
However, this system would only protect the underlying plaintext password - it wouldn't prevent someone who had sniffed the connection from logging in using the same encrypted hash of the password.
Speaking of encrypted hashes, I suggested using SHA-1 as the encryption algorithm. Badri suggested the more secure Triple DES or AES (my preference leans towards AES, of those last two options).
We agreed, however, that the only foolproof method of securing the transfer of this confidential data is to use public-key encryption, which will be accomplished in version 0.3 when we implement Transport Layer Security (TLS).

Shilpa is going to begin by working on the Notes Utility. This will require its own Utility message in order the support the adding, editing and deleting of notes. Notes will also have to be stored in a format (such as XML files on the Client, or XML files or a Database table on the Server) which supports the use of metadata such as the time it was last modified, which user last modified it, etc. On the Client, all XML files would be stored in Utilities/Notes/$Workplace/.
I suggested a small change in the graphical design of the Notes Utility from the mock-up. Instead of having all the Notes listed as tabs on the bottom, I think the Notes page should have a 'main' screen where all the Notes are listed (with the date they were last modified, who last modified it, etc.), and then double-clicking on a note's title would take you to that note. Then, to go back to the main Notes screen, you could click a button such as “Show All Notes”. Clicking on the Notes Utility's tab in the Workplace widget, or on its menu item in the Navigation widget, would automatically take the user to this 'main' screen as opposed to any individual note.
Shilpa suggested the support of permissions (to limit who can read or write to a note), but I advised that (IMHO) it would be best to leave such a complication to a later release.
Alan has stated that he would like to use version 0.2 as the opportunity to make Mira work offline, which is one of the key advantages of Mira over other Open Source groupware platforms. We discussed what would happen if a user were offline, edited a note and then went back online; the Client would synchronise the change with the Server. However, what if two users had edited the same note in that period of time, and both were offline? Would the notes merge when the second offline Client reconnected, or would a copy of the original note be created by the second Client (with its amendments), or would Mira Server resolve the double-editing conflict automatically (in a manner similar to Bazaar, SVN, etc.)? This is something that needs to be discussed in a lot more detail in Thursday's meeting.
Shilpa is going to think through a complete design for this feature (including a protocol) and will send a thread to the mailing list when she has answers.

Badri would still like to work on the Message Center. He is going to come up with a plan with regard to storing the messages in a sensible manner on the Client. For example, the Client might use XML files (similar to the current Directory) and the Server would use whichever back-end the administrator has configured it to use.
Badri asked if users would type in the name of the user they would like to send the message to, or if we intend to provide a user look-up system - a directory of all the users with accounts on that Server. I proposed that the user should first select the Server to connect to, and then download a list of all the other users on that Server (e.g. using the Q token) to allow the user to search for the recipient in the Add Recipient dialog (instead of having to type the full name in, character for character).
But what about sending a message when you are offline - is the recipient look-up data cached, for each Server? Or, does Mira Client only store the contacts that you have sent messages to in the past in your offline look-up directory?

Finally, we have scheduled a meeting for this Thursday 27/05/2010 at 23:00 UTC specifically to talk about the offline use/synchronisation topic (in a lot more detail!). I shall be sending round an agenda shortly - please do advise us if you cannot make the meeting!

Regards,

Max Bossino
Project Manager
http://miragroupware.org

[01:10] neeraj joined the chat room.

[01:10] j_k9: Hi Neeraj

[01:10] neeraj: Hi All

[01:10] j_k9: Shilpa seems to be idling, and Alan hasn't joined (yet?)

[01:10] neeraj: oh

[01:11] neeraj: how are you?

[01:11] j_k9: I'm good thanks! How are you? :)

[01:12] j_k9: Neeraj, seeing as we have plenty of time while we wait, shall we discuss what you'd like to work on after we release version 0.1?

[01:13] neeraj: sure also one more thing I wanted to check with you about the timing of the meeting

[01:14] j_k9: Sure, what do you want to say about the timing?

[01:15] neeraj: Monday's did not work out that well for me these days

[01:15] neeraj: can we move to Wednesday/Thursday ?

[01:16] neeraj: I would prefer Thursday though.

[01:16] j_k9: Thursday at the same time, 23:00 UTC?

[01:17] neeraj: yeah I think that should work well and after the meeting we have list of work to do, on which I could work on weekend

[01:17] neeraj: otherwise with Monday meeting till the time weekend comes there is no energy left.

[01:18] neeraj: Actually there was lot happening at my end in last 6 months so unable to focus on things.

[01:18] j_k9: Hmm ok, I see your point. What about Wednesday at 23:00, is that ok for you?

[01:18] j_k9: Ahh, ok. Have things slowed down a bit now? :)

[01:20] neeraj: Wednesday also sounds decent, depends what other team members prefer.

[01:21] shilpa: Hello MAx and Neeraj

[01:21] j_k9: Wednesday would be preferable at my end. I'll propose it to the mailing list, in a new thread.

[01:21] j_k9: Hi Shilpa! :) Now that you're here: how would Wednesdays at 23:00 UTC work for you, as a meeting time?

[01:22] neeraj: Hi Shilpa, how are you?

[01:22] neeraj: cool thanks

[01:23] shilpa: I am fine. Fpr next 3 to 4 weeks wednesday is super busy for me. But after that I think it would be ok.

[01:23] shilpa: I mean For

[01:24] j_k9: That's ok :) If we were to change it to Wednesday, I think it would be good to keep it on Mondays for the next month or so, and then switch to Wednesdays. We need to see if it's convenient for Alan too, though.

[01:24] shilpa: Sounds good.

[01:24] neeraj: sure

[01:24] j_k9: This isn't on the agenda, but I thought we might start by helping you decide what you would like to work on after we release 0.1?

[01:25] neeraj: Do we have list of things that we have?

[01:26] j_k9: Yes: http://miragroupware.org/wiki/doku.php/development/roadmap#version-0.2-alpha

[01:26] shilpa: Give me a minute to refresh myself with o.2 agendas.

[01:27] j_k9: Sure

[01:27] neeraj: A quick question why is Message Center only on Client side?

[01:29] j_k9: Because the functionality has already been implemented on the Server - it's just a question of tweaking the existing protocol on the Server (but that would be done by the developer working on the Client-side, too) :)

[01:29] j_k9: I think Badri would like to work on this

[01:29] neeraj: ok good.

[01:29] j_k9: By the way, I just received an email from Alan: his car has broken down on the highway, so he won't be able to join us in this meeting.

[01:29] shilpa: I can pick up on Directory level if no one has already commited to work on

[01:30] shilpa: Oh!

[01:31] shilpa: Notes utility can be other one

[01:32] shilpa: Max do you have any oriority order for 0.2

[01:32] neeraj: I could work on Directory layer in that case

[01:33] shilpa: I mean priority

[01:33] neeraj: Lately I looked at it once but did not work much on it.

[01:33] j_k9: There is some priority, in terms of a particular layer having to be implemented or updated first because another layer depends on it, but not much

[01:34] shilpa: Right. I think Directory level needs to be handled first

[01:34] j_k9: The Directory layer is going to be restructured first by Alan, so that might take some time, but either of you would be more than welcome to work on implementing the Database back-end on the side - that's just a question of linking in the soci library properly

[01:34] shilpa: Neeraj we can work together

[01:35] j_k9: After that, all that needs to be done is for the new Directory layer functions to be linked to the Database back-end.

[01:35] neeraj: sure we can do that

[01:35] shilpa: I think we need to add more finctionality to it so that we can get rid of work around codes

[01:35] j_k9: Would you like to work on that together? You could open a Launchpad branch under the ~mira-dev team so that both of you can commit to it, and you could work on it together.

[01:36] neeraj: ok

[01:36] shilpa: Sure. but as you said first we need to restructure it.

[01:36] j_k9: Shilpa: I think that's Alan's idea. He wants to completely rework it so that we don't need to use workarounds any more. In its current form, it was pieced together bit by bit to support the other layers that came along. Now that we know what we need it for, we can give it a better form.

[01:37] shilpa: Yes I agree.

[01:37] j_k9: The Notes Utility is also an interesting feature. It would only take one of you to work on this, as it's not a very large task

[01:37] shilpa: Sure

[01:38] j_k9: It would require its own Utility message to add, edit and delete files, and it would require storing Notes as files of some type (say .xml or .txt), that's something we could discuss together when fleshing out a full design.

[01:38] j_k9: But it shouldn't be a massive task.

[01:39] j_k9: Perhaps one of you would like to work on it while Alan restructures the Directory layer?

[01:39] badri joined the chat room.

[01:39] shilpa: Ok

[01:39] j_k9: Hello Badri :)

[01:39] badri: hey max

[01:39] j_k9: Shilpa, would you like to take that up?

[01:39] shilpa: I can.

[01:40] shilpa: Hello Badri.

[01:40] neeraj: Hi Badri

[01:40] j_k9: Alright, that sounds great. And Badri, do you still want to work on the Message Center?

[01:40] badri: hey shilpa

[01:40] badri: yes

[01:40] badri: max

[01:40] badri: i do want to

[01:40] neeraj: In that case I will just keep playing with Dir layer and soci lib

[01:41] j_k9: Ok. Neeraj, would you like to revisit the encrypted authentication system which you started working on, while Alan focuses on the Directory layer?

[01:41] neeraj: sure that can work

[01:41] j_k9: Then you could work on Directory/SOCI afterwards, if you'd like?

[01:41] j_k9: In collaboration with Shilpa.

[01:42] neeraj: Oh I did not realize it was that Encryption authentication.

[01:42] neeraj: yeah I can get that things out and then with Shilpa work on Dir layer

[01:42] j_k9: We can discuss each of these tasks in more detail later, if you wish - it's on the agenda :)

[01:43] j_k9: Ok, so switching back to the agenda (briefly) - let's start with Administrative topics.

[01:43] j_k9: Alan is currently working on switching all of the Split() functions, which were causing some messages to be dropped. He has almost finished, and should be done some time later today or tomorrow.

[01:44] j_k9: The plan after that is to test it, package it and then release it to the public, so we might actually have the first version out tomorrow!

[01:44] shilpa: cool

[01:44] j_k9: ^ That's all there is to this agenda point, really. It's more of an announcement than anything else :) Is everyone ok with this?

[01:45] shilpa: Ok

[01:45] neeraj: good

[01:45] badri: actually i am kind of out of the page…what r we talking about… are we all set for Version 0.3?

[01:46] badri: i mean to start with

[01:46] j_k9: Badri: We are releasing version 0.1 some time this week, probably tomorrow. After that, we will start working on version 0.2.

[01:46] j_k9: The targets for 0.2 are available here: http://miragroupware.org/wiki/doku.php/development/roadmap#version-0.2-alpha

[01:47] j_k9: Is that ok?

[01:48] badri: sounds perfect to me

[01:48] j_k9: I think we can now move on to discussing the targets for version 0.2.

[01:48] j_k9: Let's start with the Notes Utility. :) Shilpa, do you have any doubts as to what this would entail?

[01:49] shilpa: I think it is pretty much clear from mockup.

[01:49] shilpa: But is there some thinh in specific I need to know.

[01:50] shilpa: I mean thing.

[01:51] j_k9: I think the design should change a bit. Instead of having all the Notes listed as tabs on the bottom, I think the Notes page should have a 'main' screen where all the Notes are listed (with the date they were last modified, who last modified it, etc.), and then double-clicking on a note's title would take you to that note. Then, to go back to the main Notes screen, you could click a button such as “Show All”. Do you know what I mean?

[01:51] shilpa: So we need nothes to be simple text files with facility of add/deleting notes.

[01:52] j_k9: I think they should be more advanced, such as XML files. That way they could support some metadata, as well as the content of a note.

[01:52] shilpa: I Sure

[01:53] j_k9: Each note would be stored as a unique .xml file in Utilities/Notes/$Workplace/ on the Server and on the Client.

[01:53] shilpa: So are notes file private to the user/shared

[01:53] j_k9: Notes are shared with everyone in the Workplace.

[01:53] shilpa: Ok

[01:53] j_k9: In the future, we can add more options such as permissions etc - but we should keep it simple for now, IMHO.

[01:54] shilpa: Ok

[01:54] shilpa: So the notes are dynamic.

[01:55] j_k9: Would you like me to make a mock-up of the 'main' screen I'm talking about, or do you understand the idea of it? Basically an overview page which lists all the notes in that Workplace.

[01:55] neeraj: would there be any issue of having notes file both on server and client?

[01:55] shilpa: That will be great Max.

[01:55] j_k9: I suppose clicking the 'Notes' tab in the Workplace widget, or the 'Notes' item in the menu in the Navigation widget would take the user to this 'main' Notes screen

[01:55] j_k9: Neeraj: If a change were made locally, it would be synchronised to the Server.

[01:56] j_k9: I think this is something that will become more intuitive as of version 0.2, because the first thing Alan wants to do is to restructure the Directory layer, INCLUDING allowing users to work on a Workplace while offline.

[01:57] shilpa: I agree.

[01:57] neeraj: would timestamp be the way to know which file is latest?

[01:57] j_k9: For example: at the moment, the Files Utility on the Client just looks at the data on the Server every time it connects. In version 0.2, both the Client and the Server would store all of the data - they would then synchronise when the Client connects.

[01:58] j_k9: Neeraj, I'm not sure yet - this is something we really need Alan to discuss with us. But with, for example, the Notes Utility, this should be simple - if a user is offline and they create/edit/delete a note, these changes are pushed to the Server whenever the Client next connects (as opposed to 'immediately')

[02:00] badri: it becomes difficult if more than one user changes the same file

[02:00] shilpa: But if two users are seeing the same note and tring to edit it same time then we may run in to conflict.

[02:00] neeraj: ok maybe we can discuss it later in details, I think synchronization could be difficult task,

[02:00] neeraj: .

[02:00] j_k9: Exactly, which is where problems might arise.

[02:00] shilpa: Yes

[02:00] j_k9: We'd need to flag the conflict and ask the second user to correct it.

[02:01] badri: i think so the sync thread should be single threaded

[02:01] shilpa: But interesting.

[02:01] badri: so that it process one update at a time

[02:01] shilpa: Ok

[02:01] j_k9: Or, the second user's update would create a COPY of the original note, as opposed to editing the original note - then, the user could merge the notes manually and delete the copy.

[02:01] shilpa: Ok we need to have some protocol here.

[02:02] j_k9: But this is entirely up to you - it can be as complicated as you want it to be! You could, for example, refer to Bazaar's source code for conflict management.

[02:02] shilpa: I will try to think through it and will propose the protocol on mailing list.

[02:03] j_k9: I think we really need to have an in-depth conversation about synchronisation and how the whole offline system is going to work. Would everyone be up for another meeting some time this week, after releasing 0.1, specifically to discuss this?

[02:03] j_k9: Thank you, Shilpa - that would be excellent.

[02:03] j_k9: So, other than the issue of how offline data (and synchronisation) will be handled, are we ok with this topic?

[02:03] badri: Max … if it is too difficult, could u push the the offline edition to the next version… for the time being we can have just editing the file on the server

[02:03] badri: just a though

[02:04] j_k9: Badri: That is true, although Alan wants to make offline functionality a priority, and I agree with him - that's what will make Mira so useful. :)

[02:04] badri: got it

[02:04] j_k9: It's just something we're going to need to design *well*.

[02:04] badri: got it

[02:05] badri: we can have another meeting

[02:05] badri: later this week

[02:05] j_k9: But we can just inspect other systems such as Bazaar, SVN etc and try to conceive a good, appropriate system for our project.

[02:05] neeraj: sounds good, I could be available for another meeting

[02:05] badri: Wed nite 11 PM EST?

[02:05] shilpa: How about Thursday?

[02:05] j_k9: That would be great! Thursday at 23:00 UTC, perhaps?

[02:05] shilpa: Ok

[02:06] j_k9: Neeraj and Badri: would that be ok for you?

[02:06] badri: yes… i was just trying to convert it to EST ,,,,

[02:06] neeraj: should be fine , btw I mostly am not there for next Monday meeting

[02:06] badri: ;)

[02:06] neeraj: long weekend

[02:06] j_k9: Badri: it would be like an hour ago from now

[02:07] j_k9: Neeraj: Sure thing! Thanks for letting us know.

[02:07] badri: thats correct neeraj.. thanks .. am not available next week either

[02:07] badri: ;)

[02:07] shilpa: I will be not there for next Monday meeting too.

[02:07] shilpa: Thank you Neeraj.

[02:07] j_k9: Ok, I'll write up an agenda for Thursday - hopefully Alan can join us, with his thoughts on how the synchronisation system will work.

[02:07] badri: great … we got a pack now…

[02:07] badri: sure

[02:07] neeraj: cool

[02:08] shilpa: ok

[02:08] j_k9: Right, ok - shall we turn to the next target? Let's discuss encrypted authentication.

[02:08] j_k9: Neeraj, are you ok with the proposal? It is as follows:

[02:08] j_k9: A three-way handshake is proposed. First, the Client sends the username to the Server. The Server replies to the Client with the unique salt used for that username. The Client then replies with the password (encrypted using the salt).

[02:09] neeraj: where are you referring the proposal from?

[02:09] j_k9: I have sent it to the mailing list several times, based on our past meetings.

[02:10] j_k9: e.g. see the Summary of 17/05/2010 Meeting email

[02:10] neeraj: I am justing if its full proof

[02:10] shilpa: I think it should work

[02:11] j_k9: I think it's a good solution, for now. Once the entire communication is wrapped by TLS, it'll be good as foolproof.

[02:11] j_k9: But then, we'll have double encryption: TLS on the connection, and your encrypted authentication on the auth details. :)

[02:11] neeraj: hold on I see a problem

[02:12] badri: max.. i have a question.. whats the key for the encryption… where are we going to store it

[02:12] badri: ??

[02:12] badri: and what encryption algorithm are we going to use?

[02:13] j_k9: Badri: I presume, in this situation, that the Client would merely create a hash of the password using the salt supplied by the Server.

[02:13] j_k9: SHA-1

[02:13] j_k9: ?

[02:13] badri: ok …

[02:13] badri: I wud suggest Triple DES or AES

[02:14] neeraj: If the user send the user id and get the salt then encrypts the message and sends it back to server. In that case doesn't one who listens to this messages exchange can figure out the password?

[02:14] badri: that is true… that was my next question too

[02:15] j_k9: If they listened, they couldn't figure out the password itself, but they could figure out the hashed password (which would be a security error) - but at least the underlying plaintext password wouldn't be revealed

[02:15] badri: we shd have some kind publick key authentication … or we shd do it ove ssl

[02:15] badri: hmm

[02:15] neeraj: I think we should try ssl way

[02:15] j_k9: Badri: We will. When we implement TLS :)

[02:15] j_k9: That'll use public-key encryption to secure the connection.

[02:15] neeraj: yeah the public and private key as we have for launchpad.

[02:16] j_k9: And it will be much easier to set up over the entire connection than to create our own version of public-key encryption specifically for the log-in system. Do you see what I mean?

[02:16] badri: brb… got a honey do ;)

[02:16] neeraj: I see what you saying

[02:17] neeraj: but I want sometime to think

[02:18] neeraj: Just a shot, Can we get a salt associated with a user when we register.

[02:18] j_k9: Of course, that's the great thing about this - we're just talking through it! It would be great if, after thinking about how *you* want to design it, you could send an email to the mailing list in a new thread about this. That way, we can all discuss your design and hopefully come up with something that works well.

[02:18] neeraj: makes sense. Will do

[02:19] j_k9: Great! On to another topic: the Message Center.

[02:19] j_k9: Badri, are you happy with the Message Center blueprint? I've tried to make it as comprehensive as possible: http://miragroupware.org/wiki/doku.php/development/blueprints/layers/message_center

[02:19] j_k9: But do you have any questions or comments?

[02:20] badri: nope… its just straight forward…

[02:20] badri: but basic question

[02:20] j_k9: That's excellent. So you don't have any questions about how you'd want to tackle this, etc?

[02:20] j_k9: Of course - let's hear it :)

[02:20] badri: what is the DB we are using?

[02:20] badri: ;)

[02:20] badri: are the tables already designed? or

[02:21] j_k9: For what - to store the emails?

[02:21] badri: shd i come up with ablan

[02:21] badri: yes

[02:21] badri: plan**

[02:22] badri: did i surprise every one with the question ;)

[02:22] j_k9: You can come up with a design, if you'd like. I think the plan at the moment would be to use the Directory layer API to store the data on the Server (in whichever back-end the administrator of the Server chooses, either filesystem or database), and on the Client to use XML files (as with the current Directory).

[02:23] badri: hmm ok.. got it

[02:24] badri: do we have to design user pick up module

[02:24] j_k9: What do you mean by that?

[02:24] badri: in the To or cc links

[02:24] badri: what i mean is … do we provide them a look up for users

[02:24] badri: to pick the user they want to send

[02:25] badri: or they r tyoing the user name themself

[02:25] badri: ??

[02:25] j_k9: A look up would be provided

[02:26] badri: Also… the protocol for communicating with the server…. Is there a document we can read through… or do we find it out of the code?

[02:26] j_k9: First they choose the Server (even if it's only one Server) - from their list of connections

[02:26] j_k9: And then they would select a User on that Server

[02:26] badri: got it

[02:26] j_k9: Badri: Please see http://miragroupware.org/wiki/doku.php/development/blueprints/net_protocols

[02:27] badri: thanks

[02:27] shilpa: Badi: You will need some new messages like and may have to modify some of the existing ones.

[02:28] j_k9: I think you'll find the 'Q' token will come in handy.

[02:28] j_k9: Although what if a user is offline and they want to send a message? Where would the look-up come from? It would have to be a cached record of this Query. - More to discuss on Thursday :)

[02:28] badri: ok… i will read tro this and come up with ques on thursday

[02:29] j_k9: That sounds good. Are you satisfied that we have discussed this topic enough?

[02:29] badri: ya .. i have an idea for that … only already used user wuld be cached … for others they have to connect or know the user

[02:30] badri: yes i am satisfied

[02:30] j_k9: Excellent. And I like that idea you just proposed :)

[02:30] j_k9: Ok, the last target we should probably talk about is the Database back-end.

[02:31] j_k9: Neeraj and Shilpa: I know that neither of you intends to work on this right away, so would you like to discuss this now or leave it for a later date?

[02:31] j_k9: I do know that SOCI will help a lot: http://soci.sourceforge.net/

[02:32] neeraj: ok

[02:32] shilpa: I think as it is part of Directory layer we should wait till Alan is here

[02:33] j_k9: Yes, I would agree with that.

[02:33] j_k9: The final topic on the agenda is Mac OS X implementation. I am making some progress with this - Mira Server builds without a hitch, but I've encountered a problem with Mira Client. I'm going to work on fixing this - hopefully I'll be able to get it working, this week!

[02:33] badri: hmm… are we planning for a regular Database… or we are trying to memic a database with the filesystem…

[02:34] badri: ok

[02:34] j_k9: Badri: We're planning to support dedicated DBMSs such as MySQL, Oracle etc

[02:34] badri: got it

[02:34] j_k9: That's for the Directory Database back-end

[02:34] shilpa: Sorry to interrupt but I wil have to go.

[02:34] j_k9: Right, I think we've covered everything on the agenda. Is there anything anyone would like to ask, or propose?

[02:34] j_k9: That's ok - we're wrapping up :)

[02:35] shilpa: Bye everyone.

[02:35] j_k9: Bye Shilpa! Thanks for joining. :)

[02:35] shilpa left the chat room.

[02:36] j_k9: Neeraj, or Badri - does either of you have anything you wish to add which isn't on the agenda?

[02:37] neeraj: nothing more at my end.

[02:37] badri: nothing here as well

[02:38] j_k9: Excellent. In that case, let's call the meeting to a close. Thank you very much for joining! I look forward to speaking to you on Thursday.

[02:38] badri: ok sounds good

[02:38] j_k9: Goodnight!

[02:40] badri: gn