I want to check anyone phonenumber's online status by query from serverside without any notice to user. Is it even possible?
An operator can see the latest location updates etc from a mobile device, but I am guessing this is not your use case.
To do it as a third party service, you would need to either implement an instant messaging like availability service or leverage or extend an existing open source one like Tox (https://tox.chat), Telegram (https://telegram.org), Linphone (http://www.linphone.org) etc.
Related
So far, based on my understanding of OpenStack Python SDK, I am able to read the Hypervisor, Servers instances, however, I do not see an API to receive and handle the change notification/events for the operations that happens on the cluster e.g. A new VM is added, an existing VM is deleted etc.
There is a similar old post (circa 2016) and I am curious if there have been any changes in Notification handling?
Notifications to external systems from openstack
I see a documentation, which talks about emitting notifications over a message bus that indicate different events that occur within the service.
https://docs.openstack.org/ironic/latest/admin/notifications.html
I have the following questions:
Does Openstack Python SDK support notification APIs?
How do I receive/monitor notifications for VM related changes?
How do I receive/monitor notifications for compute/hypervisor related changes?
How do I receive/monitor notifications for Virtual Switch related changes?
I see other posts such as Notifications in openstack and they recommend to use Ceilometer project, which uses a Database. Is there more light-weight solution than using a completely different service like Ceilometer?
Thanks in advance for your help in this regard.
As far as I see and I know, Openstack SDK doesn't provide such a function.
Ceilometer will also not help you. It only collects data by polling and by notifications over RPC. You would still have to poll the data from ceilometer by yourself. Beside this, ceilometer alone has the problem, that it only grow and will blow up your database, that's why you should also use gnocchi, when you use ceilometer.
At the moment I see only the 3 possible solutions for you:
Write your own tool, which runs permanently in the background and collect the data in a regular interval over OpenstackSDK and REST-API requests.
Write something, which does the same like ceilometer by reciving notifications over oslo-messaging (RPC). See the oslo_messaging_notifications-section in the configs: https://docs.openstack.org/ocata/config-reference/compute/config-options.html#id35 (neutron has also such an option) and use messagingv2 as driver like ceilometer does. But be aware here, that not every event creates a notification. The list of the ceilometer meter-data should give a good overview of which event are creating a notification and what can only be collected by polling: https://docs.openstack.org/ceilometer/pike/admin/telemetry-measurements.html. The number of notification-events is really low, so its possible, that it doesn't provides all events you want.
Use in the oslo_messaging_notifications-section in the configs log as driver to write the notification in a log-file, and write a simple program to read the log-file and process or forward the read content. Here is the same problem like in number 2, that not every event creates a notification (log-entry in this case here). This has also the problem, that the notifications and so also the event-logs, are created on the compute-nodes (as far as I know) and so you would have to watch all compute-nodes by your tool.
Based on the fact, that I don't know, how much work it would be to write a tool to collect notifications over RPC and because I don't know, if all events you want to watch really creates a notification (base on the overview here: https://docs.openstack.org/ceilometer/pike/admin/telemetry-measurements.html), I would prefer number 1.
Its the easiest way to create a tool, which runs GET-Requests over REST-API in a regular interval and forward the results to the desired destination as your own custom notifications.
I followed the below references to get this working. Also, chatted with the author of this code and video.
https://github.com/gibizer/nova-notification-demo/blob/master/ws_forwarder.py
https://www.youtube.com/watch?v=WFq5JWXa9AM
In addition, I faced other issues:
By default, OpenStack server would not allow you to connect to RabbitMQ bus from remote host because of an IPTABLE rule. You will have to enable access to the RabbitMQ Port in the IP table.
I have a use case where I want to build a portal for Agent Login and Registry and allow conversation to be transferred from Bot to an agent.
Looking at this article for possibilities -
https://blogs.msdn.microsoft.com/jamiedalton/2017/08/10/microsoft-bot-framework-handing-off-to-a-human-for-agentssupervisors-with-c-and-the-botbuilder-sdk/
The handoff should happen from customer using webchat and bot logic is coded in C#. The steps that I could think of -
User asks for handoff
The Bot logic connects the conversation to signalr hub on server side
The next conversation takes place directly using this hub.
Need to know if someone implemented such use case. What should be approach for creating this?
Look over the intermediator bot sample. It is designed to work with v4 of the BotFramework demonstrating bot-to-human hand-off in C#. You will, of course, need to adapt it to work with SignalR. But, I don't see any reason it couldn't be configured to do so.
After the user invokes an app on Alexa , Is there a way to get the query as a voice stream/audio file of a user? Through alexa I want to send the stream to a webservice/lambda that the invoked app will call and analyze the intent there.
We have some proprietary code that we want to use for analyzing intent hence we cant do it on the alexa side
Since I am sending the query after the user has invoked the app and through the app there are no privacy concerns(hopefully)
Thanks
No, that is not possible, and I don't think it will be.
Echo devices connect to Amazon only, and Amazon uses Lex (which is also available via AWS) to parse speech files. As a skill developer, you will only receive the parsed results: intent, slots - and maybe, when Amazon implements user differentiation, an anonymous ID for the speaker.
There is no way to access the original speech audio in your skill. As every file is also used by Amazon to train their speech recognition, I doubt they will open their ecosystem accordingly.
Only option I see currently: build your own Echo with e.g. a Raspberry Pi, then you have full control. But you can't leverage the install base of Echo.
Same applies to Google Home and Microsoft Cortana, so it's not just Amazon.
I saw on internet that there is some programs that can use Telegram CLI.
I want to choose between them
for Telegram bot API there is much more documents explaining its functionality, but for CLI there isn't much that explains its features
it seems the only way to know about is to experiment with it.
unfortunately i don't have a linux distro installed on my pc so experimenting isn't an option right know.
so I thought to ask from people who already used it
I know about Telegram bot api, its powers and its limitations
here is my questions:
what can I do using Telegram CLI that I can't do with with bot api, and vice versa?
Telegram bot API:
do not require to register new Telegram account, so you don't need to have another phone number;
bot cannot write to user first, only after user sends a first message to bot;
already has the commands interface (/command);
can do stuff by simple HTTP POST (by sending request via cURL, for example). So you can hook to this tons of stuff (notifications about new articles at the website or so);
you can rather easily create lots of them;
you can write you own implementation in almost any programming language;
you have a list of bots you have created (thanks to #BotFather). If you have lost somehow control of your bot - just revoke the token via #BotFather and it's yours again;
pretty simple to use.
Telegram client application (in this case - CLI):
requires new Telegram account registration with phone number;
acts like any other actual Telegram user (can write to other users first, without invitation). Well, that's a good thing;
not really good cross-platform abilities for now (some lack of CLI-realisations);
not really easy to install and use;
you have to implement the commands handling part;
if you have lost your phone number - pretty much you lose this account, because it's not like you would make some precautions for CLI client account. So you will have to register a new one and repeat the setting procedure for client.
In conclusion, bots actually got rid of CLI clients, in my opinion. I had CLI account right to the moment the bots appeared. After that I deleted it and created a bot. And not just one :)
So, bots are for the "robot" stuff, and real accounts are for the real people.
The Telegram CLI library interacts directly with their MTproto protocol, which means it's like their desktop/mobile app...but for the console. You can send messages from one phone number to another. This means that when authenticating with the CLI application, you use your real number as if you were logging into the mobile application.
I wouldn't suggest using it for bot behavior as you have to write an application that wraps the Telegram CLI and parses the log file as it is displayed...since it doesn't implement all the MTproto methods and the outputs for the log file are custom...it can be quite annoying and different than what you would expect.
With Telegram CLI you can send a number to another Telegram user without having them initiate the conversation first (since it functions just like a normal Telegram client) where the Bot API requires the user to add the Bot and start interaction before the Bot knows you are there.
previous answers are almost correct. Two different interfaces for different purposes:
Telegram Bot API allows to develop a Telegram Bot.
Telegram CLI (as this one, as an implementation example: https://github.com/vysheng/tg) are telegram client implementations, running from command line, based on MTproto protocol, as Chris Brand said.
As a bot developer, I'm interested to have a TG CLI interface (2) to automatize dialogs tests, with bash scripts, with a bot made with (1).
My team uses skype group chat, and I would love to have a tool that could post notifications to our group chat.
I would like to avoid relying on an RSS feed, but it may come down to that. But even that it seems hard to find -- there seems to have been a tool called Anothr that perhaps went out of existence.
I would also prefer to not have a 3rd party (outside of Skype) that receives the messages -- e.g. I don't want a bot that is hosted by a third party on a server somewhere, with their bot sitting in our group chat.
You did not state what kind of build server you use.
If you are happy with Jenkins, there is a plugin for that:
https://wiki.jenkins-ci.org/display/JENKINS/Skype+Plugin
I did not check whether it can send groupchat messages, though.