In the App Engine docs, a JID is defined like this:
An application can send and receive
messages using several kinds of
addresses, or "JIDs."
On Wikipedia, however, a JID is defined like this:
Every user on the (XMPP) network has a unique
Jabber ID (usually abbreviated as
JID).
So, a JID is both a user identifier and an application address?
A JID is globally unique in that anyone sending an XMPP message as you#domain.com can be you.
However, an App Engine app can send XMPP messages as any number of JIDs.
Your app can send XMPP messages as your-app-id#appspot.com or as foo#your-app-id.appspotchat.com or as bar#your-app-id.appspotchat.com or as anything#your-app-id.appspotchat.com.
These IDs are still globally unique and identifying -- anyone sending an XMPP message as foo#your-app-id.appspotchat.com can be assumed to be your app.
Since I happened to have this up in my browser, the current best canonical definition of JIDs is here: draft-saintandre-xmpp-address, which just got pulled out of RFC3920bis.
Related
I've got an app that's sending email from AppEngine, but each email looks like it's a unique message. Instead I want related emails to be threaded in my email client. Is there a specific header/format I need to use?
These emails are not necessarily in response to another email, so I don't have a Message-ID to plug into References. I've tried using a natural key in References and In-Reply-To to no avail.
I was able to thread a list of emails just by using the In-Reply-To header with your format <msg-identifier#host>.
Supposedly, msg-identifier is the identifier to the message you're replying to, but as you're not replying to any message but sending all of them out of thin air, creating a new ID and using it in all the emails you send will also do the trick.
I got this working by using both References and In-Reply-To with the format <identifier#systemname>. Maybe it'll work with less; I made several changes at once. If someone chimes in with that kind of detail I'll happily accept their answer instead of mine.
I have use Outbound Message in salesforce. When the Trigger is Occur on the particular object outbound Message to pass particular End URL. here I want to receive the Outbound Message from the Mulesoft(EndPoint URL) . I have tried HTTP,UDP,TCP,Genric these Kind of endpoint URL but its not working. How i can Use the Mulesoft end point URL. by using Local host its possible or not. Because I have used Localhost:8081 this kind of URL only. what are all the way i have to receive salesforce outbound Message. Thanks
The target of the outbound message must be accessible from the web. It has to have some meaningful domain name or IP address (and if you're behind a firewall you need to allow messages from SF pool of IP addresses to pass through).
http://wiki.developerforce.com/page/Creating_an_Outbound_Messaging_Notification_Service_with_Eclipse_3.2#Testing_Your_Service
Testing can be a bit of a tricky wicket if you are not developing on a
machine that is accessible from the internet. Following the sample, we
have deployed our web service to localhost:8080. It is not possible
for the salesforce.com servers to make a request to that address.
I created a working Google Channel AP and now I would like to send a message to all clients.
I have two servlets. The first creates the channel and tells the clients the userid and token. The second one is called by an http post and should send the message.
To send a message to a client, I use:
channelService.sendMessage(new ChannelMessage(channelUserId, "This is a server message!"));
This sends the message just to one client. How could I send this to all?
Have I to store every Id which I use to create a channel and send the message for every id? How could I pass the Ids to the second servlet?
Using Channel API it is not possible to create one channel and then having many subscribers to it. The server creates a unique channel for individual JavaScript clients, so if you have the same Client ID the messages will be received only by one.
If you want to send the same message to multiple clients, in short, you will have to keep a track of active clients and send the same message to all of them.
If that approach sounds scary and messy, consider using PubNub for your push notification messages, where you can easily create one channel and have many subscribers. To make it run on Google App Engine is not that hard, since they support almost any platform or device.
I know this is an old question, but I just finished an open source project that uses the Channel API to implement a publish/subscribe model, i.e. you can have multiple users subscribe to a single topic, and then all those subscribers will be notified when anyone publishes a message to the topic. It also has some nice features like automatic message persistence if desired, and "return receipts", where a subscriber can be notified whenever OTHER subscribers receive that message. See https://github.com/adevine/gaewebpubsub#gae-web-pubsub. Licensed under Apache 2.0 license.
In Google App Engine documentation for Channel API, it is stated that "Only one client at a time can connect to a channel using a given Client ID".
In contradiction, when I try to create a channel with the same Client ID, a new channel is consumed. In other words, when I call creat channel api for ClientID "user_one" channelService.createChannel("user_one"); for ten times, 10 different channels with 10 different token strings would be created, and when I send a message to "user_one" channelService.sendMessage(new ChannelMessage("user_one", message));, all of the ten clients on different devices, would receive the message!
How would you describe this scenario ? How one can benefit from this mechanism (one clientID with different channel, all receiving same message)? how to prevent it from creating multiple channel for single user ?
The documentation is not complete but it describes its intent pretty well. It says:
Only one client at a time can connect to a channel using a given Client ID, so an application cannot use a Client ID for fan-out. In other words, it's not possible to create a central Client ID for connections to multiple clients (For example, you can't create a Client ID for something like a "global-high-scores" channel and use it to broadcast to multiple game clients.)
It's up to you to keep track of the of the number of channels you create for each ClientID. From my experience, what you describe works, but not reliably. The newest channel created with the ClientID works, the older ones, sometimes work, sometimes don't receive messages.
Note that if you're trying this out on the dev_appserver, all the clients receive messages, but on the real server this behavior is not the same.
One of my clients uses Trend Micro InterScan Messaging Security to protect their internal mail services.
Suddenly InterScan decided to filter out all messages coming from Google App Engine.
Unfortunately they haven't been able to whitelist the sender address as each e-mail gets a different one. For example, *3ckihSOVMMHlZHSL.JSMMHlZHSL.JS*#apphosting.bounces.google.com, with everything before the # being variable.
Update I'm including this screenshot of how Interscan sees the incoming e-mail. Notice that all senders are different:
If I look into the e-mail headers, the apphosting domain appears inside the Return-Path field:
Return-Path: <36kSiSwYIBh0883XL3E7.5EH883XL3E7.5E#apphosting.bounces.google.com>
The "From" field looks ok. It says what I set it to say, but the spam filter only looks at the Return-Path.
My client sysadmin doesn't want to whitelist the whole apphosting domain, as it wouldn't be only whitelisting my application.
How could I bypass this e-mail filters if I can't get an unique sender?
Thanks,
You can't change the return-path header of mail sent by App Engine. The way I see it, you have two options:
Whitelist everything from App Engine. Spam from App Engine is not a big problem, because it's expensive to send in the huge numbers spammers need, and we're constantly monitoring for spamming and shutting spammers down.
Whitelist based on the X-Google-Appengine-App-Id header, which will be set to the app ID of your app.
I am not well versed in spam filters, but it seems to me that if it can only whitelist based on one field, it is pretty lame. Unfortunately that does not help you. If this is an important client, and they absolutely refuse to budge, I see two possible paths forward:
Do some research into interscan to see if you can give the client some pointers (tactfully) on how to configure it to whitelist in such a way that your mail can get through, but only your mail.
Maintain a server outside app engine specifically for the purpose of sending emails. You can build a super simple web app that just sends out emails, and call it from within your app engine app.