If you're going to modify the server, why not implement XEP-0280? There are some minor changes that will be happening within the next few days (see standards@ for a discussion on what might change), but don't let that stop you!
- m&m <http://goo.gl/LK55L> On Jan 5, 2012, at 10:51, Daniel Dormont wrote: > I see ... you're suggesting I add logic on the server side to echo the packet > without modification. Interesting idea. I can try to write something for > that. It might not be all that hard, actually. > > dan > > On Thu, Jan 5, 2012 at 12:44 PM, Alexey Nezhdanov <snak...@gmail.com> wrote: > Ok, let me be more verbose: > > user1/resource1 sends the message: > <message to='user2' type='chat'><body>blah</body></body></message> > > user1/resource2 gets the notification: > <message to='user2' type='chat'><body>blah</body></body></message> > You do not need to look for differences b/w these two - they are > identical. Or, to be a bit more proactive, you can actually add a > 'from' field - i.e. send message to second resource not 'as it was > received [from user1]' but 'as it was sent [to user2]'. > > You are stumbled upon the false idea that recipient MUST see his > address in the 'to' field. He needs that not, check how email (Cc:) > works. > > On the other hand, if there is already XEP for this exact purpose, you > probably much better off following it - it will provide compartibility > with future clients, you will be among first adopters and your > client/server will be used as a reference implementation. > > > Am 5. Januar 2012 19:56 schrieb Daniel Dormont <d...@greywallsoftware.com>: > > Hmmm...I'm not seeing how that would work. Suppose user1@mydomain/resource1a > > sends > > > > <message type="chat" to="user2@mydomain"><body>hello user2</body></message> > > > > Now, in order to make sure user1@mydomain/resource1b also sees the message, > > the original sender sends what? I was thinking something along the lines of: > > > > <message type="echo" to="user1@mydomain"><body>hello > > user2</body><original-recipient>user2@mydomain</original-recipient></message> > > > > Without that extra element, how's user1@mydomain/resource1b supposed to know > > who they're chatting with? > > > > Dan > > > > PS I just also discovered XEP-0033. I will see if I can use that. Ejabberd > > definitely does not support XEP-0280. > > > > On Thu, Jan 5, 2012 at 8:59 AM, Alexey Nezhdanov <snak...@gmail.com> wrote: > >> > >> Just send stanza as is, no? > >> You don't need any custom elements, all data is already there. > >> > >> On Jan 5, 2012 12:00 AM, "Daniel Dormont" <d...@greywallsoftware.com> > >> wrote: > >>> > >>> Hi XMPP-ers, > >>> > >>> I've noticed that certain clients (Gmail's web interface most notably) > >>> automatically replicate my chat conversations in all windows I have open. > >>> I'm wondering how to implement something similar using an XMPP client and > >>> server. I control both client and server but don't want to make too many > >>> custom modifications if I can help it. As a first step, the easiest thing > >>> seems to be to send all messages to a bare JID rather than full JID. From > >>> the user's standpoint this correctly causes all messages they receive to > >>> appear everywhere. > >>> > >>> But what about sent messages? Is there a simple way to have messages I > >>> (as a user) send echoed back to my other connected resources? Or should I > >>> just send a second message to my own bare JID with some sort of custom > >>> element that indicates it was really a message to someone else (and who > >>> that > >>> someone else is)? > >>> > >>> thanks, > >>> Dan > >>> > >>> _______________________________________________ > >>> JDev mailing list > >>> Info: http://mail.jabber.org/mailman/listinfo/jdev > >>> Unsubscribe: jdev-unsubscr...@jabber.org > >>> _______________________________________________ > >>> > >> > >> _______________________________________________ > >> JDev mailing list > >> Info: http://mail.jabber.org/mailman/listinfo/jdev > >> Unsubscribe: jdev-unsubscr...@jabber.org > >> _______________________________________________ > >> > > > > > > _______________________________________________ > > JDev mailing list > > Info: http://mail.jabber.org/mailman/listinfo/jdev > > Unsubscribe: jdev-unsubscr...@jabber.org > > _______________________________________________ > > > _______________________________________________ > JDev mailing list > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: jdev-unsubscr...@jabber.org > _______________________________________________ > > _______________________________________________ > JDev mailing list > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: jdev-unsubscr...@jabber.org > _______________________________________________
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org _______________________________________________
