http://docs.urbanairship.com/api/ua.html#push-report
Browsing over the above site, there's several ways of getting push reports. However I want to get a list of send push messages, including the deeplink that was associated with it.
Like http://docs.urbanairship.com/api/ua.html#response-listing, but with its payload (push text, deeplinks etc.).
I know this is possible though the urban airship admin-interface (push log), however is it possible through the API?
Any experience or pointers would be greatly appreciated.
The full push payload is available via the Push Body Event. These events are accessible via the Connect product.
Retaining long-lived API-accessible push payloads is much more resource intensive than retaining short-lived admin-accessible push payloads. This is a likely reason for including Push Body Events in the Connect product instead of including them in the free plan.
Related
We want to use ejabberd in the context of a web application having fairly unique and business rules, we'd therefore need to have every chat message (not protocol message, but message a user sends to another one) go through our web application first, and then have the web application deliver the message to ejabberd on behalf of the user (if our business rules allow the message to be sent).
The web application is also the one providing the contact lists (called rosters if I understand correctly to ejabberd). We need to be and remain the single source of truth to ease maintenance.
To us, ejabberd value added would be to deliver chat messages in near real-time to clients, and enable cool things such as presence indicators. Web clients will maintain a direct connection to ejabberd through websocket, but this connection will have to be read-only as far as chat messages are concerned, and read-write as far as presence messages are concerned.
The situation is similar with regards to audio and video calls. While this time the call per see will directly be managed by ejabberd to take advantage of built-in STURN, TURN etc... and will not need to go through our web app, we have custom business logic to manage who is able to call who, when, how often etc... (so in order words, we have custom business logic to authorize the call or not and we'd like to keep all the business logic centralized in the web app).
My question is what would be the proper hooks we'd need to look into to achieve what we are after? I spent an hour or so in the documentation, but I couldn't find what I am after so hopefully someone can provide me pointers. In an ideal world, we'd like to expose API endpoints from our web app that ejabberd hooks can hit. However, the first question is: which relevant hooks is ejabberd offering and where are these hooks documented?
Any help would be greatly appreciated, thank you!
When a client sends a packet to ejabberd, it triggers the user_send_packet hook, providing the packet and the state of the client's session process. Several modules use that hook, for example mod_service_log.
I have been looking everywhere for a solution to this problem.
At my work, we are trying to integrate Maximo with another system via the other systems REST API (which returns JSON responses). I am able to make this integration work on a small scale, however this API is taking upwards of 5 seconds to respond per request. Currently, I have defined this system as a JSON Resource, and I copy daily "snapshots" of the non-persistent data to a persistent attribute using an automation script. The requests all run in a sequence - which works slowly for 5 assets in testing, and will definitely not scale to 1000's of calls a day.
Assume that the API of the external system cannot be modified in any way... Is there a way to query this API in a non-blocking way? I'd imagine that if I could send a request, and send the next, etc. without needing to wait for a reply to proceed, this would solve the problem.
I looked into Invocation and Publishing Channels, and also Enterprise Services, and it seems like Enterprise Services along with JMS Queues might be what I need, however documentation says that these only support queuing incoming data... and I can't see how this solves my problem.
Any help? I am completely stuck on this.
Thank you!
I had to do something that sounds similar, once. I tried JSON Resources, but they didn't work for me. I ended up using the examples in Maximo 7.6 Scripting Features to do it. The first code sample in that document is a library script for making HTTP/S calls using out-of-the-Maximo-box libraries, and other examples in that document use IBM's JSONObject and JSONArray classes (also available out of the Maximo box) to parse responses.
To get things going concurrently / multithreaded, you could configure a cron task to call your automation script, and configure multiple instances on various schedules to call the same one and use the args or some other mechanism to prevent collisions.
I have an instant messaging application almost complete the only thing I'm missing are firefox notifications for you. As is the API?
It's not clear if you're after Notifications API or Push Notifications API, so I'll talk about both.
First, the Notification "API" (I'm not sure if it's been renamed to be an API, and I'm afraid it's just known as "Notification" by now). You can use mozNotification to create new notification objects and use show to display them:
var notification = navigator.mozNotification;

var n = notification.createNotification("Title", "Body", "optional_icon.png");
n.show();
On both links, you can get a better understanding what can be done with this.
Be sure you ask for permission to use this (add this to your manifest.webapp):
"permissions": {
"desktop-notification":{}
}
To make it easier, I've made a demo app. That a look at how it works, and the changes I've made.
Warning: this is different from Web Notifications.
The Push API is already listed on Mozilla Wiki, but it's work in progress AFAIK. You can follow the news on this specific API on Mozilla Wiki, on github (server side stuff) and on the Gecko implementation bug.
There's another API, the SimplePush API, that seems to be working by now. Unfortunately, I don't know much about it. But at least the documentation seems pretty good.
Unfortunately again, I don't know how those APIs relate to W3C's Push API. I'm afraid the Push API is somewhat related to the standard, although I'm not sure of that. I wouldn't rely on any other documentation besides Mozilla's, in the case of these APIs.
For server based push notifications see Simple Push that includes implementation examples. This is available in Firefox OS (/Boot2Gecko) 1.1. but not in 1.0 (which is on all currently released devices).
Please also note, that you'll need a real device and it won't work in the emulator.
Simple Push itself is not difficult to implement given the above link. Nevertheless there a couple of things you need to take care about:
you need your own server that will trigger Firefox's server on demand for a push
the push received on the device does not contain any information (this means you'll have to query needed information after receiving the push)
the push received is silent and invisible - that means you'll have to display a desktop notification yourself as described above
the push endpoint has to be the same page as your launch_path from the manifest (this means you'll have to put all the logic in one page) due to a bug
make sure you'll acquire a wake lock after receiving the push and release it after your work is done - this way the device will not fall to deep sleep and your push processing is paused in the middle of it
It is possible to build similar functionality on Boot2Gecko 1.0 using MozAlarmsManager.
The documentation (http://developers.box.com/webhooks/) talks about webhooks in the context of "user's account". I read that as getting notifications only about the objects to which I have access.
Let's say I want to be notified every time there is a new upload anywhere across my organization. Do I need to be an admin to accomplish this, or is the webhooks scope not subject to my user permissions?
While we're continuing to enhance webhooks, there is some administrative functionality built-in. For instance, if you can get your webhooks installed for all your users, and have the webhook point to one endpoint, that can track all activity in your account.
There is a way to force webhooks on all users in your domain as an administrator. However, this feature hasn't been optimized for companies that use webhooks for internal use. That's still in progress.
If you'd like to be kept in the loop, or try some workarounds with what we have, feel free to contact us at api [at] box [dot] com. With more information, we may find something that works today, based on your exact needs.
At this point, the webhooks are only provided at the user level. If you log on as an admin and setup an application that gets webhooks, you will only get the same set of notifications as you see in the "Updates" tab in the Web UI.
We are looking to expand the webhooks capabilities, and this is one area that we may explore. However, it is not currently scheduled, so I can't provide any idea of even rough dates.
I would like to learn what are the scenarios/usecases/ where messaging like RabbitMQ can help consumer web applications.
Are there any specific resources to learn from?
What web applications currently are making use of such messaging schemes and how?
In general, a message bus (such as RabbitMQ, but not limited to) allows for a reliable queue of job processing.
What this means to you in terms of a web application is the ability to scale your app as demand grows and to keep your UI quick and responsive.
Instead of forcing the user to wait while a job is processed they can request a job to be processed (for example, clicking a button on a web page to begin transcoding a video file on your server) which sends a message to your bus, let's the backend service pick it up when it's turn in the queue comes up, and maybe notify the user that work has/will begin. You can then return control to the UI, so the user can continue working with the application.
In this situation, your web interface does zero heavy lifting, instead just giving the user visibility into stages of the process as you see fit (for example, the job could incrementally update database records with the state of process which you can query and display to your user).
I would assume that any web application that experiences any kind of considerable traffic would have this type of infrastructure. While there are downsides (network glitches could potentially disrupt message delivery, more complex infrastructure, etc.) the advantages of scaling your backend become increasingly evident. If you're using cloud services this type of infrastructure makes it trivial to add additional message handlers to process your jobs by subscribing to the job queue and just picking off messages to process.
I just did a Google search and came up with the following:
Reddit.com
Digg.com
Poppen.De
That should get you started, at least.