Re: insite messaging system input?
Michael Wiencek <[email protected]> Wed, 25 Mar 2015 14:51:27 -0500
| Newsgroups | gmane.comp.audio.musicbrainz.devel |
|---|---|
| Message-ID | <CAEV5jn3GiJgP1xDvarONUirCZgBG7t+g55bb+3Uh9g0fAg2e8Q@mail.gmail.com> |
On Wed, Mar 25, 2015 at 9:59 AM, inapis <[email protected]> wrote: > bitmap or ianmcorvidae: After some discussion with kuno and freso, I am > interested in implementing the insite messaging/notification system. > > I previously developed a in-app backend messaging/notification system for a > startup (called Clicle) in node.js. > > I have come to an understanding that XMPP is not high on priority list . And > from what the community envisions is a messaging system similar to what is > seen in different web forums. I developed the previous system using the std > combo of node.js+socket.io. > > Probably a overkill for this project if we don't need a lot of real time > capabilities but nevertheless the node.js+socket.io stack wins anytime over > other stacks because of the speed of development and easy maintainability. > It's std java script. > > Is it okay if I implement the system in node.js + socket.io? Previous > experience would help me tremendously in avoiding a lot of pitfalls thus > producing a higher quality system If it works well and is easy to deploy, I'd be okay with it. I think the wider community would prefer Python, though. > Also I have been looking through the source code. It's definitely doable in > node.js with plugging into the perl parts totally possible. There are > existing modules for node.js which can bind with perl methods but they are > slightly outdated. I'll have to hack on that if something ends up being > incomplete. Adds a little bit more work but not that will kill the project. Shouldn't it be the other way around? The perl should initiate communication, and the messaging system shouldn't care what's communicating with it. Binding to perl methods from node.js sounds wrong and icky. :) I'm curious to hear how you'd persistently store messages between editors, since those are currently email-only. Obviously if the server crashes, messages shouldn't be lost before they're read/deleted. Edit notes on the other hand are already stored in the main database, so it'd also be good to understand how those fit into the new system. Michael