From dev at coherence-project.org Sun Jan 3 13:27:36 2010 From: dev at coherence-project.org (Frank Scholz) Date: Sun, 03 Jan 2010 20:27:36 +0100 Subject: [jdev] Mirabeau/Coherence talk proposal for FOSDEM Dev Room Message-ID: <4B40EFA8.8050104@coherence-project.org> Hi, my name is Frank Scholz and I'm the founder and lead-developer of Coherence. Together with Philippe Normand, who works on Mirabeau, I would like to propose a talk for the XMPP FOSDEM dev room. Mirabeau - creating personal media networks and bridging UPnP devices over the Internet ---------------------------------------------------------------------- DLNA/UPnP devices - consoles, set-top boxes, TVs - finally enter our living rooms and allow an easy access of our digital media. But the UPnP A/V specification has been designed for local networks only - preventing media sharing over network borders. With the UPnP framework Coherence and the Jabber/XMPP infrastructure we are able to overcome these obstacles. This greatly simplifies the realization of the "access everywhere" concept and the implementation of "family and friends" networks. Not only between some software with a dedicated library, but also by transparently integrating ordinary Consumer Electronics devices. Parents can use there DLNA-enabled TV in their home to look at their kids photos on the NAS there, or one can access his audio-collection with the laptop from everywhere, or just with the PS3 at a party at some friends place. With new hardware showing up, like the PlugComputer, we even have an ideal platform for this task, which e.g. could be given pre-configured away to other family members. Beside the bridging a device like that can act of course as an UPnP MediaServer too, and be an UPnP MediaHub to online-content like Flickr, YouTube, Picasa, Miro, BBC,... Now with all necessary parts in place - viz. in the Debian/Ubuntu/Fedora/... repositories, a simple package install, the naming of an Jabber server and a chat room there is all that's needed to create a personal media network. Technically this is realized by enabling the sharing of UPnP devices, like an UPnP MediaServer, with members of ones roster. The communication to and from these devices is done via 'messages' in a MUC, where each Coherence/Mirabeau instance appears as a chat user. The actual media-transfer is at the moment done out-of-band, to not strain the servers excessively. Coherence is an Open-Source DLNA/UPnP framework, -> http://coherence-project.org with the emphasis on being easily extended - resulting in a community driven, constantly growing list of plugins. -> http://coherence-project.org/wiki/MediaServer Mirabeau was first presented on the 2nd Open-Source DLNA summit in 2008 -> http://coherence-project.org/download/coherence-jabber.pdf and demonstrated during Gnome/KDE conference in 2009 -> http://coherence-project.org/download/mirabeau-guadec-2009.odp http://netzflocken.de/2009/6/30/pont-mirabeau-an-upnp-bridge http://base-art.net/Articles/108/ http://www.plugcomputer.org/ Regards, Frank From lucas at lucas-nussbaum.net Sun Jan 3 16:52:31 2010 From: lucas at lucas-nussbaum.net (Lucas Nussbaum) Date: Sun, 3 Jan 2010 23:52:31 +0100 Subject: [jdev] Java XMPP library with jingle support? Message-ID: <20100103225231.GA20001@xanadu.blop.info> Hi, Is there a Java XMPP library with Jingle support? I've tried Smack, but its Jingle support seems to be half-working. For example, it is still using the urn:xmpp:tmp:jingle namespace, and isn't interoperable with pidgin. Alternatively, does someone know Jabber clients running on Linux that interoperate with Smack's version of Jingle? Thanks -- | Lucas Nussbaum | lucas at lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas at nussbaum.fr GPG: 1024D/023B3F4F | From tomek at xiaoka.com Tue Jan 5 04:02:42 2010 From: tomek at xiaoka.com (Tomasz Sterna) Date: Tue, 05 Jan 2010 11:02:42 +0100 Subject: [jdev] RFC 3921 message to RFC 5322 message conversion Message-ID: <1262685762.4709.60.camel@smoku-desktop> Hello. I am working on accessing jabber message archive with IMAP and a normal MUA with IMAP backend. This begs a question: How do I convert RFC 3921 message, to RFC 5322 message to store in IMAP store. (But it may also be useful for Jabber/E-Mail gateway.) 1. How do i store 'from' and 'to' fields of the XMPP message? RFC 5322 defines From: as mailbox-list and To: as address-list which in turn reduces to addr-spec which does not include schema and is assumed to be in SMTP domain. ":" is used to delimiter group names so we cannot use XMPP URI there. - Should I add X- header for preserving XMPP 'from' field? What exact? - Should I fill From: and To: fields to maka maile readers usable? 2. Subject: header is straightforward 3. converts directly to References: - what if there is no ? Should I supplement it? How? 4. Should I generate Message-ID header? If so, how? Maybe it would be useful to base it on some of the message characteristics? -- Tomasz Sterna Xiaoka.com From da-jdev at weeno.net Tue Jan 5 05:55:57 2010 From: da-jdev at weeno.net (David Ammouial) Date: Tue, 5 Jan 2010 05:55:57 -0600 Subject: [jdev] RFC 3921 message to RFC 5322 message conversion In-Reply-To: <1262685762.4709.60.camel@smoku-desktop> References: <1262685762.4709.60.camel@smoku-desktop> Message-ID: <20100105055557.38060d81@doch.oaxaca-dome.net> Tue, 05 Jan 2010 11:02:42 +0100, Tomasz: > 1. How do i store 'from' and 'to' fields of the XMPP message? > RFC 5322 defines From: as mailbox-list and To: as address-list which > in turn reduces to addr-spec which does not include schema and is > assumed to be in SMTP domain. If there is no way to contact the sender of the message via SMTP (or to refer to the recipient), I think you should either leave the field empty (which I'm not sure is legal), or forge an address. Some solutions that come to mind are: A. converting the sender JID to an SMTP address at a Jabber-to-SMTP gateway of your choice. IMHO, it's obviously the best solution, if technically possible. B. using the mail address of the person responsible for the IMAP store. C. using a clearly invalid address. For solutions B. and C., you should maybe put the sender JID in the realname part of the address, in order to compensate the loss of information. > ":" is used to delimiter group names so > we cannot use XMPP URI there. Indeed, I don't think any URI is really easy to use in those fields. > - Should I add X- header for preserving XMPP 'from' field? What exact? What about the Jabber-ID header? If I understood it correctly, it seems to be exactly its role: indicating a way to contact the sender of an email via XMPP. > - Should I fill From: and To: fields to maka maile readers usable? I would say: if and only if you have any pertinent information to give them, yes. If you don't have any for the To: field, I think you should drop it. After all, whenever one receives an email and they were mentionned as Bcc:, their address doesn't appear, and it never hurt anyone. The problem is the From: field is mandatory. Well actually it's not, but in case it's not present, the Sender: field must be present, so the problem stays the same. ;) > 3. converts directly to References: Indeed. My first doubt was that References: and In-Reply-To: should contain a _message_ identifier and not a _thread_ identifier, but RFC 822 explicitely mentions a "previous correspondence which this message answers", a msg-id being a particular case. In real-life implementations, though, I think most MUAs try to find a msg-id that matches the contents of the header. So maybe you should fill this field with the Message-ID you mention in your next question. ;) > 4. Should I generate Message-ID header? If so, how? Maybe it would be > useful to base it on some of the message characteristics? I think you should. The format is free as long as the resulting value is unique. As you said, I guess any algorithm including some message characteristics would be appropriate. These can be a mix of: - the "id" if present, first and obviously. - the "from" attribute - the "to" attribute - a timestamp Another option can be a non-ambiguous hash (MD5, SHA-*) of the whole stanza. In any case, I don't think you should include any random data of data that is unique to the IMAP store: if the user happens to use various SMTP stores (e.g. a private one and a public one), the Message-IDs should be consistent between every store, so the calculation should be as deterministic as possible. HTH. -- David From da-jdev at weeno.net Tue Jan 5 06:10:30 2010 From: da-jdev at weeno.net (David Ammouial) Date: Tue, 5 Jan 2010 06:10:30 -0600 Subject: [jdev] RFC 3921 message to RFC 5322 message conversion In-Reply-To: <20100105055557.38060d81@doch.oaxaca-dome.net> References: <1262685762.4709.60.camel@smoku-desktop> <20100105055557.38060d81@doch.oaxaca-dome.net> Message-ID: <20100105061030.110bf29a@doch.oaxaca-dome.net> Tue, 5 Jan 2010 05:55:57 -0600, David: > In any case, I don't think you should include any random data of data > that is unique to the IMAP store: if the user happens to use various > SMTP stores [...] Sorry, this should read: In any case, I don't think you should include any random data, or any data that is unique to the IMAP store: if the user happens to use various stores [...] -- David From ctofur at gmail.com Tue Jan 5 06:44:25 2010 From: ctofur at gmail.com (chris johnston) Date: Tue, 5 Jan 2010 07:44:25 -0500 Subject: [jdev] RFC 3921 message to RFC 5322 message conversion In-Reply-To: <1262685762.4709.60.camel@smoku-desktop> References: <1262685762.4709.60.camel@smoku-desktop> Message-ID: <7572d2561001050444m4dd338aep6d2515ca088fe0a5@mail.gmail.com> You may want to investigate the transport http://xmpppy.sourceforge.net/mail/ for a base application to improve as you need. I have used this transport with eJabberD and is very simple to setup. -Chris On Tue, Jan 5, 2010 at 5:02 AM, Tomasz Sterna wrote: > Hello. > > I am working on accessing jabber message archive with IMAP and a normal > MUA with IMAP backend. > > This begs a question: How do I convert RFC 3921 message, to RFC 5322 > message to store in IMAP store. (But it may also be useful for > Jabber/E-Mail gateway.) > > 1. How do i store 'from' and 'to' fields of the XMPP message? > RFC 5322 defines From: as mailbox-list and To: as address-list which in > turn reduces to addr-spec which does not include schema and is assumed > to be in SMTP domain. ":" is used to delimiter group names so we cannot > use XMPP URI there. > - Should I add X- header for preserving XMPP 'from' field? What exact? > - Should I fill From: and To: fields to maka maile readers usable? > > 2. Subject: header is straightforward > > 3. converts directly to References: > - what if there is no ? Should I supplement it? How? > > 4. Should I generate Message-ID header? If so, how? Maybe it would be > useful to base it on some of the message characteristics? > > > > > -- > Tomasz Sterna > Xiaoka.com > > _______________________________________________ > JDev mailing list > Forum: http://www.jabberforum.org/forumdisplay.php?f=20 > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: JDev-unsubscribe at jabber.org > _______________________________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at cridland.net Tue Jan 5 06:47:21 2010 From: dave at cridland.net (Dave Cridland) Date: Tue, 05 Jan 2010 12:47:21 +0000 Subject: [jdev] RFC 3921 message to RFC 5322 message conversion In-Reply-To: <20100105055557.38060d81@doch.oaxaca-dome.net> References: <1262685762.4709.60.camel@smoku-desktop> <20100105055557.38060d81@doch.oaxaca-dome.net> Message-ID: <27553.1262695641.659120@puncture> On Tue Jan 5 11:55:57 2010, David Ammouial wrote: > Tue, 05 Jan 2010 11:02:42 +0100, Tomasz: > > 1. How do i store 'from' and 'to' fields of the XMPP message? > > RFC 5322 defines From: as mailbox-list and To: as address-list > which > > in turn reduces to addr-spec which does not include schema and is > > assumed to be in SMTP domain. > > If there is no way to contact the sender of the message via SMTP (or > to refer to the recipient), I think you should either leave the > field > empty (which I'm not sure is legal), or forge an address. Some > solutions that come to mind are: > A. converting the sender JID to an SMTP address at a Jabber-to-SMTP > gateway of your choice. IMHO, it's obviously the best solution, > if > technically possible. > B. using the mail address of the person responsible for the IMAP > store. > C. using a clearly invalid address. > > For solutions B. and C., you should maybe put the sender JID in the > realname part of the address, in order to compensate the loss of > information. > > I don't think B & C are at all practical, I'm sorry to say. I think A is entirely practical. At minimum, I think you could use MIME-style encoding on the node, enclose that in quotes, and then ACE encode the domain. That loses resources, but I don't think that's a worry, given that you can also include that data in the original stanza. Of course, if you do want a full SMTP/XMPP gateway, then you do need resources as well, and you probably need to have the gateway domain as the email address's domain, and the full jid (encoded and quoted) as the local-part. FWIW, I don't think that this is as interesting a problem as rich archival access. > > - Should I add X- header for preserving XMPP 'from' field? What > exact? > > What about the Jabber-ID header? If I understood it correctly, it > seems > to be exactly its role: indicating a way to contact the sender of an > email via XMPP. > > That's a good point. The problem is that it's just a header - there's little searching capability, and it won't appear nicely in the ENVELOPE fetch item. > In any case, I don't think you should include any random data of > data > that is unique to the IMAP store: if the user happens to use various > SMTP stores (e.g. a private one and a public one), the Message-IDs > should be consistent between every store, so the calculation should > be > as deterministic as possible. I don't see why consistency between implementations helps here. It's not as if we need that for email now, after all - different submission agents add message identifiers in all manner of ways, and certainly not consistently. All that matters is that a given message has an identifier, which is (mostly) unique. (Message ids aren't entirely unique, and this doesn't hurt anyone). If the intent is to reply to a message held in one IMAP store through an unassociated Submission server acting as a gateway and have it all work perfectly, then I'd have to raise the If It Hurts defense. :-) Dave. -- Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From norman at rasmussen.co.za Tue Jan 5 11:18:40 2010 From: norman at rasmussen.co.za (Norman Rasmussen) Date: Tue, 5 Jan 2010 17:18:40 +0000 Subject: [jdev] RFC 3921 message to RFC 5322 message conversion In-Reply-To: <7572d2561001050444m4dd338aep6d2515ca088fe0a5@mail.gmail.com> References: <1262685762.4709.60.camel@smoku-desktop> <7572d2561001050444m4dd338aep6d2515ca088fe0a5@mail.gmail.com> Message-ID: <5b698f5a1001050918j5c170f5dn5f3351e5d637f1e4@mail.gmail.com> On Tue, Jan 5, 2010 at 12:44 PM, chris johnston wrote: > You may want to investigate the transport > http://xmpppy.sourceforge.net/mail/ for a base application to improve as > you need. > I have used this transport with eJabberD and is very simple to setup. > Good to hear :-) If anyone finds bugs/has suggestions/patches, feel free to ping me with details. > -Chris > > > > On Tue, Jan 5, 2010 at 5:02 AM, Tomasz Sterna wrote: > >> Hello. >> >> I am working on accessing jabber message archive with IMAP and a normal >> MUA with IMAP backend. >> >> This begs a question: How do I convert RFC 3921 message, to RFC 5322 >> message to store in IMAP store. (But it may also be useful for >> Jabber/E-Mail gateway.) >> >> 1. How do i store 'from' and 'to' fields of the XMPP message? >> RFC 5322 defines From: as mailbox-list and To: as address-list which in >> turn reduces to addr-spec which does not include schema and is assumed >> to be in SMTP domain. ":" is used to delimiter group names so we cannot >> use XMPP URI there. >> - Should I add X- header for preserving XMPP 'from' field? What exact? >> - Should I fill From: and To: fields to maka maile readers usable? >> >> 2. Subject: header is straightforward >> >> 3. converts directly to References: >> - what if there is no ? Should I supplement it? How? >> >> 4. Should I generate Message-ID header? If so, how? Maybe it would be >> useful to base it on some of the message characteristics? >> >> >> >> >> -- >> Tomasz Sterna >> Xiaoka.com >> >> _______________________________________________ >> JDev mailing list >> Forum: http://www.jabberforum.org/forumdisplay.php?f=20 >> Info: http://mail.jabber.org/mailman/listinfo/jdev >> Unsubscribe: JDev-unsubscribe at jabber.org >> _______________________________________________ >> > > > _______________________________________________ > JDev mailing list > Forum: http://www.jabberforum.org/forumdisplay.php?f=20 > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: JDev-unsubscribe at jabber.org > _______________________________________________ > > -- - Norman Rasmussen - Email: norman at rasmussen.co.za - Home page: http://norman.rasmussen.co.za/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From stpeter at stpeter.im Thu Jan 7 16:04:37 2010 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 07 Jan 2010 15:04:37 -0700 Subject: [jdev] Mirabeau/Coherence talk proposal for FOSDEM Dev Room In-Reply-To: <4B40EFA8.8050104@coherence-project.org> References: <4B40EFA8.8050104@coherence-project.org> Message-ID: <4B465A75.7080706@stpeter.im> That looks very interesting! Let's make sure it gets on the agenda. :) On 1/3/10 12:27 PM, Frank Scholz wrote: > Hi, > > my name is Frank Scholz and I'm the founder and lead-developer of > Coherence. Together with Philippe Normand, who works on Mirabeau, > I would like to propose a talk for the XMPP FOSDEM dev room. > > > Mirabeau - creating personal media networks and bridging UPnP devices > over the Internet > ---------------------------------------------------------------------- > > DLNA/UPnP devices - consoles, set-top boxes, TVs - finally > enter our living rooms and allow an easy access of our digital media. > > But the UPnP A/V specification has been designed for local networks > only - preventing media sharing over network borders. > > With the UPnP framework Coherence and the Jabber/XMPP infrastructure > we are able to overcome these obstacles. > > This greatly simplifies the realization of the "access > everywhere" concept and the implementation of "family and friends" > networks. Not only between some software with a dedicated library, > but also by transparently integrating ordinary Consumer Electronics > devices. > > Parents can use there DLNA-enabled TV in their home to look at their > kids photos on the NAS there, or one can access his audio-collection > with the laptop from everywhere, or just with the PS3 at a party at > some friends place. > > With new hardware showing up, like the PlugComputer, we even have > an ideal platform for this task, which e.g. could be given > pre-configured away to other family members. > > Beside the bridging a device like that can act of course as > an UPnP MediaServer too, and be an UPnP MediaHub to online-content > like Flickr, YouTube, Picasa, Miro, BBC,... > > Now with all necessary parts in place - viz. in the > Debian/Ubuntu/Fedora/... repositories, a simple package install, > the naming of an Jabber server and a chat room there is all > that's needed to create a personal media network. > > Technically this is realized by enabling the sharing of UPnP devices, > like an UPnP MediaServer, with members of ones roster. The communication > to and from these devices is done via 'messages' in a MUC, where > each Coherence/Mirabeau instance appears as a chat user. > The actual media-transfer is at the moment done out-of-band, > to not strain the servers excessively. > > > Coherence is an Open-Source DLNA/UPnP framework, > -> http://coherence-project.org > > with the emphasis on being easily extended - resulting in a > community driven, constantly growing list of plugins. > -> http://coherence-project.org/wiki/MediaServer > > Mirabeau was first presented on the 2nd Open-Source DLNA summit in 2008 > -> http://coherence-project.org/download/coherence-jabber.pdf > > and demonstrated during Gnome/KDE conference in 2009 > -> http://coherence-project.org/download/mirabeau-guadec-2009.odp > > http://netzflocken.de/2009/6/30/pont-mirabeau-an-upnp-bridge > http://base-art.net/Articles/108/ > > http://www.plugcomputer.org/ > > Regards, > Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6820 bytes Desc: S/MIME Cryptographic Signature URL: From stpeter at stpeter.im Thu Jan 7 16:15:56 2010 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 07 Jan 2010 15:15:56 -0700 Subject: [jdev] Java XMPP library with jingle support? In-Reply-To: <20100103225231.GA20001@xanadu.blop.info> References: <20100103225231.GA20001@xanadu.blop.info> Message-ID: <4B465D1C.1070306@stpeter.im> On 1/3/10 3:52 PM, Lucas Nussbaum wrote: > Hi, > > Is there a Java XMPP library with Jingle support? > > I've tried Smack, but its Jingle support seems to be half-working. For > example, it is still using the urn:xmpp:tmp:jingle namespace, and isn't > interoperable with pidgin. Smack is open-source, no? Patches welcome, I'm sure. :) > Alternatively, does someone know Jabber clients running on Linux that > interoperate with Smack's version of Jingle? Better, I think, to make Smack work correctly. Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6820 bytes Desc: S/MIME Cryptographic Signature URL: From stpeter at stpeter.im Thu Jan 7 16:24:11 2010 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 07 Jan 2010 15:24:11 -0700 Subject: [jdev] [Fwd: [Juser] facebook style XMPP web chat bar - iJabBar] Message-ID: <4B465F0B.6020500@stpeter.im> FYI, I think this person sent his message to the wrong list... -------- Original Message -------- Subject: [Juser] facebook style XMPP web chat bar - iJabBar Date: Tue, 5 Jan 2010 18:49:52 +0800 From: Zhan Caibao Reply-To: Jabber/XMPP end-user discussion list To: juser at jabber.org Hi everybody, I'm the owner of iJab, an opensource XMPP web client. And now I'm very glad we released iJabBar, a facebook style web chat bar, anyone want to integrate XMPP chat into your own website and please go to http://code.google.com/p/ijab/ to take a look. Thanks. Zhan -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6820 bytes Desc: S/MIME Cryptographic Signature URL: From lucas at lucas-nussbaum.net Fri Jan 8 01:01:38 2010 From: lucas at lucas-nussbaum.net (Lucas Nussbaum) Date: Fri, 8 Jan 2010 08:01:38 +0100 Subject: [jdev] Java XMPP library with jingle support? In-Reply-To: <4B465D1C.1070306@stpeter.im> References: <20100103225231.GA20001@xanadu.blop.info> <4B465D1C.1070306@stpeter.im> Message-ID: <20100108070138.GA338@xanadu.blop.info> On 07/01/10 at 15:15 -0700, Peter Saint-Andre wrote: > On 1/3/10 3:52 PM, Lucas Nussbaum wrote: > > Hi, > > > > Is there a Java XMPP library with Jingle support? > > > > I've tried Smack, but its Jingle support seems to be half-working. For > > example, it is still using the urn:xmpp:tmp:jingle namespace, and isn't > > interoperable with pidgin. > > Smack is open-source, no? Patches welcome, I'm sure. :) > > > Alternatively, does someone know Jabber clients running on Linux that > > interoperate with Smack's version of Jingle? > > Better, I think, to make Smack work correctly. Well, first, I don't really have the time needed to do that. Another problem is that it seems that the Jingle part of Smack is not completely open source. Or at least, not all the sources are available. For example, jstun (a STUN library) was modified and is only provided as a jar. -- | Lucas Nussbaum | lucas at lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas at nussbaum.fr GPG: 1024D/023B3F4F | From admin at flosoft.biz Fri Jan 8 09:27:18 2010 From: admin at flosoft.biz (Florian Jensen) Date: Fri, 8 Jan 2010 15:27:18 +0000 Subject: [jdev] XMPP Summit #8 in Brussels Message-ID: Hey guys, first of all, this will be my last E-mail to all XMPP Mailinglists. Future E-mails will all go to the Summit Mailinglist: summit at xmpp.org. You can subscribe here: http://mail.jabber.org/mailman/listinfo/summit The XSF has decided to hold it's XMPP Summit in the Best Western - Carrefour de L'Europe Hotel in the centre of Brussels (http://xmpp.org/summit/summit8.shtml#hotel). We also have a special deal available for all XSF Members, a single or double / twin room for 109? / night. Room sharing is encouraged and we can hook people up on the Summit Mailinglist, or just contact me directly (http://xmpp.org/summit/summit8.shtml#contact). For anyone who then wants to order the room, I will send you a special order form that needs to be faxed (yes, I'm sorry about that), to the Hotel. Please note: We only have this deal until the 15th of January. Greets, Florian Jensen From julien.genestoux at gmail.com Tue Jan 12 10:01:15 2010 From: julien.genestoux at gmail.com (Julien Genestoux) Date: Tue, 12 Jan 2010 17:01:15 +0100 Subject: [jdev] Next XMPP meetup in San Francisco : February 2nd Message-ID: <26c0cf901001120801y3ee1f9dfl9992abef39242bd7@mail.gmail.com> Hey, The next XMPP meetup in San Francisco will be held on Feb 2nd, 3 days before FOSDEM :) It's hosted at Pivotal Labs who also offers the food and the drinks : http://technology.meetup.com/11/calendar/12290361/ Come and show what you do with XMPP. Speakers wanted! Cheers Ps: Happy New Year! -- Julien Genestoux, http://twitter.com/julien51 http://superfeedr.com +1 (415) 830 6574 +33 (0)9 70 44 76 29 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stpeter at stpeter.im Tue Jan 12 16:14:52 2010 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 12 Jan 2010 15:14:52 -0700 Subject: [jdev] XSF membership application period, Q1 2010 Message-ID: <4B4CF45C.5070004@stpeter.im> The XMPP Standards Foundation is currently accepting applications for new members. This Q1 application period will run until the end of the month. Why apply? - Help the XSF with technical reviews and communication efforts - Help elect the XMPP Council, or run for the Council in the future (council candidates must be XSF members) - Help the XSF stay true to its mission of building an open, secure, feature-rich, decentralized infrastructure for real-time communication and collaboration over the Internet Application instructions are available here: http://wiki.xmpp.org/web/Membership_Applications_January_2010 This application period ends on January 31, so take action today. :) Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6820 bytes Desc: S/MIME Cryptographic Signature URL: From virgilio.santos at gmail.com Thu Jan 14 09:40:45 2010 From: virgilio.santos at gmail.com (=?ISO-8859-1?Q?Virg=EDlio_Santos?=) Date: Thu, 14 Jan 2010 13:40:45 -0200 Subject: [jdev] Hi there Message-ID: Hi, I?m new on software development with jabber. I'll be on a java web based project that is about to start and I want to know if someone has any hints, tutorials, books for dummies to recommend to me. Thanks in advance, Virg?lio -- "In July of 2004, Bush told an Amish group in Pennsylvania that "God speaks through me." He believes that God wanted him to be president, and that God is working through him, even as tens of thousands of innocent Iraqi men, women, and children die in a war based on lies." From abhinavsingh at ymail.com Thu Jan 14 12:05:00 2010 From: abhinavsingh at ymail.com (Abhinav Singh) Date: Thu, 14 Jan 2010 10:05:00 -0800 (PST) Subject: [jdev] Hi there In-Reply-To: References: Message-ID: <515668.43189.qm@web31804.mail.mud.yahoo.com> Hi, Know the in and out of how to apply/use smack library.http://www.igniterealtime.org/projects/smack/ That should give you a good start, combined with various xep docs. Abhinav Singh, Bangalore, India http://abhinavsingh.com ________________________________ From: Virg?lio Santos To: jdev at jabber.org Sent: Thu, January 14, 2010 9:10:45 PM Subject: [jdev] Hi there Hi, I?m new on software development with jabber. I'll be on a java web based project that is about to start and I want to know if someone has any hints, tutorials, books for dummies to recommend to me. Thanks in advance, Virg?lio -- "In July of 2004, Bush told an Amish group in Pennsylvania that "God speaks through me." He believes that God wanted him to be president, and that God is working through him, even as tens of thousands of innocent Iraqi men, women, and children die in a war based on lies." _______________________________________________ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: JDev-unsubscribe at jabber.org _______________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin at kismith.co.uk Thu Jan 14 12:11:14 2010 From: kevin at kismith.co.uk (Kevin Smith) Date: Thu, 14 Jan 2010 18:11:14 +0000 Subject: [jdev] Hi there In-Reply-To: References: Message-ID: On Thu, Jan 14, 2010 at 3:40 PM, Virg?lio Santos wrote: > Hi, Hi, > I want > to know if someone has any hints, tutorials, books for dummies to > recommend to me. Peter, Remko and I wrote a book on XMPP: http://www.amazon.com/XMPP-Definitive-Real-Time-Applications-Technologies/dp/059652126X/ref=cm_cr_pr_product_top That should be a good introduction to XMPP. If you're interested in developing with XMPP for web applications in javascript, Jack also has a book: http://www.amazon.com/Professional-XMPP-Programming-JavaScript-jQuery/dp/0470540710/ref=pd_sim_b_3 I've not read this one - but people who have done so have said it's very good. /K From mr.spoon21 at gmail.com Sat Jan 16 07:22:00 2010 From: mr.spoon21 at gmail.com (Mr.SpOOn) Date: Sat, 16 Jan 2010 13:22:00 +0000 Subject: [jdev] Using xmpp with an unsupported language Message-ID: <8f67b6f81001160522n177fd4ccqe160cac605d954e4@mail.gmail.com> Hi, how would it be possible using the xmpp protocol with a language not listed in the libraries page? For example, I'm interested in using it with the Processing framework or with SuperCollider. Processing (http://processing.org/) is built on Java, but there exists a Javascript version (http://processingjs.org/). So maybe in these cases it would be possible to use the Java or JavaScript library listed on the site. What do you think? Anyway, no idea for SuperCollider (http://supercollider.sourceforge.net/). Would it be necessary to write a new library from scratch? Or is there a simpler method? Thanks. From coder2000 at gmail.com Sat Jan 16 09:43:15 2010 From: coder2000 at gmail.com (Dieter Lunn) Date: Sat, 16 Jan 2010 09:43:15 -0600 Subject: [jdev] Using xmpp with an unsupported language In-Reply-To: <8f67b6f81001160522n177fd4ccqe160cac605d954e4@mail.gmail.com> References: <8f67b6f81001160522n177fd4ccqe160cac605d954e4@mail.gmail.com> Message-ID: <340b38941001160743t3b760543ndface5be2ddd3b4@mail.gmail.com> So long as you can parse XML you can use XMPP with any language. Dieter Lunn http://www.coder2000.ca On Sat, Jan 16, 2010 at 7:22 AM, Mr.SpOOn wrote: > Hi, > how would it be possible using the xmpp protocol with a language not > listed in the libraries page? > > For example, I'm interested in using it with the Processing framework > or with SuperCollider. > > Processing (http://processing.org/) is built on Java, but there exists > a Javascript version (http://processingjs.org/). So maybe in these > cases it would be possible to use the Java or JavaScript library > listed on the site. What do you think? > > Anyway, no idea for SuperCollider > (http://supercollider.sourceforge.net/). Would it be necessary to > write a new library from scratch? Or is there a simpler method? > > Thanks. > _______________________________________________ > JDev mailing list > Forum: http://www.jabberforum.org/forumdisplay.php?f=20 > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: JDev-unsubscribe at jabber.org > _______________________________________________ > From admin at flosoft.biz Wed Jan 20 17:31:52 2010 From: admin at flosoft.biz (Florian Jensen) Date: Wed, 20 Jan 2010 23:31:52 +0000 Subject: [jdev] XMPP Summit: Developers Challenge (with prizes!!) Message-ID: Hey everyone! Less than 3 weeks left until the XMPP Summit #8 comes to Brussels. This year, we've got something new! Nokia has generously offered to sponsor a mobile XMPP developer challenge. What does that mean? Starting from NOW, you can start writing a mobile application for ANY Nokia platform (Maemo / S60v3 / S60v5 ...). The requirements are: - The program must be FREELY available; OpenSource is preferred. - The application needs to be demoed on a Nokia Phone (we have demo devices on location) on the XMPP Summit (Monday). If you are not attending the Summit, find someone who is, and can demo / explain the app, and collect the prize. - Limit of 1 application per attendee. - Substantially new code, as decreed on the day by the judges. (If you have questions, the judges will give guidance, but the final decision will be made on the day) - Judges aren't eligible. - And of course: The application needs to use XMPP in some way. The judges are: Jack Moffitt (XSF Board Chairman); Kevin Smith (XSF Council Chairman); Kristian Luoma (Nokia) So what can I win? We have one Nokia N900 generously sponsored by Nokia which the judges will hand over to the best application. We will also have a second prize, whose winner is chosen by all the attendees (participants excluded). This prize consists of 2 XMPP books (XMPP: The Definitive Guide; Professional XMPP Programming with Javascript and Jquery) and an official XMPP T-Shirt. So, open up those text editors and start coding, and good luck! Greets, Florian Jensen From pubsub at networkimprov.net Wed Jan 20 17:44:50 2010 From: pubsub at networkimprov.net (Liam) Date: Wed, 20 Jan 2010 15:44:50 -0800 Subject: [jdev] Replication & revision protocol In-Reply-To: <41bc5e6c1001181335h3511da4fwae0ec6db2e9f4f21@mail.gmail.com> References: <41bc5e6c1001181335h3511da4fwae0ec6db2e9f4f21@mail.gmail.com> Message-ID: <41bc5e6c1001201544t3c2e1df6w49308784dd16b974@mail.gmail.com> I'm building an app which replicates collections of data objects among groups of contributors/subscribers. I use XMPP for transport & store-forward, and I've built a simple replication & revision system on top of PubSub. I'm considering open sourcing this code and documenting the protocol. (Source is javascript requiring Strophe.) Creating a separate package for this would entail some work, so I'd like to gauge potential interest... My replication & revision system does the following: Establishes pubsub nodes for shared collections Reliably transmits (reliable requires IQ Notifications): - invitations to join a collection - invitation acceptances - collection replicas to new members - resignations from a collection - revisions to a collection, containing: a) list of revised objects b) diffs for added/modified objects format is app-specific; common diff types may be specified Obviously, it's very lightweight. It's not focused on real-time apps per se, but could be applied thereto. Also, I'd love pointers to other forums where folks could be interested... Liam PS: protocol specifics to follow... -------------- next part -------------- An HTML attachment was scrubbed... URL: From pubsub at networkimprov.net Wed Jan 20 18:39:17 2010 From: pubsub at networkimprov.net (Liam) Date: Wed, 20 Jan 2010 16:39:17 -0800 Subject: [jdev] Replication & revision protocol In-Reply-To: <41bc5e6c1001201544t3c2e1df6w49308784dd16b974@mail.gmail.com> References: <41bc5e6c1001181335h3511da4fwae0ec6db2e9f4f21@mail.gmail.com> <41bc5e6c1001201544t3c2e1df6w49308784dd16b974@mail.gmail.com> Message-ID: <41bc5e6c1001201639l51dd68f9yd6ef89b71cab26d6@mail.gmail.com> The protocol sequence below is derived from an exchange between instances of my app. Typos could have crept in during editing! There are features missing... splitting messages to fit the max payload size for the node, and types for diff formats. Feedback welcome! 1. Creator makes a pubsub node for incoming messages, and subscribes to it: (These nodes give us IQ for 1-to-1 messaging, even if recipient is offline.) http://jabber.org/protocol/pubsub#node_config 0 0 open whitelist never 2. Contributor does the same: http://jabber.org/protocol/pubsub#node_config 0 0 open whitelist never 3. Creator makes a pubsub node for a shared collection, and subscribes: http://jabber.org/protocol/pubsub#node_config 0 0 subscribers whitelist never 4. Creator revs the collection whitelist, notifies collection members of the whitelist change, and invites Contributor to join the collection: contributor at localhost Liam 2010-01-19T20:45:26Z Cornucopia A non-descript invitation 5. Contributor subscribes to the collection, and notifies Creator: 6. Creator replicates collection to Contributor, first meta/data and then revision history: 7. Contributor makes a revision to collection: 8. Contributor resigns from collection: On Wed, Jan 20, 2010 at 3:44 PM, Liam wrote: > I'm building an app which replicates collections of data objects among > groups of contributors/subscribers. > > I use XMPP for transport & store-forward, and I've built a simple > replication & revision system on top of PubSub. > > I'm considering open sourcing this code and documenting the protocol. > (Source is javascript requiring Strophe.) Creating a separate package for > this would entail some work, so I'd like to gauge potential interest... > > My replication & revision system does the following: > > Establishes pubsub nodes for shared collections > Reliably transmits (reliable requires IQ Notifications): > - invitations to join a collection > - invitation acceptances > - collection replicas to new members > - resignations from a collection > - revisions to a collection, containing: > a) list of revised objects > b) diffs for added/modified objects > format is app-specific; common diff types may be specified > > Obviously, it's very lightweight. It's not focused on real-time apps per > se, but could be applied thereto. > > Also, I'd love pointers to other forums where folks could be interested... > > Liam > > PS: protocol specifics to follow... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkdeexit at gmail.com Fri Jan 22 12:38:32 2010 From: rkdeexit at gmail.com (RaviKant Cherukuri) Date: Fri, 22 Jan 2010 10:38:32 -0800 Subject: [jdev] Multiplexing large number of client connections Message-ID: <13222c891001221038s6d75843bv1f66a2f4c84d668@mail.gmail.com> Is there a way to multiplex multiple client streams each belonging to a different user on the same TCP connection? The closest I could find was the BOSH XEP that talks about multiplexing using some sort of a session id. Is there a way to do this on a TCP connection? If not, is BOSH a recommended way of doing this? Federation would be great for this but if the target network does not support federation, and a gateway is connecting as a client (I think meebo does this), are there any XMPP tricks that can help me out? Thanks for the help, Ravikant -------------- next part -------------- An HTML attachment was scrubbed... URL: From stpeter at stpeter.im Fri Jan 22 15:22:39 2010 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 22 Jan 2010 14:22:39 -0700 Subject: [jdev] Multiplexing large number of client connections In-Reply-To: <13222c891001221038s6d75843bv1f66a2f4c84d668@mail.gmail.com> References: <13222c891001221038s6d75843bv1f66a2f4c84d668@mail.gmail.com> Message-ID: <4B5A171F.8080405@stpeter.im> On 1/22/10 11:38 AM, RaviKant Cherukuri wrote: > Is there a way to multiplex multiple client streams each belonging to a > different user on the same TCP connection? No. > The closest I could find was > the BOSH XEP that talks about multiplexing using some sort of a session > id. Is there a way to do this on a TCP connection? If not, is BOSH a > recommended way of doing this? There really is no recommended way of doing this. > Federation would be great for this but if the target network does not > support federation, and a gateway is connecting as a client (I think > meebo does this), are there any XMPP tricks that can help me out? IMHO connecting a gateway as a client is a bad idea, and perhaps even abusive (most public XMPP services will limit the number of simultaneous resources / full JIDs that you are allowed to have). Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6820 bytes Desc: S/MIME Cryptographic Signature URL: From dave at cridland.net Fri Jan 22 16:43:49 2010 From: dave at cridland.net (Dave Cridland) Date: Fri, 22 Jan 2010 22:43:49 +0000 Subject: [jdev] Multiplexing large number of client connections In-Reply-To: <13222c891001221038s6d75843bv1f66a2f4c84d668@mail.gmail.com> References: <13222c891001221038s6d75843bv1f66a2f4c84d668@mail.gmail.com> Message-ID: <14795.1264200229.743698@puncture> On Fri Jan 22 18:38:32 2010, RaviKant Cherukuri wrote: > Is there a way to multiplex multiple client streams each belonging > to a > different user on the same TCP connection? The closest I could find > was the > BOSH XEP that talks about multiplexing using some sort of a session > id. Is > there a way to do this on a TCP connection? If not, is BOSH a > recommended > way of doing this? No, but there is a fantastic way of multiplexing multiple connections over a single IP layer, it's called "TCP". If this sounds a bit facetious, then it is - TCP is a multiplexing method for a connection, and it's fine to use it - from the serv's point of view, it's likely that there's *very* little resource difference from servicing multiple TCP sessions compared to servicing multiple client sessions in the same TCP stream - plus the server can no longer take advantage of load balancing techniques so easily, or even simple SRV. Dave. -- Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From norman at rasmussen.co.za Sat Jan 23 09:35:08 2010 From: norman at rasmussen.co.za (Norman Rasmussen) Date: Sat, 23 Jan 2010 15:35:08 +0000 Subject: [jdev] Multiplexing large number of client connections In-Reply-To: <13222c891001221038s6d75843bv1f66a2f4c84d668@mail.gmail.com> References: <13222c891001221038s6d75843bv1f66a2f4c84d668@mail.gmail.com> Message-ID: <5b698f5a1001230735p994d9d5t97ddb9716e8c4e30@mail.gmail.com> Openfire has a connection manager [1], but you didn't say if the 'multiple client streams' were xmpp or legacy. Also I would guess that connection managers would have to be set up bu the administrator (not by random connecting users) [1] http://www.igniterealtime.org/projects/openfire/connection_manager.jsp On Fri, Jan 22, 2010 at 6:38 PM, RaviKant Cherukuri wrote: > Is there a way to multiplex multiple client streams each belonging to a > different user on the same TCP connection? The closest I could find was the > BOSH XEP that talks about multiplexing using some sort of a session id. Is > there a way to do this on a TCP connection? If not, is BOSH a recommended > way of doing this? > > Federation would be great for this but if the target network does not > support federation, and a gateway is connecting as a client (I think meebo > does this), are there any XMPP tricks that can help me out? > > Thanks for the help, > Ravikant > > > > _______________________________________________ > JDev mailing list > Forum: http://www.jabberforum.org/forumdisplay.php?f=20 > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: JDev-unsubscribe at jabber.org > _______________________________________________ > > -- - Norman Rasmussen - Email: norman at rasmussen.co.za - Home page: http://norman.rasmussen.co.za/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at rasmussen.co.za Sat Jan 23 09:46:08 2010 From: norman at rasmussen.co.za (Norman Rasmussen) Date: Sat, 23 Jan 2010 15:46:08 +0000 Subject: [jdev] Multiplexing large number of client connections In-Reply-To: <5b698f5a1001230735p994d9d5t97ddb9716e8c4e30@mail.gmail.com> References: <13222c891001221038s6d75843bv1f66a2f4c84d668@mail.gmail.com> <5b698f5a1001230735p994d9d5t97ddb9716e8c4e30@mail.gmail.com> Message-ID: <5b698f5a1001230746t6501bf05p7d50e89d9a7b01f8@mail.gmail.com> It seems that openfire's xep [2] uses very similar stanza's to jabberd2's Component Protocol [3]. [2] http://www.igniterealtime.org/community/docs/DOC-1210 [3] http://codex.xiaoka.com/wiki/_media/jabberd2:component.html On Sat, Jan 23, 2010 at 3:35 PM, Norman Rasmussen wrote: > Openfire has a connection manager [1], but you didn't say if the 'multiple > client streams' were xmpp or legacy. Also I would guess that connection > managers would have to be set up bu the administrator (not by random > connecting users) > > [1] http://www.igniterealtime.org/projects/openfire/connection_manager.jsp > > On Fri, Jan 22, 2010 at 6:38 PM, RaviKant Cherukuri wrote: > >> Is there a way to multiplex multiple client streams each belonging to a >> different user on the same TCP connection? The closest I could find was the >> BOSH XEP that talks about multiplexing using some sort of a session id. Is >> there a way to do this on a TCP connection? If not, is BOSH a recommended >> way of doing this? >> >> Federation would be great for this but if the target network does not >> support federation, and a gateway is connecting as a client (I think meebo >> does this), are there any XMPP tricks that can help me out? >> >> Thanks for the help, >> Ravikant >> >> >> >> _______________________________________________ >> JDev mailing list >> Forum: http://www.jabberforum.org/forumdisplay.php?f=20 >> Info: http://mail.jabber.org/mailman/listinfo/jdev >> Unsubscribe: JDev-unsubscribe at jabber.org >> _______________________________________________ >> >> > > > -- > - Norman Rasmussen > - Email: norman at rasmussen.co.za > - Home page: http://norman.rasmussen.co.za/ > -- - Norman Rasmussen - Email: norman at rasmussen.co.za - Home page: http://norman.rasmussen.co.za/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan at dickinsons.co.za Sun Jan 24 06:43:41 2010 From: jonathan at dickinsons.co.za (Jonathan Dickinson) Date: Sun, 24 Jan 2010 14:43:41 +0200 Subject: [jdev] Multiplexing large number of client connections Message-ID: <4b5c4085.1c07d00a.04d9.ffffce35@mx.google.com> You can 'multiplex' multiple resources into one stream. Not sure about server support though. -----Original Message----- From: Norman Rasmussen Sent: 23 January 2010 05:46 PM To: Jabber/XMPP software development list Subject: Re: [jdev] Multiplexing large number of client connections It seems that openfire's xep [2] uses very similar stanza's to jabberd2's Component Protocol [3]. [2]?http://www.igniterealtime.org/community/docs/DOC-1210 [3]?http://codex.xiaoka.com/wiki/_media/jabberd2:component.html On Sat, Jan 23, 2010 at 3:35 PM, Norman Rasmussen wrote: Openfire has a connection manager [1], but you didn't say if the 'multiple client streams' were xmpp or legacy. ?Also I would guess that connection managers would have to be set up bu the administrator (not by random connecting users) [1] http://www.igniterealtime.org/projects/openfire/connection_manager.jsp On Fri, Jan 22, 2010 at 6:38 PM, RaviKant Cherukuri wrote: Is there a way to multiplex multiple client?streams each belonging to a different user on the same TCP connection? The closest I could find was the BOSH XEP that talks about multiplexing using some sort of a session id. Is there a way to do this on a TCP connection? If not, is BOSH a recommended way of doing this? ? Federation would be great for this but if the [The entire original message is not included] -------------- next part -------------- An HTML attachment was scrubbed... URL: From stpeter at stpeter.im Sun Jan 24 21:55:00 2010 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Sun, 24 Jan 2010 20:55:00 -0700 Subject: [jdev] Multiplexing large number of client connections In-Reply-To: <4b5c4085.1c07d00a.04d9.ffffce35@mx.google.com> References: <4b5c4085.1c07d00a.04d9.ffffce35@mx.google.com> Message-ID: <4B5D1614.8060009@stpeter.im> On 1/24/10 5:43 AM, Jonathan Dickinson wrote: > You can 'multiplex' multiple resources into one stream. Not sure about > server support though. As I understand it, that's not what he's looking for. And we removed the protocol for multiple resources over a single stream from draft-ietf-xmpp-3920bis because list consensus led me to think that people believe it is unnecessary and too complicated. Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6820 bytes Desc: S/MIME Cryptographic Signature URL: From jeskar at web.de Mon Jan 25 12:46:03 2010 From: jeskar at web.de (Karsten J) Date: Mon, 25 Jan 2010 19:46:03 +0100 Subject: [jdev] Can an external XMPP component to listen to certain events on the server side such as a buddy request? Message-ID: <27db7e21001251046w20b9e0x99d50c0049dc4a07@mail.gmail.com> Hello, I am studying at a University in Germany. We started a little project which tracks the location of people, connects them and helps them to interact on different levels. Well, in the end it will. We decided to use XMPP as our protocol and as it turns out there is almost always an XEP which covers something we want to do. I really start liking it. Since we don't have the capacity to write our own server we decide to use an existing one and enhance its features with an external component. However, I kinda ran into a problem and I hope you can help me out. In the XEP-0114 it says that an external component can do things that clients cannot. I tried to find a list of those things but till now I wasn't lucky. There is one special thing my component needs to be able to do. I would like my component to listen to buddy requests and "buddy acceptances" of clients which are received by the server. As far as I know an internal component or something like a packet interceptor as a plug in which sends the packets on to my component could do that. However, before I start writing a plug in for a specific server implementation I would like to know if there is a way within the specifications of the protocol. I need this feature to do some logic on the component side. I hope you understand my problem and thank you for any advices. best whishes, Karsten Jeschkies From tomek at xiaoka.com Mon Jan 25 15:29:09 2010 From: tomek at xiaoka.com (Tomasz Sterna) Date: Mon, 25 Jan 2010 22:29:09 +0100 Subject: [jdev] Multiplexing large number of client connections In-Reply-To: <4B5D1614.8060009@stpeter.im> References: <4b5c4085.1c07d00a.04d9.ffffce35@mx.google.com> <4B5D1614.8060009@stpeter.im> Message-ID: <1264454949.7433.25.camel@wing.ordonowny.acn.waw.pl> Dnia 2010-01-24, nie o godzinie 20:55 -0700, Peter Saint-Andre pisze: > And we removed the protocol for multiple resources over a single > stream > from draft-ietf-xmpp-3920bis because list consensus led me to think > that > people believe it is unnecessary and too complicated. Why the hell did I spent time implementing it in jabberd2 then? -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/ From tomek at xiaoka.com Mon Jan 25 15:32:53 2010 From: tomek at xiaoka.com (Tomasz Sterna) Date: Mon, 25 Jan 2010 22:32:53 +0100 Subject: [jdev] Multiplexing large number of client connections In-Reply-To: <13222c891001221038s6d75843bv1f66a2f4c84d668@mail.gmail.com> References: <13222c891001221038s6d75843bv1f66a2f4c84d668@mail.gmail.com> Message-ID: <1264455173.7433.29.camel@wing.ordonowny.acn.waw.pl> Dnia 2010-01-22, pi? o godzinie 10:38 -0800, RaviKant Cherukuri pisze: > Is there a way to multiplex multiple client streams each belonging to > a different user on the same TCP connection? jadc2s does that for jabberd14 and jabberd2 has it built-in with its c2s component. c2s component job is to accept client connections and route all jabber:client stanzas over one connection to jabberd2 router component. This way you may handle client connections on different IP addresses and different machines balancing load and overcoming 65k connections per one IP address limitation of IP protocol. -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/ From ilya at drakontas.com Mon Jan 25 15:38:06 2010 From: ilya at drakontas.com (Ilya Braude) Date: Mon, 25 Jan 2010 16:38:06 -0500 Subject: [jdev] Can an external XMPP component to listen to certain events on the server side such as a buddy request? In-Reply-To: <27db7e21001251046w20b9e0x99d50c0049dc4a07@mail.gmail.com> References: <27db7e21001251046w20b9e0x99d50c0049dc4a07@mail.gmail.com> Message-ID: <4B5E0F3E.1060600@drakontas.com> Hi Karsten, Karsten J wrote: > Hello, > > I am studying at a University in Germany. We started a little project > which tracks the location of people, connects them and helps them to > interact on different levels. Well, in the end it will. > > We decided to use XMPP as our protocol and as it turns out there is > almost always an XEP which covers something we want to do. I really > start liking it. > > Since we don't have the capacity to write our own server we decide to > use an existing one and enhance its features with an external > component. However, I kinda ran into a problem and I hope you can help > me out. In the XEP-0114 it says that an external component can do > things that clients cannot. I tried to find a list of those things but > till now I wasn't lucky. I've ran into a similar use case myself. External components don't have that kind of access. An external component basically registers itself as component.domain.com, and can send and receive messages from/to all JIDs at that domain (i.e. user1 at component.domain.com, user2 at component.domain.com, component.domain.com, etc.). But the xmpp server will not route stanzas that are not addressed to the component to it, nor will the server allow the component to send stanzas addressed from other domains. > There is one special thing my component needs > to be able to do. I would like my component to listen to buddy > requests and "buddy acceptances" of clients which are received by the > server. As far as I know an internal component or something like a > packet interceptor as a plug in which sends the packets on to my > component could do that. However, before I start writing a plug in for > a specific server implementation I would like to know if there is a > way within the specifications of the protocol. > We wrote a plugin for openfire that just forwards stanzas down an XML pipe over TCP, and use an external (non-XMPP) service to filter out the stanzas we are interested in using xpath expressions (this was really easy with twisted words/wokkel). Alternatively, you can implement the logic completely inside your plugin. I don't think you'll be able to pass stanzas from a plugin or internal component to an external component directly, the component protocol doesn't support that. If you really want to use an external XMPP component, I can only think of wrapping your original stanza in another stanza addressed to the component. Good luck, Ilya > I need this feature to do some logic on the component side. > > I hope you understand my problem and thank you for any advices. > > best whishes, > Karsten Jeschkies > _______________________________________________ > JDev mailing list > Forum: http://www.jabberforum.org/forumdisplay.php?f=20 > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: JDev-unsubscribe at jabber.org > _______________________________________________ > -- Ilya Braude Lead Software Engineer Drakontas LLC (267) 415-4769 From stpeter at stpeter.im Mon Jan 25 15:40:06 2010 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Mon, 25 Jan 2010 14:40:06 -0700 Subject: [jdev] Multiplexing large number of client connections In-Reply-To: <1264454949.7433.25.camel@wing.ordonowny.acn.waw.pl> References: <4b5c4085.1c07d00a.04d9.ffffce35@mx.google.com> <4B5D1614.8060009@stpeter.im> <1264454949.7433.25.camel@wing.ordonowny.acn.waw.pl> Message-ID: <4B5E0FB6.208@stpeter.im> On 1/25/10 2:29 PM, Tomasz Sterna wrote: > Dnia 2010-01-24, nie o godzinie 20:55 -0700, Peter Saint-Andre pisze: >> And we removed the protocol for multiple resources over a single >> stream >> from draft-ietf-xmpp-3920bis because list consensus led me to think >> that >> people believe it is unnecessary and too complicated. > > Why the hell did I spent time implementing it in jabberd2 then? Because you are a good person and a true innovator. The multi-resource stuff seemed like a good idea at the time but people on the XMPP WG discussion list were concerned about adding complexity. We could, of course, still define it as an XMPP extension if there's interest. Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6820 bytes Desc: S/MIME Cryptographic Signature URL: From jonathan at dickinsons.co.za Mon Jan 25 17:41:32 2010 From: jonathan at dickinsons.co.za (Jonathan Dickinson) Date: Tue, 26 Jan 2010 01:41:32 +0200 Subject: [jdev] Multiplexing large number of client connections Message-ID: <4b5e2c37.0f67f10a.69a1.78be@mx.google.com> There is definitely interest on my side. I will basically have a single client that other processes connect to via IPC - the cleanest solution would be resources, although the client could always open up new connections. In any case it would be great for scenarios like mine (basically delegation). Sorry for not conforming to the list standards, I am on my mobile. -----Original Message----- From: Peter Saint-Andre Sent: 25 January 2010 11:40 PM To: Jabber/XMPP software development list Subject: Re: [jdev] Multiplexing large number of client connections On 1/25/10 2:29 PM, Tomasz Sterna wrote: > Dnia 2010-01-24, nie o godzinie 20:55 -0700, Peter Saint-Andre pisze: >> And we removed the protocol for multiple resources over a single >> stream >> from draft-ietf-xmpp-3920bis because list consensus led me to think >> that >> people believe it is unnecessary and too complicated. > > Why the hell did I spent time implementing it in jabberd2 then? Because you are a good person and a true innovator. The multi-resource stuff seemed like a good idea at the time but people on the XMPP WG discussion list were concerned about adding complexity. We could, of course, still define it as an XMPP extension if there's interest. Peter -- Peter Saint-Andre https://stpeter.im/ From mmahoney at palantirisystems.com Mon Jan 25 23:43:00 2010 From: mmahoney at palantirisystems.com (Mike Mahoney) Date: Tue, 26 Jan 2010 00:43:00 -0500 Subject: [jdev] Multiplexing large number of client connections In-Reply-To: <4b5e2c37.0f67f10a.69a1.78be@mx.google.com> References: <4b5e2c37.0f67f10a.69a1.78be@mx.google.com> Message-ID: <017d01ca9e4a$6bd218e0$43764aa0$@com> > > There is definitely interest on my side. I will basically have a > single client that other processes connect to via IPC - the cleanest > solution would be resources, although the client could always open up > new connections. In any case it would be great for scenarios like mine > (basically delegation). > FWIW, there's interest on my side as well, but I realize I missed the previous discussion. Our client is device based and it would be nice if one JID could be used to represent multiple resources at one site. We currently get around it by tracking resources at the client and routing messages based on content. I think it is an important feature for non-user based clients. -Mike ----- Mike Mahoney www.palantirisystems.com xmpp: mmahoney at jabber.org From jeskar at web.de Wed Jan 27 13:32:51 2010 From: jeskar at web.de (Karsten J) Date: Wed, 27 Jan 2010 20:32:51 +0100 Subject: [jdev] JDev Digest, Vol 72, Issue 14 In-Reply-To: References: Message-ID: <27db7e21001271132k6da4cbadse76a3f5743007ebb@mail.gmail.com> > Hi Karsten, > > Karsten J wrote: >> Hello, >> >> I am studying at a University in Germany. We started a little project >> which tracks the location of people, connects them and helps them to >> interact on different levels. Well, in the end it will. >> >> We decided to use XMPP as our protocol and as it turns out there is >> almost always an XEP which covers something we want to do. I really >> start liking it. >> >> Since we don't have the capacity to write our own server we decide to >> use an existing one and enhance its features with an external >> component. However, I kinda ran into a problem and I hope you can help >> me out. In the XEP-0114 it says that an external component can do >> things that clients cannot. I tried to find a list of those things but >> till now I wasn't lucky. > > I've ran into a similar use case myself. ? External components don't > have that kind of access. ?An external component basically registers > itself as component.domain.com, and can send and receive messages > from/to all JIDs at that domain (i.e. user1 at component.domain.com, > user2 at component.domain.com, component.domain.com, etc.). ?But the xmpp > server will not route stanzas that are not addressed to the component to > it, nor will the server allow the component to send stanzas addressed > from other domains. > >> There is one special thing my component needs >> to be able to do. I would like my component to listen to buddy >> requests and "buddy acceptances" of clients which are received by the >> server. As far as I know an internal component ?or something like a >> packet interceptor as a plug in which sends the packets on to my >> component could do that. However, before I start writing a plug in for >> a specific server implementation I would like to know if there is a >> way within the specifications of the protocol. >> > > We wrote a plugin for openfire that just forwards stanzas down an XML > pipe over TCP, and use an external (non-XMPP) service to filter out the > stanzas we are interested in using xpath expressions (this was really > easy with twisted words/wokkel). > > Alternatively, you can implement the logic completely inside your plugin. > > I don't think you'll be able to pass stanzas from a plugin or internal > component to an external component directly, the component protocol > doesn't support that. ?If you really want to use an external XMPP > component, I can only think of wrapping your original stanza in another > stanza addressed to the component. > > Good luck, > Ilya Thx a lot for your advice. We decide to send extra messages to the component once the buddy request was accepted. This is not an ideal solution Hwever your implementation is "just" a proof of concept right now. best wishes, Karsten Jeschkies From virgilio.santos at gmail.com Thu Jan 28 10:29:38 2010 From: virgilio.santos at gmail.com (=?ISO-8859-1?Q?Virg=EDlio_Santos?=) Date: Thu, 28 Jan 2010 14:29:38 -0200 Subject: [jdev] [Whack] Tutorials and Client issues Message-ID: Hello, I'm trying to make a qeue and user/message controller to my server users (attendants) interactions with anonymous ones (users). I was thinking on implementing a controller client (kind of "know everybody bot") that handle the qeues and chat redirections but I read about whack and external components to openfire and now I want to know how to do that control directly from a server component (which will probably end the problem the client launching and perhaps even the client life/death/memory leak problems that eventually show up). I was wandering on the ignite pages for whack documentation and some tutorial for dummies to get started on whack developing but I could not find it. Someone know any? Any help will be really big! []'s -- "In July of 2004, Bush told an Amish group in Pennsylvania that "God speaks through me." He believes that God wanted him to be president, and that God is working through him, even as tens of thousands of innocent Iraqi men, women, and children die in a war based on lies." From gato at jivesoftware.com Thu Jan 28 16:10:19 2010 From: gato at jivesoftware.com (Gaston Dombiak) Date: Thu, 28 Jan 2010 22:10:19 +0000 Subject: [jdev] [Whack] Tutorials and Client issues In-Reply-To: Message-ID: Hey Virgilio, Have you checked the Fastpath service plugin available here: http://www.igniterealtime.org/projects/openfire/plugins.jsp ? From your description it seems like you are looking something like that. Regards, -- Gato On 1/28/10 8:29 AM, "Virg?lio Santos" wrote: Hello, I'm trying to make a qeue and user/message controller to my server users (attendants) interactions with anonymous ones (users). I was thinking on implementing a controller client (kind of "know everybody bot") that handle the qeues and chat redirections but I read about whack and external components to openfire and now I want to know how to do that control directly from a server component (which will probably end the problem the client launching and perhaps even the client life/death/memory leak problems that eventually show up). I was wandering on the ignite pages for whack documentation and some tutorial for dummies to get started on whack developing but I could not find it. Someone know any? Any help will be really big! []'s -- "In July of 2004, Bush told an Amish group in Pennsylvania that "God speaks through me." He believes that God wanted him to be president, and that God is working through him, even as tens of thousands of innocent Iraqi men, women, and children die in a war based on lies." _______________________________________________ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: JDev-unsubscribe at jabber.org _______________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomek at xiaoka.com Fri Jan 29 07:39:42 2010 From: tomek at xiaoka.com (Tomasz Sterna) Date: Fri, 29 Jan 2010 14:39:42 +0100 Subject: [jdev] Multiplexing large number of client connections In-Reply-To: <4B5E0FB6.208@stpeter.im> References: <4b5c4085.1c07d00a.04d9.ffffce35@mx.google.com> <4B5D1614.8060009@stpeter.im> <1264454949.7433.25.camel@wing.ordonowny.acn.waw.pl> <4B5E0FB6.208@stpeter.im> Message-ID: <1264772382.6318.1.camel@smoku-desktop> Dnia 2010-01-25, pon o godzinie 14:40 -0700, Peter Saint-Andre pisze: > The multi-resource stuff seemed like a good idea at the time but > people > on the XMPP WG discussion list were concerned about adding complexity. > We could, of course, still define it as an XMPP extension if there's > interest. There is. Dropping it kills private MUC which is an interesting feature for the privacy nuts. Well... it's an interesting feature anyway. :-) -- Tomasz Sterna Xiaoka.com From stpeter at stpeter.im Fri Jan 29 08:52:04 2010 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 29 Jan 2010 07:52:04 -0700 Subject: [jdev] Multiplexing large number of client connections In-Reply-To: <1264772382.6318.1.camel@smoku-desktop> References: <4b5c4085.1c07d00a.04d9.ffffce35@mx.google.com> <4B5D1614.8060009@stpeter.im> <1264454949.7433.25.camel@wing.ordonowny.acn.waw.pl> <4B5E0FB6.208@stpeter.im> <1264772382.6318.1.camel@smoku-desktop> Message-ID: <4B62F614.6000009@stpeter.im> On 1/29/10 6:39 AM, Tomasz Sterna wrote: > Dnia 2010-01-25, pon o godzinie 14:40 -0700, Peter Saint-Andre pisze: >> The multi-resource stuff seemed like a good idea at the time but >> people >> on the XMPP WG discussion list were concerned about adding complexity. >> We could, of course, still define it as an XMPP extension if there's >> interest. > > There is. Dropping it kills private MUC which is an interesting feature > for the privacy nuts. Well... it's an interesting feature anyway. :-) You mean http://xmpp.org/extensions/inbox/private-muc.html I suppose. It's not clear to me if we absolutely need multi-resource support in order to have private MUCs. And I wouldn't want to have a dependency on the server to provide private MUCs anyway. Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6820 bytes Desc: S/MIME Cryptographic Signature URL: From tomek at xiaoka.com Sat Jan 30 10:22:19 2010 From: tomek at xiaoka.com (Tomasz Sterna) Date: Sat, 30 Jan 2010 17:22:19 +0100 Subject: [jdev] Resource binding In-Reply-To: <4B62F614.6000009@stpeter.im> References: <4b5c4085.1c07d00a.04d9.ffffce35@mx.google.com> <4B5D1614.8060009@stpeter.im> <1264454949.7433.25.camel@wing.ordonowny.acn.waw.pl> <4B5E0FB6.208@stpeter.im> <1264772382.6318.1.camel@smoku-desktop> <4B62F614.6000009@stpeter.im> Message-ID: <1264868539.3015.90.camel@wing.ordonowny.acn.waw.pl> Dnia 2010-01-29, pi? o godzinie 07:52 -0700, Peter Saint-Andre pisze: > You mean http://xmpp.org/extensions/inbox/private-muc.html I suppose. > It's not clear to me if we absolutely need multi-resource support in > order to have private MUCs. And I wouldn't want to have a dependency > on the server to provide private MUCs anyway. One may always establish multiple connections to bring up more resources. But I think resource binding is way simpler method. BTW: What was the exact reasons for dropping it? I didn't find it nor confusing, nor hard to implement. Pros: - does not add another flow, just reuse existing one - easy to implement (servers already support one resource bind and multiple connections from one client) - very straightforward once you get what resource bind is (and you need to bind one) Cons: - ??? -- Tomasz Sterna Instant Messaging & EDI Consultant Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/