Fair enough. I'll read XEP-0280 more closely and see what I can do. If it works out I'll post it to the Ejabberd list.
Thanks for the tips. dan On Thu, Jan 5, 2012 at 12:55 PM, Matthew Miller <[email protected]>wrote: > 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 <[email protected]> > 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 <[email protected] > >: > > > 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 <[email protected]> > 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" <[email protected]> > > >> 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: [email protected] > > >>> _______________________________________________ > > >>> > > >> > > >> _______________________________________________ > > >> JDev mailing list > > >> Info: http://mail.jabber.org/mailman/listinfo/jdev > > >> Unsubscribe: [email protected] > > >> _______________________________________________ > > >> > > > > > > > > > _______________________________________________ > > > JDev mailing list > > > Info: http://mail.jabber.org/mailman/listinfo/jdev > > > Unsubscribe: [email protected] > > > _______________________________________________ > > > > > _______________________________________________ > > JDev mailing list > > Info: http://mail.jabber.org/mailman/listinfo/jdev > > Unsubscribe: [email protected] > > _______________________________________________ > > > > _______________________________________________ > > JDev mailing list > > Info: http://mail.jabber.org/mailman/listinfo/jdev > > Unsubscribe: [email protected] > > _______________________________________________ > > > _______________________________________________ > JDev mailing list > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: [email protected] > _______________________________________________ > >
_______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
