I'm investigating how our application can communicate with a phone system: identifying the caller and making a call.
I see that there is a standard Java API: JTAPI with 2 implementations (gjtapi and xtapi). Unfortunately, those projects seems to be dead.
Can I use this API?
Thanks!
I think it depends on the phone systems you have to use/connect with :
With Avaya, Unify (Siemens), Cisco you have good support. Asterisk looks outdated.
Other systems? Don't know.
Yes, JTapi is still alive but it depends of telefony platform maker. For example:
For Cisco you have tow options: For Call Manager Express which allows you control just one extension by connection and for Call Manager Enterprise wich allows you control many extensions by connection.
For Avaya you have another implementation of JTapi wich allows you control one extension by connection.
All of them use the standar of JTapi for implements their requirements according with the telephony plataforma.
Related
I'm in the process of porting an application to ChromeOS with the requirement that it should look and feel as native as possible. This means in particular that it should allow things such as multi-monitor support and USB support.
One possibility would be to implement it as a web application (since we have already a web client), but in this case I would need to add support for native features (again, multi-monitor support and USB device access), so I wonder what needs to be done in this case. My wild guess as a ChromeOS developer newbie is that I would need to extend the code with ChromeOS JavaScript features, and I don't know if this is possible.
Another possible approach would be to write an Android application, since I see that ChromeOS added support for Android applications (in this case I would have to write the code from scratch).
Finally, another option would be to write native code, which could be possible for example relying on a Crouton development environment, and reuse the code of a native C application.
What approach would you recommend to build a ChromeOS application starting from a web application or from a native one?
What approach would guarantee access to native features (multi-monitor support and USB)?
I discovered two APIs which should help with multi-monitor support:
https://developer.chrome.com/extensions/windows
https://developer.chrome.com/apps/system_display
The system.display API allows one to discover and monitor the current monitor layout, while the windows API allows one to create several windows in the same application. By combining these ones I should be able to create a window for each monitor in case I go with the chrome implementation route.
Given that I already have a native implementation for Linux, Crostini (as opposed to Crouton) is also very appealing since it provides a deeper level of integration with virtually no changes to the code and no need to maintain two different versions of the web client, with the only downside that it requires the user to create a Linux environment and manually install the application, also it is not supported on all chromebook devices and on many it will be never supported.
I still need to check what is the performance overhead. Also the level of integration with USB I/O might be higher than the one achievable by using the chrome API.
How to make an external program control Tridium Niagara framework? I see two options; Which one is correct:
1) Niagara allows addition of 3rd party code to provide an API, and someone else has already done that and we can use it.
2) Niagara allows 3rd party code to do API but we have to write our own.
Niagara installations can be configured to process many different network control protocols driven by an external process across the network, for example by BACnet. The Niagara instance can be configured internally in many different ways to respond to control from across the network.
Niagara 4.x prominently features Web GUIs, including Javascript client widgets and server Javascript, or the server can respond to the Web GUI activity with its other configuration and scripting methods.
For any real complexity beyond the bundled network drivers or HTTP, 3rd party modules coded in Java are used. These would typically be coded as Niagara drivers, processing data over serial or sockets.
Niagara's APIs are mostly open. But Niagara is a complex environment. Completing Tridium's week-long developer training/certification is typically required to produce a proper module.
There are some external API's that Tridium built into AX. oBIX and Bajascript.
I've written external oBIX programs in both Java and Python to pull data from a remote Jace. You'll have to add the oBIX service and export the points you want to see.
Bajascript is a javascript library Tridium uses to interact with the system as well. I believe they released Bajascript 2.0 not to long ago. http://www.bajascript.com
If those don't do what you like, you'll more than likely need to write your own API to handle it.
Suppose I've a custom made hardware which is connected to the computer. I've my drivers installed to communicate with the hardware.Then how can I write an API through which i can access my hardware programmatically(As an example consider accessing oculus rift head mounted device using OculusSDK).Specifically how do i make my API communicate with device drivers to access the hardware using system call interface? If possible explain with an example.
Your hardware driver should implement a way of interracting with user.
E.g., it can be special file(s), which user can open (using standard open(2)) and then call read/write/mmap/ioctl for it. Each such operation actually triggers some driver code, which in case triggers some hardware request.
We use a particular ODBC driver here to access a legacy database. Our homemade software (a 2 tier vb.net winform application that connects to an sql-server database) could really use it for some operations. Unfortunately, due to licencing restrictions we cannot deploy the ODBC driver on more than one computer. I'm looking for a way to go around that.
My initial thought was a WCF service and POCOs. However, since the app references a library with a rich set of generic ADO.NET helper functions, I really want to reuse these to communicate with the server. So I'm thinking of making my own ADO.NET implementation to access the WCF service that will, in turn, expose session objects to process queries sent by the client.
Anybody did something like this before? What challenges awaits with implementing my own ADO provider? Also, is there something like this that already exists, before I go and reinvent the wheel?
You can use an ODBC-ODBC Bridge to access you legacy ODBC driver from any other machine and still access it via ODBC. Sounds to me like this would be a lot less effort.
Update: I can only describe the Easysoft ODBC-ODBC Bridge as I've not seen the code of any other bridge. At the client end you install the OOB client ODBC driver. On the server end you install a service. The client end effectively sends your ODBC calls and data to the server where they are redirected to the actual ODBC driver you want to use. Of course, there are loads of optimisations performed both in the ODBC APIs and the protocol. There are a lot of advantages to this a) you can use a driver you cannot get for the platform you want to code on b) you can use a 32 bit application to talk to a 64 bit driver or vice versa c) you might only be able to or want to use one license for the driver/database on the server d) you can cross networks to access a remote driver etc.
Transactions are handled properly in the Easysoft OOB.
I've seen download manager programs including IDM taking control of downloads in browsers without having extensions in them and they are calling it (Advanced Browser Integration).
I was wondering if anyone can suggest an approach for a similar situation?
IDM only works on Windows and does his Advanced Browser Integration tricks using Windows Filtering Platform which is a windows specific service.
If you want to do something similar on Windows, you should study that platform.
On unix systems, as far as I know, there isn't anything like the Windows Filtering Platform. Packet filtering and other firewall like functionality happens in the kernel and there are multiple implementations of that: which is running (if any) depends on how the user decided to configure the system (even if ipf is almost guaranteed to be the used one on BSD and BSD derived systems).
On Mac Os X specifically you probably want to check Network Kernel Extensions. I'm not sure they are sufficient to do what you want to do, but I suspect they are.