I know asking this question here is not proper, I feel sorry for that.
I have tried searching websites, Amazon and Alibaba, but fail to find any product can support Eddystone-EID.
So, I think developers in stack overflow may know any product can support Eddystone-EID.
Could you share any any information for that?
The two vendors below claim to sell beacons compatible with Eddystone-EID as of October 2021:
Gimbal
Estimote Location Beacons
Before you buy anything beware that Google shut down their beacon platform web services in April 2021. I wrote a full blog post to explain what this means: Eddystone is Dead, Long Live Eddystone!
Using these web services is completely optional for Eddystone-UID and Eddystone-URL, but critical for Eddystone-EID, because the beacon identifier rotates with a crypto algorithm and a “trusted resolver” server is needed to convert the advertised “ephemeral identifier” from jibberish to something meaningful and useful.
Without Google’s beacon platform web services, I am aware of no commercially available trusted resolver for Eddystone-EID. You would need to build your own, which is a non-trivial effort. Without a trusted resolver Eddystone-EID is worthless.
Because of this, make sure the vendors above still support using their products with Eddystone-EID. In time, it is likely they will remove support in their beacon firmware.
Finally, it is important to note that just because Google gave up on their beacon web services, most apps that use Eddystone, iBeacon and Altbeacon are unaffected. Beacons are standardized and will work forever — just don’t use Google web services! Again, beacon technology aside from Eddystone-EID has no need for Google web services.
Related
This might be a basic query but I wanted to confirm if there is any way of using the LUIS services/functionality offline without consuming the online APIs and generating the public key online. By offline, I mean to say if there are any supporting libraries/DLLs available for on-premise solutions by which we can build the Intends/Utterences/Entities and train the NLP system offline.
(The reason for asking this question is that I want to integrate LUIS with my existing Microsoft Bot application. However, our organization limits the software usage to utilize only on-premise offline software and any online software/services/APIs such as Azure APIs are restricted.)
Assuming that there is no such offline support for LUIS AI, are there any other libraries that would provide such support for .NET apps. I have come across Apache OpenNLP but that seems to more of Java-oriented offering.
Any inputs/suggestions on this would be appreciated.
Luis now has the ability to be fully off-cloud and on-premise through a docker container pull. This would be available for on-premise and Azure's IoT Edge (intelligent Edge) products.
Keep in mind
The described solution still requires a connection for Azure LUIS billing purposes that at the time of this writing is at a 15 minute interval. I believe this will be adjusted at some point in the future but it is something to keep in mind and plan for.
Link to Container Support in Azure Cognitive Services
As well, specifically, LUIS has full integration via this scenario. Where you can install and run LUIS docker containers. Please, keep in mind at the time of this writing this is ONLY for LUIS. Not QNA, not Bing Spell Check, *not analytics from the LUIS endpoints but there is a container work around for that.
Also, not speech priming or sentiment analysis and a few other features listed in the article.
Lastly, you can look into "Azure Stack" and IoT Edge here
It's a promising start. There are work arounds you may have to engineer while these services bare out more fruit but keep asking questions and keep raising concerns and more features will surely come!
LUIS is based on an online use, like almost all Microsoft Cognitive Services (except Custom vision compact models for example). There is no possibility for offline use, even if it may be useful for some cases like mobile use also.
Moreover (see here in the official documentation):
Is LUIS available on-premises or in private cloud? => No
For your 2nd question, StackOverflow may not be the right place for this (see https://stackoverflow.com/help/on-topic) and... I don't have a good solution! But would be interested to know one
There are plenty of companies out there offering texting to your landline without affecting voice service (ie zipwhip, heywire), but does anybody know what they're using? Twilio almost offers this, but it's currently in beta and only for toll free numbers. TextUs.biz has an explanation of how they do it in their faq, which explains that they have some sort of agreement with their SMS gateway provider that lets them get texts to a particular number routed to them, but afer a lot of googling I still can't find any resources on how to make it work.
(Disclaimer: I'm the VP of Engineering # HeyWire) The TextUs FAQ is spot on. SMS routing and voice routing are completely separate. OTT text carriers like us have agreements with SMS aggregators and have to abide by industry rules and guidelines. The agreements and rules may vary depending on whether you're doing short code, non-toll-free long code, and toll-free long code. International and MMS are also other dimensions as well.
In general, our application stacks connect to SMS gateways, which connect to SMSCs at our aggregator partners. Beyond that, the details of how everything works isn't technically complicated. Some the real special sauce comes in the details of all the agreements and partnerships required to get things up and running. Unfortunately, those types of details fall under the umbrella of "trade secrets". Partly due to providers not wanting to reveal too much to competitors and partly due to the agreements themselves, which prohibit disclosure of details.
Are you asking because you're trying to build something or just to try to find out some general information?
EDIT: And I just realized I wasn't logged into my account when I posted this. Oh well.
I have seen this question asked several times but the answers have so far been very robotic and disappointing:
What is the difference between EWS vs EAS?
Now, most sites give the following: "One is a protocol for mobile devices, the other is a web service." Well, no shit. Here's the real question:
What is stopping someone from setting up a descent library for EWS that any mobile app or OS could use instead of paying MS a per-user license fee for ActiveSync? Is EWS too expensive, since it's SOAPy instead of RESTful? Is ActiveSync doing more of the heavy lifting in terms of caching and general logic? Does EAS have some feature that EWS doesn't have (shared calendars or some such?) Is it really just a matter of mobile OSs wanting to ensure that Exchange 03 is supported?
I'm sure they each have their finer points that make them distinct, but the question that I think most people are getting at when this question gets asked is "Why should I pay for EAS if EWS can do the same thing and more if I'm willing to write the client side myself?"
Most organizations will license EAS because one or more of the following is true for them:
They want to allow existing mobile devices (iOS, Android, etc) to access their services without requiring new software to be installed on them (EAS is supported on lots of devices). Zimbra and Kerio do this, for example.
They can't use EWS as a client protocol to access their Exchange services, but EAS is available.
They want to operate in a low-bandwidth environment and can't afford the weighty overhead of SOAP within EWS compared to the compressed WBXML of EAS.
I'd wager that #1 makes up the vast majority of them.
Aside: EAS is not RESTful. Everything goes over POST, there's no hypermedia or ability for the client to do content negotiation. It's basically session-oriented RPC, using WBXML as an encoding format and HTTP as a transmission protocol.
I understand how NFC is supposed to work on a high level, and a bit about the protocols used. Now, I need to understand, with your help, if there are any standards related to mobile payments.
From a trusted service manager perpective, I believe there are no standards at all and that both the machine on the point of sale and the app on the mobile device would have to be custom made correct?
If no such standards exist yet, can I assume it can be as "simple" as:
On contact the machine creates a checkout receipt and sends it to the device (this would have to be done with customized hardware)
The device receives the receipt and uses the UICC to authenticate itself with the bank/TSM
The bank, upon validation, signs the receipt which is forwarded to the machine by the device
Am I getting this right? If there are any technical bits I'm missing, please refer them so I can research.
Thanks
sure there are standards - see EMV (Europay, Mastercard, Visa). It is necessary for world wide interoperability of the payments systems, which uses the chip (aka secure element), no matter they are contact or contactless (i.e. NFC).
EMV specifies used hardware, protocols, file structures and used commands, data authentication, PIN ciphering, key management. It is pretty complicated.
I think you can start here: http://en.wikipedia.org/wiki/EMV
Regards,
STeN
www.mautilus.com
As said before, EMVCo standards will cover some of your need, but so will also GlobalPlatform underlying technology, as well as some further refinements of AEPM.
I'll also add once you obtain the information you need from the payment card, you have to send it to a payment gateway which then transfers the information to the payment network (Visa, MasterCard, etc.) where the data will then be routed to the issuer of the card for authorization. The response is then sent all the way back through the chain to the initiator of the transaction. Triangle has a free API that captures the card information for you. You can then use the captured information and route it to your gateway.
Disclaimer: I'm the co-founder of Triangle.
I am investigating developing an app for Windows Phone 7 that requires access to email/calendar information from Exchange Server (read only).
The way I see it there are 2 options EWS or ActiveSync.
WP7 only supports Basic Authentication.
By default on Exchange server installations the EWS virtual directory has Basic Authentication disabled meaning a configuration change of Exchange Server to allow EWS to be used.
The ActiveSync protocol looks like it would take some time to get your head around and develop an implementation.
The questions are
1. How common is it for people to enable basic authentication for EWS? Is this something that most businesses are likely to not want to do?
How difficult is it to learn and use the ActiveSync protocol? Is it something that could be done in days, weeks or months?
1) To find out about the common configuration of EWS servers I'd spek to some sysadmins and ask them. Maybe try on https://serverfault.com/
1) How difficult something is to learn very much depends on the skills and experience of the person learning and the teaching resources available. This is a non-trivial protocol so I wouldn't expect learning it to take days. There will also be a licensing cost of implementing Excahange ActiveSync which I suspect would make it an expensive option.
Option 3: Create your own web service that acts as a proxy to EWS and does the authentication for you. Ugly and a bit painful, but if your app is architected well, once WP7 supports better authentication, switching to directly hit EWS should be pretty simple.
ActiveSync is painful and does not support everything that EWS supports. I would recommend going the EWS route if you have that option.
If your going to use ActiveSync, think again... it uses wbxml and you would need to create your own API for doing calls - this means crating tokenized blobs which must be 100% perfect and account for all aspects of whatever type of messaging items you are going against or will risk creating bad items or even poison ones. The devistation caused by bad EAS calls could well exceed your customer base... so, you need to be very careful. Also, while the specs are public, it needs an very expensive license. If you license, you would need to get a support contract with a specific schedule in order to get develper support. With a team of developers, it will likely take 3-5 or so years to do a full implementation client side and work out most of the bugs. So, as far as the skills in email development, you and your other developers would need to be pretty hard-core. There may be third party APIs which wrap EAS calls... however, you should be sure that they are licensed and that that the license would cover your development - so, you would need to research those on your own.
EWS has more features and is far, far easier to use and is what is suggested... further, there is no special licensing, etc.
Using a proxy web service+Exchange Managed APIs so that WP7 can go against Exchange without writting a ton of code:
http://www.telerik.com/products/windows-phone/getting-started/exchange-client.aspx
... can also use this approach to use NTLM.
Before considering EAS...
http://blogs.msdn.com/b/webdav_101/archive/2011/09/29/new-to-exchange-activesync-development.aspx