User Details
- User Since
- Apr 12 2015, 12:47 PM (508 w, 6 d)
- Roles
- Disabled
May 31 2017
.. the server side should come for free in the form of presence diffs once Presence.track'ing is added to RoomChannel. Then it will just be the client-side display that is left.
After talking today with Alek, we'll move to a SPA directly after notifications and room metadata (the current topics we are working on) which will make this a moot point. So closing.
have implemented leave and terminate functions in RoomChannel, but am now blocked by Alek's feature branch which also introduces an :after_join handler where Presence.track'ing can be placed.
Looking really good already.. :)
implemented in the feature/room_perms branch
implemented in the feature/room_perms branch
implemented in the feature/room_perms branch
May 29 2017
This is now implemented in the feature/room_perms branch
May 24 2017
No, K16 is enough
The issue with emails is a user-confusion issue: you get an email with an attachment, you save that attachment "to the cloud", and now the time is oddly different than the email. So it isn't that there is a bug with emails, but that the time differences cause problems for users.
I have pushed a commit to the feature/autodetect_ipv6 branch which turns on keepalive for the socket; there is a corresponding fix on the eimap (imap server connection code) side as well, though I'm not sure that is needed. Hopefully that will resolve the issue as it will try to keep the socket up as long as the other side is still there according to the OS settings for these timeouts. by default on Linux it is 2 hours, which should be plenty.
This is now working, minus authentication and persistence. I will create new tasks for this.
May 23 2017
I have started a feature branch in feature/room_metadata
Apr 18 2017
Apr 8 2017
Mar 21 2017
Tested and approved! Thanks, Christian, for catching this refactor booboo.
Mar 20 2017
Is this with no ruleset in the config for a particular connection? Or when you connect with a client claiming to be /Kolab in the ident, or? Let's look at your guam config / setup when we are together next
Feb 7 2017
Ah .. the differential associated with this is closed, but (for whatever reason?) phabricator was showing this item as still open/active, which i did not expect. sorry for the noise. :)
Feb 6 2017
So same issue, with slightly different results: multiple commands sent together, which is allowed by the IMAP spec indeed, and then the client ends up waiting for responses that do not come as expected. Thanks for the report.
This is already pushed into develop, no?
Feb 3 2017
If I'm understanding you correctly, this is really about persistence: dealing with disconnections / reconnections etc. how do we manage notifications, invitations, permissions, etc.
Jan 20 2017
Those require statements look fine IMHO. Yes, it's a bit more verbose that one could imagine if it were placed somewhere central, but at least this way it is explicit: this code requires that API .. and so it says so right there. That kind of clarity makes that extra line worth it ... +1 from me.
Jan 18 2017
Amnesia is quite nice, and makes using mnesia rather more bearable from Elixir. Let's try it!
last status persistence.
I have commented on D363 ... :)
Perhaps I'm missing something, but this simply shows the effective status of the user in the UserStatusWidget on the client, so if I have two connections in the same context with statuses as:
Jan 17 2017
Jan 16 2017
One small comment above. Otherwise looks good. Will you merge the changes in my branch into this and push it all together into develop? I would +1 that.
Jan 13 2017
Jan 11 2017
Sorry, I skipped some details. I was thinking about invitations in specific, and how we could use a Phoenix.Token as part of the invitation metadata to make authorizing the invitation when it is used easy/simpler. I may have actually put this in the wrong ticket even. Indeed, this belonged on T2118 *sigh*.
Ah, one other "little" issue .. in the listBy() javascript function there is this:
Ok, so FINALLY got time to look at this this afternoon :)
Looking ...
Jan 10 2017
remembered Phoenix.Token just now -> https://hexdocs.pm/phoenix/Phoenix.Token.html
.. oh, and if we really need/want to, we can always migrate to a full SQL RDBMS in future. The storage/lookup code is not really so big. The reason for choosing mnesia in this use case if because it is largely ephemeral data, speed is nice, and fewer dependencies / setup routines is never a bad thing.
Key/value store should be enough for that. Mnesia (which comes with Elixir/Erlang) uses a tuple as the definition for a table, with an implicit primary key, you can index and search on any field in the tuple. So it is very much like an SQL database in that it has tables, primary keys and optional secondary keys. But it is built into the language and runtime itself, supports RAM-only and on-disk storage as well as clustering if desired. It's a very nice tool to use for "lightweight" database needs (e.g. I wouldn't necessarily try and map a dozen tables with complex relations / refint requirements, or a dataset that was expected to grow to dozens or more GB and require long term storage), as it is easy to use, fast, well integrated and means one less dependency.
Jan 9 2017
The common set seems to be:
This should be modeled so that we can reasonably expect to bridge XMPP to it, and perhaps even matrix.org federation.
I thin it would be very nice and interesting to see if we can run the chat functionality without a database connection at all. The authentication mechanism could be responsible for retrieving the username to show for a given login (defaulting to the login itself) along with "nice things" like the user's image to show, etc. This way, when we go to integrate with the larger Kolab stack, that user information does not need to be synchronized also to the chat database. Wherever they auth against would also give the chat service the user's metadata like username, picture, organization, location info, etc. This has obvious overlap with the user's addressbooks and identities; amazing would be allow the user to select from their identities as configured in Roundcube ... we can get their later, but should keep that kind of integration in mind now. Mostly so we don't end up duplicating that in the chat service directly.
Remember the user status in database and don't reset it on logon nor any other operation, except system/set-status
Jan 3 2017
Dec 14 2016
Ah, yes, phoenix presence handles their status entirely. We need to do nothing for that (and should not .. it's a complicated thing, and they have implemented it fully).
This will be used to store user auth tokens, e.g. to validate sessions? If so, should this use Phoenix.Token instead (https://hexdocs.pm/phoenix/Phoenix.Token.html)? Auth will be served by Kolab (e.g. LDAP), and presence managed by Pheonix Presence .... ?