19 posts / 0 new
Last post
EdgeSystems
Spokes.dll x86_64
Is it possible to acquire spokes in 64-bit?

cdhruv
Hi,<br /> <br /> To clarify, by &quot;acquire spokes in 64-bit&quot; you mean a 64-bin installer of the SDk as opposed to 32-bit that is currently available ?<br /> <br /> ~cdhruv

cdhruv
Hi,<br /> <br /> To clarify, by &quot;acquire spokes in 64-bit&quot; you mean a 64-bin installer of the SDk as opposed to 32-bit that is currently available ?<br /> <br /> ~cdhruv

cdhruv
Hi,<br /> <br /> To clarify, by &quot;acquire spokes in 64-bit&quot; you mean a 64-bin installer of the SDk as opposed to 32-bit that is currently available ?<br /> <br /> ~cdhruv

EdgeSystems
You did clarify that, three times in fact ;) haha. The 32-bit installer bundles a 32-bit Spokes.dll, I want a 64-bit Spokes.dll.

cdhruv
Got it - apologies for multiple posts of the previous message, somehow the system did it thrice despite me posting it only once.<br /> <br /> Will get back with an update.

EdgeSystems
Much appreciated

cdhruv
Hi,<br /> <br /> 32 bit dll will run on Win 64 in Wow mode<br /> <br /> Could you tell us /explain more why are you looking for a 64-bit Spokes.dll ? What excatly is the developer need for the latter ?<br /> &nbsp;

EdgeSystems
Hi,<br /> <br /> We distribute a 32-bit app today and we would like to distribute a 64-bit as well. The Spokes dll is the only thing that&#39;s holding us back.

cdhruv
Hi,<br /> <br /> &gt;<span style="color: rgb(72, 72, 72); font-family: Lato, sans-serif; font-size: 15px; letter-spacing: 0.15px; background-color: rgb(255, 255, 255);">We distribute a 32-bit app today and we would like to distribute a 64-bit as well. The Spokes dll is the only thing that&#39;s holding us back.</span><br /> Given that the 32-bit DLL will work in Windows 64-bit in WOW mode (Windows On Windows) mode, could you explain further as to the need for 64-bit Spokes DLL and how is the lack thereof holding you back ?<br /> <br /> &nbsp;

EdgeSystems
<br /> You&#39;re talking about running a 32-bit program on a 64-bit machine, which is no problem. I&#39;m talking about linking plantronics dll with a 64-bit program.

ahijleh
Any update on this issue? We need to bundle a 64-bit version of Spokes.dll into our 64-bit application as well. Is this still not supported?

lcollins
Hi, Spokes.dll is not released in a 64-bit format. The only APIs that support a 64 bit application runtime are the REST and COM APIs which have the pre-requisite of running Plantronics Hub or the Plantronics Hub minimal runtime (which is included with the SDK). If the 32 bit Spokes.dll must be used the only other option would be to create your own interop wrapper around the 32 bit dll. It would be easier to use COM or REST APIs with the Hub runtime. These APIs have some other advantages described in the overview on this site.

ahijleh
As I understand it, running "PLTHub.exe" starts a local server in which you can send commands via the REST API. It can be packaged with the app and could solve our problem but, is there any way this process can be started without adding a systray icon (on Windows)?

ahijleh
As I understand it, running "PLTHub.exe" starts a local server in which you can send commands via the REST API. It can be packaged with the app and could solve our problem but, is there any way this process can be started without adding a systray icon (on Windows)? My post was added two times by mistake :(

lcollins
Hi, If you use COM API there is a workaround - If you install the minimal Hub runtime (available with SDK) but you don't deploy all 3 MSIs to end-users machine, but only these 2: SpokesSDKNativeRuntime.msi SpokesSDKRuntime.msi In this case you would not get a system tray icon, and the PLTHub.exe is launched through a COM API request. (when you create COMSessionManager interface). However, with REST API in this scenario you must install all three: SpokesSDKNativeRuntime.msi SpokesSDKRuntime.msi SpokesSDKStartup.msi The SpokesSDKStartup.msi results in PLTHub.exe running at login and in that scenario it will create the system tray icon. Some other partners require their users to install/deploy the full Plantronics Hub product in order that their integration (COM or REST) starts working. If you put the all integration code in a worker thread that retries if it fails to get connection and potentially stands off (slows down the retry rate) when there is no response from our API, that is a way to cleanly handle case where there is no Hub or Hub is in process of being upgraded. The samples for COM and REST that illustrate this pattern are: C# COM Sample with resilient connection: https://developer.plantronics.com/article/advanced-sdk-topic-ensuring-resilience-plantronics-com-api C++ REST Sample with resilient connection: https://developer.plantronics.com/article/hubrestsample-new-c-rest-api-sample-pdc Java and JavaScript REST Samples with resilient connection is here under the *Java/JavaScript tabs*: https://developer.plantronics.com/article/softphone-integration-code-samples Note: these sample codes work equally well with full Hub or minimal Hub runtimes (PLTHub.exe) Does it help? Thanks

ahijleh
I see. Thank you for laying out these options. I will investigate this further to check what is the best course of action in our case.

EdgeSystems
Why can't you just compile it in 64-bit?

cdhruv
In theory, sure, we could. In practice, decision about 64-bit support for Spokes.dll has not yet been made by our engineering & product management teams.

Add new comment