Re: [jdev] SoC idea: providing multiplexing support
I've been asking for the same feature a few years ago. Thing is, if i use jabber client on some other PC than my desktop, logs are saved there, not on my desktop (where i need them to be). This is a separate issue I think. This is indeed a server-side history request, and is something wanted by many people (including me). The original poster's idea sounds like a client with a 'sync' mode, behaving like this: - Every incoming message is forwarded to all other resources that are in 'sync' mode. The messages use AMP, like in the remote controlling xep. - For every gui change, an iq is sent with a GUI command, e.g. iq type=set to=[EMAIL PROTECTED]/otherresource ui-action type=open-chat target=[EMAIL PROTECTED]/ /iq - When a client goes into 'sync' mode, it requests the initial state from one of the other resources One should probably even use private PEP for the gui sync part, instead of just sending iqs to every resource separately. If the commands are basic (like 'open chat'), then both implementation and conflict resolution sounds easy enough. cheers, Remko
Re: [jdev] SoC idea: providing multiplexing support
mm, agreed. Server-side history with some minor sync iq's would be all that is required. I'm not sure I'd want to be able to open and close conversations remotely. Perhaps a window that shows 'current remote conversations' that you can pick from to continue them. On Wed, Mar 19, 2008 at 11:15 AM, Remko Tronçon [EMAIL PROTECTED] wrote: I've been asking for the same feature a few years ago. Thing is, if i use jabber client on some other PC than my desktop, logs are saved there, not on my desktop (where i need them to be). This is a separate issue I think. This is indeed a server-side history request, and is something wanted by many people (including me). The original poster's idea sounds like a client with a 'sync' mode, behaving like this: - Every incoming message is forwarded to all other resources that are in 'sync' mode. The messages use AMP, like in the remote controlling xep. - For every gui change, an iq is sent with a GUI command, e.g. iq type=set to=[EMAIL PROTECTED]/otherresource ui-action type=open-chat target=[EMAIL PROTECTED]/ /iq - When a client goes into 'sync' mode, it requests the initial state from one of the other resources One should probably even use private PEP for the gui sync part, instead of just sending iqs to every resource separately. If the commands are basic (like 'open chat'), then both implementation and conflict resolution sounds easy enough. cheers, Remko -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
[jdev] SoC idea: providing multiplexing support
Hi all, I have been playing with the idea of using Jabber as a multiplexing instant messaging client for a little while now, and would like to know what others think. By multiplexing I mean that a user could be logged in to the same account from several locations at once (a separate client would be running at each), with messages that are sent or delivered appearing at all of the locations. The user would have the option of preserving state across the various connected clients, so that closing a conversation window on one would close it on the others, opening a new conversation window would open it everywhere else, etc. The idea is that the user can continue his current conversations while moving across computers, and can login to transports that only support one login location at a time (e.g. MSN) from multiple computers at once. Several uses for this come to mind. The above description may be confusing, so I'll give a usage example. A user has a jabber client running on his desktop and is logged into an account with several transports, so that jabber may be used to contact AIM/MSN/other contacts. The user leaves his desktop and boots up his laptop at a different location. He launches a jabber client on the laptop and logs in. If he has decided to preserve state across connections, any conversation windows that were open on his desktop will be opened on his laptop and populated with a portion of the conversation. The user says something in a conversation window that was open on the desktop. What the user says, and anything the contact he is chatting with says, appear in the conversation windows on both the desktop and laptop. The user can move between laptop and desktop freely, and anyone he is talking with will not notice. As far as implementation, a protocol extension would be needed to preserve state and to make messages show up in all the required conversation windows. Also, a proxy sitting between clients and jabberd would need to be created, or an existing jabberd modified. Clients would obviously need to be modified as well to support the protocol extension. I love this idea and would find it extremely useful, but I am well aware that I may be the only one. What does everyone else think? I'm considering using this idea on my SoC application, so any input would be greatly appreciated. Thanks, Andrew
Re: [jdev] SoC idea: providing multiplexing support
On 2008-03-19 01:23, Andrew Yates wrote: I have been playing with the idea of using Jabber as a multiplexing instant messaging client for a little while now, and would like to know what others think. By multiplexing I mean that a user could be logged in to the same account from several locations at once (a separate client would be running at each), with messages that are sent or delivered appearing at all of the locations. [snip] I love this idea and would find it extremely useful, but I am well aware that I may be the only one. What does everyone else think? I'm considering using this idea on my SoC application, so any input would be greatly appreciated. I think you can accomplish this already using RDP, VNC, or screen. -- Jefferson Ogata [EMAIL PROTECTED] NOAA Computer Incident Response Team (N-CIRT) [EMAIL PROTECTED] Never try to retrieve anything from a bear.--National Park Service
Re: [jdev] SoC idea: providing multiplexing support
I think you can accomplish this already using RDP, VNC, or screen. I realize something like this is possible with VNC/NX/RDP/screen (which I do use for irc, email, and other applications), but I don't find those as convenient for Jabber. This may have something to do with my usage patterns, but it is also because I prefer a GUI for instant messaging and VNC/NX/RDP don't quite cut it for me. Of course, others may disagree as you did, which is why I am inquiring before jumping into anything. Thanks for your input :-)
