Chat Application
-
No, I think that's a good idea. If your server talks JSON, you could also use it with native mobile clients. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Agreed. And it should be fairly simple.
If it's not broken, fix it until it is
-
Agreed. And it should be fairly simple.
If it's not broken, fix it until it is
Have you considered using a Jabber server instead of writing one from scratch? /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
I want to create a simple chat app. I would like to host it on my server and allow one-to-many people to chat. I'd like to do it myself as a learning experience. Can anyone point me in the right direction? Thank you
If it's not broken, fix it until it is
Several years ago I wrote one that was just WinForms-to-SQL-Server, then I started working on a WCF service for it (again, it was quite a while ago), but since then it has stagnated. It's something I'd like to finish for an article. Calling it a "chat app" isn't terribly accurate, as it is something between that and a simple e-mail system. It supports message threads (like forum posts here on CP) and delayed delivery for recipient(s) who are offline.
Kevin Marois wrote:
as a learning experience
Should be a good way to learn the communication framework du jour and allow clients to be created for a number of devices.
-
Several years ago I wrote one that was just WinForms-to-SQL-Server, then I started working on a WCF service for it (again, it was quite a while ago), but since then it has stagnated. It's something I'd like to finish for an article. Calling it a "chat app" isn't terribly accurate, as it is something between that and a simple e-mail system. It supports message threads (like forum posts here on CP) and delayed delivery for recipient(s) who are offline.
Kevin Marois wrote:
as a learning experience
Should be a good way to learn the communication framework du jour and allow clients to be created for a number of devices.
I'm thinking I could create a Web API that maintains a list of Conversations. Each Conversation would have a unique Id and a list of Participants. The only problem I see is the API notifying clients that they have a message. I'm guessing a callback of some sort would do the trick.
If it's not broken, fix it until it is
-
I want to create a simple chat app. I would like to host it on my server and allow one-to-many people to chat. I'd like to do it myself as a learning experience. Can anyone point me in the right direction? Thank you
If it's not broken, fix it until it is
SignalRwill be a better component for a chat application. I done a real-time time application with SignalR.. Its very interesting :cool: -
SignalRwill be a better component for a chat application. I done a real-time time application with SignalR.. Its very interesting :cool: -
Kevin Marois wrote:
My usage will NOT be asp.Net
So what language are you going to use?:~
-
Kevin Marois wrote:
My usage will NOT be asp.Net
So what language are you going to use?:~
Language? C# ASP.Net is not a language. It's a Web Development platform
If it's not broken, fix it until it is
-
Language? C# ASP.Net is not a language. It's a Web Development platform
If it's not broken, fix it until it is
my bad.. forgot the forum title :( .. thought about PHP and Java .. apologies
-
I'm thinking I could create a Web API that maintains a list of Conversations. Each Conversation would have a unique Id and a list of Participants. The only problem I see is the API notifying clients that they have a message. I'm guessing a callback of some sort would do the trick.
If it's not broken, fix it until it is
Kevin Marois wrote:
Each Conversation would have a unique Id and a list of Participants.
I put it in a database. Each message has its own ID, the ID of its parent, and the ID of the first message in the thread. Each message also has its own set of recipients (many-to-many relationship between Message and User). The client could then display each message as it arrives, or show the entire thread in a TreeView.
Kevin Marois wrote:
API notifying clients
"Push" sucks; always has, always will. I always use polling; it allows the client/user to control frequency or even disable polling altogether. I also put in a "get messages now" feature. The server should only handle requests as they are made and not try to keep track of all the possible connections or it won't scale well. You probably also don't want to waste cycles re-trying broadcasts to clients that have lost connectivity. If no one is asking for data, don't try to send it; just wait.
-
You know, I'm fairly good with MVC 4 Web Services. Any reason I shouldn't use that?
If it's not broken, fix it until it is
Kevin Marois wrote:
I'm fairly good with MVC 4 Web Services
Then it might be a good opportunity to teach rather than learn. :-D
-
Kevin Marois wrote:
I'm fairly good with MVC 4 Web Services
Then it might be a good opportunity to teach rather than learn. :-D
The part I'm not sure about is getting notifications in the client from the Server. Ever done this?
If it's not broken, fix it until it is
-
The part I'm not sure about is getting notifications in the client from the Server. Ever done this?
If it's not broken, fix it until it is
Details. Details. Don't bother me with details. (I don't even know what MVC 4 is.)
-
Kevin Marois wrote:
Each Conversation would have a unique Id and a list of Participants.
I put it in a database. Each message has its own ID, the ID of its parent, and the ID of the first message in the thread. Each message also has its own set of recipients (many-to-many relationship between Message and User). The client could then display each message as it arrives, or show the entire thread in a TreeView.
Kevin Marois wrote:
API notifying clients
"Push" sucks; always has, always will. I always use polling; it allows the client/user to control frequency or even disable polling altogether. I also put in a "get messages now" feature. The server should only handle requests as they are made and not try to keep track of all the possible connections or it won't scale well. You probably also don't want to waste cycles re-trying broadcasts to clients that have lost connectivity. If no one is asking for data, don't try to send it; just wait.
Ok but with polling the client would have to make queries every 2 or 3 seconds to get close to real time
If it's not broken, fix it until it is
-
Ok but with polling the client would have to make queries every 2 or 3 seconds to get close to real time
If it's not broken, fix it until it is
Yes, only as frequently as the user wants.