Hi all, Tonight's meeting was attended by Adam, Alan, Tijoy and myself. You can find a transcript of the meeting here: http://miragroupware.org/wiki/doku.php/development/communication/archives/101216_message_center
I shall address the topics in the order in which they were discussed. Please use this mailing list thread to discuss these topics: many of the issues raised in the meeting were still not decided at the end of it, so this is the place to debate them before our next meeting. For the Message Center, do we implement a custom messaging system or use a "standard" backend? Adam said that this depends on what we want to do. For example, if we want to be able to send emails to other systems, we should use the "standard" SMTP/Exchange with IMAP/POP3/Exchange. Alternatively, if we do not want this functionality, it is easier to keep the messaging system contained and build it ourselves. I said that our aim is not to replace the user's email client; so we should start with a contained system. We want to support rich text and attachments, but we do not want to interact with alternative systems. The best option, which was agreed on, is to implement our own custom messaging system with a "framework" approach so that, in the future, if we wish to support the other "standard" backends, we can extend the framework to support them. What to use for network message structure and content (including serialization)? A few options were suggested: Adam said that using XML might make it easier to validate messages. It is easier to understand and debug. Tijoy proposed JSON as an option because of its benefits in low-bandwidth scenarios. Alan said that we might need something more verbose than JSON for a mailing system of this kind. If bandwidth is a concern, Adam suggested we look in to using protocol buffers, such as Google Protocol Buffers, for a very efficient data serialization format. Tijoy added that, if we use protocol buffers, we don't have to worry about object→XML/JSON and XML/JSON→object conversion because the protocol buffer generates the stubs itself. However, he also expressed a concern that protocol buffers would give us more than we need, e.g. different langage bindings (we don't use Java or Python). Adam has used a message passing broker system in the past: QPID (an AMQP broker), with Qt. He found that it served all his requirements. It was suggested that if Adam started to work on the Message Center, Tijoy could then join in once he is more familiar with Mira's code. The tasks for this feature could then be divided accordingly. Alan raised the point that the Network layer is not binary-friendly, in that every "\r\n" or "\n" is treated as the beginning of a new message. In order to support the Message Center, the Network layer will have to be modified to support binary data. As Alan wrote the existing Network layer code, he suggested that the three of them could work on restructuring this Layer together, at least at the beginning, to upgrade it in line with the requirements of the Message Center. The existing network messages that we use could be "upgraded" for compatibility with the new network system with little difficulty. Adam said that we could encode their information with any of the proposed data serialization methods. Alan said that our existing messages can easily be adapted to the way messages are defined in protocol buffers. Adam proposed that one field within the network message could be designated as the message type. That message type would then allow the code to interpret the rest of the fields appropriately. Adam is going to prepare some code examples and submit them to the group for discussion. I asked him to publish them to a personal branch on Launchpad. He says he might be able to do some of it this weekend. At the end of the meeting, Tijoy said that we should consider using HTTP, because TCP on a non-standard port (as we currently use) is often blocked in an enterprise environment. A problem put forward by Adam is that it might conflict with normal web traffic. Discuss. :) 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
