My company was using a third party tool to download print jobs from Google. This has developed problems so we've written our own. We can register a printer, get notifications via XMPP and download jobs. All good. We'd like to download jobs from the printers already registered via the the third party tool.
We have successfully got the permission of the google account that owns the printer to manage its printers and subsequently downloaded jobs from the printer. This was achieved using a solution that issued /fetch api calls every minute. Of course, Google wants the XMPP method used so we tried to do that. After getting over an authentication issue by adding googletalk to the scope in the oAuth request we fail to get any notifications.
In summary, with our own printer we can fetch, download and get XMPP notifications but with the printer registered with the third party tool (where we don't know the client id and secret but do know the google account) we can fetch and download but not get XMPP notifications. Is there any way round this?
The XMPP messages go to the robot account that owns the printer, so I don't think you should expect to receive XMPP messages without that robot account (and corresponding XMPP JID).
Rather than work around the intentions of the API, I suggest you work with the third party. Maybe they can provide hooks into their notification queue?
Related
i'm developing an android application that will send notifications to users, one of the ways it notify is via skype, i need to know the user's status to trust that the user is going to read the message since it seems i can send skype messages even when the target user is offline.
im using https://docs.botframework.com/en-us/restapi/connector/ bot's API to send the messages
¿is there anyway to get the current status(online, away, etc..) of an especific skype user?
since it seems they no longer offer "mystatus.skype.com" service.
We are developing a consumer hardware product. Each device is registered on a central webserver and the owner also have a user account to which the device is linked. The owner may also choose to share the device with other users.
Now, to solve the problem of getting through firewalls etc we are using XMPP: the user access his/her devices using an iOS/Android app. The app connects to the XMPP-server and so does the hardware devices. So the app can access the devices by sending custom XMPP stanzas.
Currently the device and the mobile app use the same JID, so the device will allow messages only from the same bare JID as itself uses. To allow for sharing devices we are planning to use the roster instead: the device will get its own JID ("hw381983829#thexmppserver.com") and will accept stanzas from all JID's in its roster.
The problem I'm having is that the users, devices and device-sharing data are stored on the webserver. I would like to use this same information on the XMPP-server: all users and devices on the webserver are allowed to login to XMPP and the roster of a device is the same as the users that may access it. This information can be accessed through a JSON API.
One way would be to mirror changes as they happen, but I don't like that idea since there are too many steps that could go wrong.
The best solution I can think of is to let the XMPP server use the JSON API instead of its builtin database. It would be read-only, but that is not a problem since all registration and sharing should be done on the webserver.
Any ideas on how to proceed? The functionality described above is more or less all that we need: we don't need S2S, offline messages, etc. We are currently using Ejabberd, but Prosody or Openfire are perhaps better alternatives?
For authentication, it looks like this ejabberd contribution does exactly what you need:
https://github.com/processone/ejabberd-contrib/tree/master/ejabberd_auth_http
For roster, it is easy to write a custom roster module that will be hitting your HTTP backend instead of query the database thanks to ejabberd API.
You can have a look at mod_roster as a guide to implement the methods: https://github.com/processone/ejabberd/blob/master/src/mod_roster.erl
We've written an application to replace a third party tool to download and print jobs through Google Cloud Print. For new customers this will work well. We create the printer in the cloud and download jobs. It works. Customers up and running with the third party tool are using a printer created with that tool. I thought I'd be able to access that printer's jobs by getting the user to go through oauth authentication to give our application the permission to manage the user's printers. However, having done this and all seeming to work when I fetch jobs from that printer the response is that there are no jobs. But there is a job. Is this behaviour to be expected. Is there any way around this? We'd just like to avoid our customers having to create new printers.
The question is a little unclear; feel free to edit your question and I'll edit this answer.
Being able to manage jobs is not the same as being able to download jobs. Each printer belongs to a user, and each has a robot account. Only those two accounts (I believe) can download the job ticket and payload.
After a job is marked as completed (through the /control API), the payload is deleted.
A third user account that can manage jobs is allowed to view information about the job, as well as cancel/delete the job, but can't (I believe) download the job payload.
I want to allow people to privately share data with each other using their contacts list to select people to share with. I'm planning on using Push Notifications to notify others that they have been shared with, but how can I handle those that do not have the app installed?
The cases are that I have their phone # and/or email. I can simply send them a message saying "X wants to share Y with you", but how can I determine if I need to send a Push Notification or an email/text?
If you're looking for API then you're out of luck. You can always collect this personal data server-side with agreement of your users. There you can also manage groups and other community relations.
Check here:
https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
The crux of it though will be that you will need to store a token when the device is registered anyway to be able to send notifications to them, so you can use that.
And using The Feedback Service alluded to in the documentation, you can remove the token, should it fail too often.
But, as rokjarc said, if you're expecting a third-party API to exist, you're pretty much out of luck. Apple ahs done most of the work for you already anyway.
When the app registeres for push notifications you need to pass additional data to your server. The user could input their own email/phone which will be sent to the server so that users can find each other. The email/phone can be stored alongside with the push token. When someone wants to share something, you would search the corresponding push token in the database and send the notification through APNS. Note there can be multiple push tokens for one email or phone i.e. when a user has multiple devices.
The users of your app should be aware of the data which is stored on your server and should have the option to delete it. Also use the APNS feedback service to detect and remove invalid push tokens.
I want to integrate my web application with chat and notification service and the foremost and the best, i understand is XMPP. After going through the nitty gritties, though i understood most of it but I got stuck here i.e. how will i run a Chat and notification service together.
One option is to have run different connections of Strophe, long polling with different accounts one for chat and other for notifications.
Other one is to have both notifications and chat on the same accounts but now the problem if the user signs out from chat he wont be able to receive notifications.
The first option does not seem feasible to me, but is there a way the later one could work?
Use one connection, to your "chat" service. Run your notification service as a component on your chat server, or run a separate server and federate them together. The client will be able to contact the notification service (and vice-versa) via the naming scheme in the Jabber ID's (JIDs) that you pick. Make sure you pick a different domain name for the user accounts on the chat side than for the notification service.