can i get sample code to use kolab web admin API ? I am trying it shows invalid session . Authentication is working fine. rather than authentication no api is working fine.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

This ticket is no longer relevant.

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

implemented in the feature/room_perms branch

implemented in the feature/room_perms branch

implemented in the feature/room_perms branch

This is now implemented in the feature/room_perms branch

This is now working, minus authentication and persistence. I will create new tasks for this.

I have started a feature branch in feature/room_metadata

If I'm understanding you correctly, this is really about persistence: dealing with disconnections / reconnections etc. how do we manage notifications, invitations, permissions, etc.

@seigo, I started working on a 1:1 chat. Creating and using a chat is simple. Problem is with invitations/notifications. I suppose we'd need some kind of event system. Consider scenario:

1. UserA first time wants to talk with UserB
2. UserB is notified about "incoming chat". He joins the conversation.
3. UserB disconnects, closes the chat window. Then connects again.
4. UserA want's still to talk with UserB again.

Amnesia is quite nice, and makes using mnesia rather more bearable from Elixir. Let's try it!

I have commented on D363 ... :)

@seigo, what do you think about use of https://github.com/meh/amnesia ?

See D363. Still I prefer to use system channel for presence operations. Additionally implemented "client context". Still does not implement status persistence.

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 :)

We already use Phoenix.Token for user authentication tokens. But I don't understand for what you propose to use it. User metadata? I suppose not for anything else?

Looking ...

remembered Phoenix.Token just now -> https://hexdocs.pm/phoenix/Phoenix.Token.html

@seigo, I'm having trouble with this. Would you mind taking a look? I thought it will be a simple change in system_channel.ex, but I can't make it working.

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

+1

We already use (authenticated) system channel for that and I think it should/can be used still. I just wasn't sure channel about data persistence or channel data size limitations. So, it looks that if we use the system channel all we need is to properly handle user joins to the channel. I'll go this route for now.

@seigo, I'm not sure we can do it without SQL, how about invitations? I'm thinking of a case of "I'm logging in, give me all pending invitations". I don't think we can store invitations inside a chat. I'm used to use relational databases and can't imagine how to use key/value store here.

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.