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
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Mira-development mailing list
Mira-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mira-development