XMPP makes the smart grid smarter

Interesting article...

http://www.greentechmedia.com/articles/instant-messenger-of-the-smart-grid-6110.html

/psa

[Fwd: [Standards] topics for s2s meeting]

FYI. All are welcome.

-------- Original Message --------
Subject: [Standards] topics for s2s meeting
Date: Mon, 04 May 2009 13:54:00 -0600
From: Peter Saint-Andre <stpeter@...>
Reply-To: XMPP Standards <standards@...>
To: XMPP Extension Discussion List <standards@...>

We will hold a "Monthly XMPP Meeting" tomorrow about server-to-server
communication (dialback, secure multiplexing, etc.). What are the open
issues that we need to discuss? Feel free to ping me on or off list with
your suggestions.

Time: 19:00 UTC
Place: xmpp:jdev@...
Calendar: http://xmpp.org/xsf/XSF.ics

Peter

[ANN] Prosody 0.4.1 Released

We are pleased to announce the release of Prosody 0.4.1.

Although the version number may make this appear a "minor" release,
it is far from that. Although real feature development has still
been going on in the main branch, we have put a lot of work into
polishing Prosody's integration with the system. Hence 0.4.1 has
in addition to bugfixes, much improved logging, signal handling,
and a new 'prosodyctl' utility.

In addition the Debian package has received a lot of attention, now
complete with a fully-functioning init script, and creating a new user
account for Prosody.

Prosody is a lightweight Jabber/XMPP server written in Lua. It aims
to be flexible, easy to extend, and simple to use for both users
and developers alike.

The following is a summary of changes since the previous version:

   * Revamped logging system, now much more flexible
   * Fix broken presence stanzas sometimes coming from MUC
   * Add a dataforms lib for modules to use
   * Always send </stream:stream> when a stream is closing
   * Non-blocking DNS lookups integrated into s2s
   * Much cleaner XEP-0114 implementation internally
   * Fix incorrect routing of some type=error presence stanzas
   * Allow mod_debug and mod_console to run alongside each other
   * Don't try to use SSL when it is configured but not installed
   * Allow greater control over the listening network interfaces
   * Support for handling POSIX signals, clean shutdown on SIGTERM

Subject: PubSub administration example [Celebrating the 30th subscriber of bbc_news ]

]

Hi,

Since there is now 30 subscribers in the bbc-news -service
(http://www.lobstermonster.org/post/xmpp-pubsub-service-to-publish-bbc-world-news)
and almost beating Facebook in popularity, I thought why not to do a
simple administration tool to manage PubSub subscriptions and create
other similar services.

This tool is done very fast and in the beginning it was ment to serve
one purpose only. So don't complain too much :-D I have also only
tested Firefox 3.1b3. IMPORTANT: IE WILL NOT WORK since the use of
getElementsByTagNameNS -javascript DOM function.

If you have read this far, Please find the tool here:
http://www.lobstermonster.org/examples/pubsubManager/

With this very simple tool you can:
    * Create/delete/View -PubSub Nodes
    * Create/delete/view -PubSub Items
    * Delete/view subscriptions of Nodes

When you access the service, it logs in automatically as a predefined
test user who has all the rights to create/delete/view PubSub nodes
and create items in them. So be free to create your own node and
publish items in it using the tool provided. Specially new users who
are interested of PubSub and want to know more of it, good option is
to install Psi, enable it's XML console and subscribe to a node
created and see what's going on. (Keep in mind that the server is
Openfire 3.6.4 so it might have it's own special behavior for some
cases).

Regarding XMPP Voice Message Processing

_______________________________________________
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
_______________________________________________

Re: Regarding XMPP Voice Message Processing

Hello

On Sun, May 10, 2009 at 05:52:12PM +0800, 周聪伟 wrote:
>     As everybody know, the Mobile GPRS bandwidth is very sensitive, so the scenario will be like this:
>     1. Mobile Record the voice as one buffer or file in AMR codec.
>     2. Client A, send this data to Client B （maybe put the data into special message stanza）, the data
should be sent to the server first (as all message will through server transfer to another client)
>     3. The XMPP server will not directly send the data to Client B first, but story the data, and notify the
Client B, now there is one voice data coming to you(including Client As's JID, time stamp, and maybe voice
message ID, etc)
>     4. Client B if want to receive the voice message, then send the request to the XMPP server, then the XMPP
server will push the voice data to Client B.

Why store it on the server? Why not negotiate the „do you want to get
the message now?“ with the other client and then use a file transfer to
get it there?

With regards

--

-- 
2 keys should be enough for everyone

Michal 'vorner' Vaner

_______________________________________________
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
_______________________________________________

Re: Regarding XMPP Voice Message Processing

Am 10.05.2009 um 11:52 schrieb 周聪伟:

> maybe we can encode the voice data to Base64.

