Re: insite messaging system input?

On Wed, Mar 25, 2015 at 02:51:27PM -0500, Michael Wiencek wrote:
> 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.
> >

It does seem like pretty serious overkill. My past thoughts about this
have trended more toward installing Dovecot somewhere and writing it as
an IMAP client in the site (which isn't really a good idea, because it'd
be a bit weird for edit notes, which would (I guess) require a mailbox
per edit -- so don't go down that road exactly!), or just storing the
messages in the DB like we do with edit notes, and render them out that
way.

As bitmap mentions below, this would be a persistent messaging system
(until messages are deleted, or such); edit notes I think it'd be fine
to essentially copy into the system, since those have slightly different
requirements (can't be deleted, end up in data dumps, etc.). It's not
really intended to be a realtime messaging system -- of course, if we
can move it that way it's not necessarily a bad thing -- but it's
certainly the top priority.

> > 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.
>

If it needs to be a separate system then python's probably the usual
tool of choice, though there's an argument for it just being directly
integrated with the perl code as well, and I don't think the leaning
toward python is anything more than a leaning. The usual tradeoffs
apply, we can be more flexible with deployment for a separate system but
the task of integration and the task of deployment are both larger.

> > 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 agree. My assumption would be that the perl code would post messages
either to an AMQP queue, over HTTP, or some other
inter-process/inter-server communication system to the messaging system,
which would subsequently not care, and provide a way for the perl to
fetch messages from it (via HTTP or some other
inter-process/inter-server system). The messaging system shouldn't need
access to authentication-type information, for example, that you
mentioned in IRC.

But, of course, perhaps we're misunderstanding your proposal and what
you're saying is a better idea.

> 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.
>

Another thing to mention here is that we don't want email to go away --
users who want to get emails should still be able to have this new
messaging system send them emails. Minor point but probably one worth
mentioning!

In general I think you have some good ideas, but I'm not entirely sure
if your ideas are for the system we want or something else (e.g. a
realtime/"chat" system, more than a messaging system); I'd like to hear
a more detailed proposal, I think. Remember that to be properly
considered for summer of code a proposal needs to be submitted to the
Melange site by the 27th, but it is possible for proposals to be marked
editable there as well, if more work is needed. So don't hesitate to
apply there as well if that's your goal.

I see that our application template is currently empty, which is
presumably an oversight on Rob's part; we usually ask for basic
information like github/bitbucket profiles as well as a list of MBIDs
for music you like (since after all, we're a music metadata site!).

> Michael
>
> _______________________________________________
> MusicBrainz-devel mailing list
> [email protected]
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

_______________________________________________
MusicBrainz-devel mailing list
[email protected]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlUTXPwACgkQq+0avXExp2+cogCgngFxDTN+nhkHbpaA975zYUND
LT0AniIhpwQUakHqY2hNszFiLqLQ8yUR
=5l1P
-----END PGP SIGNATURE-----