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