This sounds horrible, especially for mobile use. It really is the  
worst case there! Base64 makes data about 1/3 bigger and with GPRS,  
every byte counts.

You should instead have a bot which you can tell you want to receive  
it and then it sends it for example as a file using a SOCKS proxy or  
you could even use Jingle.

--
Jonathan

_______________________________________________
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
_______________________________________________

Re: Regarding XMPP Voice Message Processing

> On Sun, May 10, 2009 at 05:52:12PM +0800, ??? wrote:
>>     As everybody know, the Mobile GPRS bandwidth is very sensitive, so the scenario will be like this:
>>     1. Mobile Record the voice as one buffer or file in AMR codec.
>>     2. Client A, send this data to Client B ?maybe put the data into special message stanza?, the data should be
sent to the server first (as all message will through server transfer to another client)
>>     3. The XMPP server will not directly send the data to Client B first, but story the data, and notify the
Client B, now there is one voice data coming to you(including Client As's JID, time stamp, and maybe voice
message ID, etc)
>>     4. Client B if want to receive the voice message, then send the request to the XMPP server, then the XMPP
server will push the voice data to Client B.
> 
> Why store it on the server? Why not negotiate the ?do you want to get
> the message now?? with the other client and then use a file transfer to
> get it there?
> 
> With regards

Hi Michal 'vorner' Vaner:
        One thing is we don't want to Client to Client do the transfer voice data or file
        Because: 1. Some times the persion is not online
                           2. In GPRS connection,I think the P2P is not very good solution for transfer the short voice message.
                           3. If use the server side, server side can setup the Socket listen port, 
                               and client can send the data to it fast as can do the connection very fast. 
                                but if use the P2P it will need some time to setup the communication.

        So we are thinking through the server side to transfer the voice data.

        now we have the private IM application (include the client side and server side), we're thinking  go to XMPP.

        The flow in our application now is as below:
        1. First Client A setup the connection with Server, login
        2. Get the list of friends, check the online frends, etc
        3. Client A select one friend, chose send voice message
        4. Start the voice record, voice will record as one AMR file
        5. Send the AMR data to server
        6. Server will check the destination user status, see wether it's online or not. 
        7. If the dest-user online, server will send the notification to him, "one voice message, do you want to
receive? "
        8. If it chose receive, then server will send the voice data to it.
        9. All these communication base on socket communication.

        So now we're finding the solution on XMPP.... how we can do? thanks very much

Regards
Charles

----- Original Message ----- 
From: <jdev-request <at> jabber.org>
To: <jdev <at> jabber.org>
Sent: Monday, May 11, 2009 1:00 AM
Subject: JDev Digest, Vol 64, Issue 6

> Send JDev mailing list submissions to
> jdev <at> jabber.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.jabber.org/mailman/listinfo/jdev
> or, via email, send a message with subject or body 'help' to
> jdev-request <at> jabber.org
> 
> You can reach the person managing the list at
> jdev-owner <at> jabber.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of JDev digest..."
> 
> 
> Today's Topics:
> 
>   1. Regarding XMPP Voice Message Processing (???)
>   2. Re: Regarding XMPP Voice Message Processing
>      (Michal 'vorner' Vaner)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sun, 10 May 2009 17:52:12 +0800
> From: ??? <zcw <at> mypmlive.com>
> Subject: [jdev] Regarding XMPP Voice Message Processing
> To: <jdev <at> jabber.org>
> Message-ID: <C8E9B77A43D44D71B8CBD892CEACC3B0 <at> zsxcharles>
> Content-Type: text/plain; charset="gb2312"
> 
> Hi All:
>    We want to develop the IM application base on XMPP, and the Client application will run on the Mobile
OS(such as Symbian, Windows Mobile, J2ME, etc). 
>    Now I am facing one problem about the voice message:
>    We hope our application can send the voice message(like Voice SMS), from one client to another client
through the Server, maybe we can encode the voice data to Base64.
>    The server, we're planing to use OpenFire.
> 
>    As everybody know, the Mobile GPRS bandwidth is very sensitive, so the scenario will be like this:
>    1. Mobile Record the voice as one buffer or file in AMR codec.
>    2. Client A, send this data to Client B ?maybe put the data into special message stanza?, the data should be
sent to the server first (as all message will through server transfer to another client)
>    3. The XMPP server will not directly send the data to Client B first, but story the data, and notify the
Client B, now there is one voice data coming to you(including Client As's JID, time stamp, and maybe voice
message ID, etc)
>    4. Client B if want to receive the voice message, then send the request to the XMPP server, then the XMPP
server will push the voice data to Client B.
> 
> 
>    This is our idea, but we didn't know how we can do and use which protocols. is anybody can help us. Thanks very much.
> 
> 
> Regards
> Charles
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090510/fe40afcd/attachment.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Sun, 10 May 2009 12:32:39 +0200
> From: Michal 'vorner' Vaner <vorner <at> ucw.cz>
> Subject: Re: [jdev] Regarding XMPP Voice Message Processing
> To: Jabber/XMPP software development list <jdev <at> jabber.org>
> Message-ID: <20090510103239.GA31379 <at> tarantula.kolej.mff.cuni.cz>
> Content-Type: text/plain; charset="utf-8"
> 
> Hello
> 
> On Sun, May 10, 2009 at 05:52:12PM +0800, ??? wrote:
>>     As everybody know, the Mobile GPRS bandwidth is very sensitive, so the scenario will be like this:
>>     1. Mobile Record the voice as one buffer or file in AMR codec.
>>     2. Client A, send this data to Client B ?maybe put the data into special message stanza?, the data should be
sent to the server first (as all message will through server transfer to another client)
>>     3. The XMPP server will not directly send the data to Client B first, but story the data, and notify the
Client B, now there is one voice data coming to you(including Client As's JID, time stamp, and maybe voice
message ID, etc)
>>     4. Client B if want to receive the voice message, then send the request to the XMPP server, then the XMPP
server will push the voice data to Client B.
> 
> Why store it on the server? Why not negotiate the ?do you want to get
> the message now?? with the other client and then use a file transfer to
> get it there?
> 
> With regards
> 
> -- 
> 2 keys should be enough for everyone
> 
> Michal 'vorner' Vaner
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 198 bytes
> Desc: not available
> URL: <http://mail.jabber.org/pipermail/jdev/attachments/20090510/aa785dd5/attachment-0001.pgp>
> 
> ------------------------------
> 
> _______________________________________________
> JDev mailing list
> JDev <at> jabber.org
> http://mail.jabber.org/mailman/listinfo/jdev
> 
> 
> End of JDev Digest, Vol 64, Issue 6
> ***********************************
> 
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 4061 (20090507) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.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
_______________________________________________

