Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Aza Noriega
    @MegaGM
    Hello world?
    Jonathan Gros-Dubois
    @jondubois
    Hi!
    Aza Noriega
    @MegaGM
    Is it possible to show all users that are in one channel right now without workarounds?
    Or should I implement the workaround that I wrote in the comment https://github.com/TopCloud/socketcluster/issues/44#issuecomment-73103946 ?
    Aza Noriega
    @MegaGM
    @jondubois Do you have planned to make an implementation of channel entity on the server side? Is is possible at all in that way I wrote there TopCloud/socketcluster#48 ?
    Jonathan Gros-Dubois
    @jondubois
    @MegaGM Right now, SC doesn't offer any way to get channel metadata such as number of users subscribed to a particular channel - You have to create a new channel and publish the count metadata to it! So for example, if you had a channel called 'cats' and you wanted your users to know about how many other users are subscribed to the 'cats' channel, you would have to create a new channel 'cats_subscriber_count' (example) and whenever a user subscribes to the cat channel, you will have to keep track of the subscriber count (stored in a database or using the scServer.global store) and publish the number to that channel.
    Jonathan Gros-Dubois
    @jondubois
    Right now, SC doesn't know about 'users', it only knows about sockets -- It might be nice for SC to know about users, but then that means we'll have to add a whole user management layer on top of SC... We'll have to build an API to create/read/update/delete accounts and then we'll have to choose a specific database engine to store all that user data in a persistent way - What if the developer/company who uses SC wants to use MySQL, Cassandra or CouchDB instead of the default MongoDB? We don't want to dictate how developers should store their data. We want the developer to choose the database engine that is most suitable for their specific needs. It's a VERY interesting question though, and I will be thinking about it really hard -- Is there a nice flexible way to offer this user management feature without forcing the developer to use particular database engines? Maybe we could write adaptors for a number of different (popular) database engines and the user can choose the one they want (or write their own) - So SC could interact with any underlying database (through the same interface)...
    Also, should this be the responsibility of SC itself? or maybe we should create a brand new project on top of SC which adds these user-oriented features?
    Jonathan Gros-Dubois
    @jondubois
    @MegaGM Regarding server-side channel entities, right now, you CAN subscribe to channels from the server side using the global object: http://socketcluster.io/#!/docs/api-global, but unlike the client, the subscribe() method doesn't return a channel object/entity. I really want to add this feature to SC though, so yes, it's coming soon!
    Jonathan Gros-Dubois
    @jondubois
    Thanks for asking these tough questions though. My goal for SC is that it has to be useful and convenient but also flexible enough to work alongside any other technology (not monolithic). Modularity is really important - I want SC to work seamlessly with other tools.
    Also, if you (or anyone else) has an opinion on the direction of SC, I am interested in hearing it.
    Jonathan Gros-Dubois
    @jondubois
    I thought of a simple way to identify users within SC without having to get databases involved - We can allow developers to set a special identity token on both the client-side and server-side of each socket (it will show up as a cookie on the client and an object on the server) - The token will tell us which user owns what socket (it will also be used to automatically authenticate the user in case of reconnect) - The developer will be responsible for setting these tokens through a simple API, it won't matter which database the data comes from - The token could contain the username, a salted hash of the user's password (for authenticating), a creation timestamp and any other additional custom info which the developer wants to associate with each user.
    EDIT the developer will be responsible for setting and also checking these tokens. API will be provided for doing this easily.
    Aza Noriega
    @MegaGM

    channel object/entity. I really want to add this feature to SC though, so yes, it's coming soon!

    Yiay ^_^ I'm happy to hear it!

    you would have to create a new channel 'cats_subscriber_count'

    Nice idea, thanks!

    It might be nice for SC to know about users

    I really thought it is in SC1 and it's called socket sessions :D

    Jonathan Gros-Dubois
    @jondubois
    Sessions kind of solve that problem. But a session is just a bunch of sockets open in the same browser. The new problem that I've been thinking about is; what if you have a separate database that contains details about all your users - How can you efficiently
    associated these users (from the database) with the sessions without having to keep track of sessions IDs
    Jonathan Gros-Dubois
    @jondubois
    Basically keeping track of the relationships between user accounts and session IDs (which get created and destroyed relatively often) is difficult. An authentication token-based approach will make this easier. Basically the idea is that a client socket will be able to login to your system using SC (maybe through a 'login' event) and if successful, you can tell SC to set a token containing the username of that user (as a cookie). Then if the user opens another tab in the browser and tries to subscribe to a channel, the server will see the auth token containing the username and so SC will know exactly WHO that socket belongs to. You will also be able to set tokens with a fixed expiry date so that the user can close their browser and go back to the site and SC will automatically recognize them based on the token. The token will be signed by SC so that the client cannot change it and put someone else's username for example without invalidating the token.
    Jonathan Gros-Dubois
    @jondubois
    I guess with sessions, you can use something like socket.session.set('username', 'john345') to keep track of which user a session belongs to, but I'm trying to move away from sessions with V2 because they are inefficient, difficult to maintain (add complexity to SC source code) and there are easier ways to achieve the same effect. Also a token-based approach has some scalability advantages.
    It's really hard to explain this. I will post examples when I'm done. I am very close to a final design.
    Aza Noriega
    @MegaGM

    server will see the auth token containing the username and so SC will know exactly WHO that socket belongs to

    Super! It's exactly that, what I had used socket.sessions for.

    It's really hard to explain this.

    Maybe, but for me personally the concept is completely understandable. However I've got some questions, like "Whether will we have to force to reload all opened tabs if at the moment when an authentication has performed, there was some other tabs opened already?"

    Jonathan Gros-Dubois
    @jondubois
    No it won't force a reload but the token will accessible in all tabs. The server will be able to publish a message to the user's channel to tell all tabs which belong to that user that they are now logged in and the client-side can decide for itself how to deal with that.
    Aza Noriega
    @MegaGM
    Naruhodo, it makes sense
    Aza Noriega
    @MegaGM
    Will be server-side channel-entities exist in SC1?
    Jonathan Gros-Dubois
    @jondubois
    Yes :)
    Aza Noriega
    @MegaGM
    @all I cannot understand why, WHY SocketCluster is not so popular so far??
    Jonathan Gros-Dubois
    @jondubois
    @MegaGM I think part of the reason is that SocketCluster (launched in September 2013 on GitHub) is much younger than alternatives like Socket.io (started in May 2011 on GitHub). The fact that our community is so small is part of the problem. That said, I'm pushing hard on documentation and traffic to the website is growing nicely (particularly search traffic - Where it looks like it's accelerating). Website is now getting a pretty consistent 100 visitors per day during working days so it's not too bad - The site was only launched in August last year so you have to give it time :)
    Jonathan Gros-Dubois
    @jondubois
    The advantage of not being popular though is that we were able to adapt to trends/new concepts really quickly without upsetting too many users so that has been really great. SC2 would never have happened if SC was very popular and we had to support tens of thousands of legacy apps.
    sachin shinde
    @sacOO7
    Hi
    sachin shinde
    @sacOO7
    Hi again :smile:
    sachin shinde
    @sacOO7
    Hey everyone