Re: Regarding XMPP Voice Message Processing

> -----Original Message-----
> From: jdev-bounces <at> jabber.org [mailto:jdev-bounces <at> jabber.org] On
> Behalf Of Charles Zhou
> Sent: 11 May 2009 10:43 AM
> To: jdev <at> jabber.org
> Subject: Re: [jdev] Regarding XMPP Voice Message Processing
> 
> [...]
> 
>         The flow in our application now is as below:
>         1. First Client A setup the connection with Server, login
>         2. Get the list of friends, check the online frends, etc
>         3. Client A select one friend, chose send voice message
>         4. Start the voice record, voice will record as one AMR file
>         5. Send the AMR data to server
>         6. Server will check the destination user status, see wether
> it's online or not.
>         7. If the dest-user online, server will send the notification
> to him, "one voice message, do you want to receive? "
>         8. If it chose receive, then server will send the voice data to
> it.
>         9. All these communication base on socket communication.
> 
>         So now we're finding the solution on XMPP.... how we can do?
> thanks very much

Back in the day XMPP transfers were facilitated with FTP/HTTP. Both are *really* easy to implement
(especially HTTP - as it probably has a client library on your platform). You also still get the delayed
delivery. I can't remember the XEP; but I am sure someone else on the list could fill you in.

1. First Client A setup the connection with Server, login.
2. Get the list of friends, check the online friends, etc.
3. Client A select one friend, chose send voice message.
4. Start the voice record, voice will record as one AMR file.
5. Upload AMR to server over HTTP/FTP.
   i. If HTTP the server responds with the URL to the file.
   ii. If FTP you will first need to communicate with an XMPP component to get the file name to use.
6. Send a <message> to the other user; and include the upload URL (you will need to refer to the XEP for the
element to use).
7. According to the normal <message> processing rules the message will be delivered when the destination
is online.
8. They can then choose to download the message at any time. The XMPP server is not responsible for sending it
- the HTTP/FTP one is.
   i. The HTTP/FTP server could delete the message automatically when it is successfully downloaded.

There is a further benefit to using HTTP - GPRS networks are often shaped; so anything over port 80 will be
faster than the rest.

> 
> Regards
> Charles
> 

_______________________________________________
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
_______________________________________________

Re: Regarding XMPP Voice Message Processing

On Mon May 11 09:42:36 2009, Charles Zhou wrote:
>         So now we're finding the solution on XMPP.... how we can  
> do? thanks very much

You're describing a store-and-forward messaging system.

That's not what XMPP is, although you obviously need tight  
integration to presence, and a notification system, too, and XMPP  
will come in useful for that.

But I'd suggest you take a close look at the VPIM work done by the  
IETF for the actual voice messaging, since that's very much what it  
was designed for. I think that implementations exist, too, in pretty  
wide deployment.

Linking together XMPP and IMAP/SMTP - which is what VPIM is based on  
- would be a welcome bit of work to get done, too.

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
_______________________________________________
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
_______________________________________________