search

mmehr2 / Msw4

Source code for MagicScroll for Windows (basic) project.
0 stars 0 forks source link

Pubnub candidate remote solution issues #4

Closed mmehr2 closed 6 years ago

mmehr2 commented 6 years ago

As mentioned in ticket #3 there are problems finding a working M2M solution for Visual Studio 2010 that can be made to work here. One attempt was Pubnub. I'll document some issues with that here. (They should be separated out, but I'm rushing here a bit.)

  1. Pubnub has proven to be difficult to integrate. My initial success at building it was replaced by chagrin as it became obvious that the VS2010 interface was not well supported. (See ticket reference #4342 there.)

  2. Cost of service if exceeding free tier limits It seems to me that the cost of the service will become prohibitive. I did the math over trying to keep the number of messages down to 1 million per month per account, and even with one account per device, I believe the number of messages the remote scrolling app would use if a teleprompter were in regular use by a studio would exceed that number. Priced plans (from $49/mo@2M to $799/mo@20M) don't necessarily seem to help. I will add the analysis in a separate item. I doubt if the owner wants to pass significant costs on to his customers just for this feature.

  3. Additional Pubnub issue over file transfer. The script file needs to be sent at the start of each session of scrolling, and the description of how to do this over Pubnub seemed arcane at best, and at worst a real problem, especially for client privacy. (Pubnub packets are broadcast worldwide, so we would probably be advised to use the TLS/HTTPS features, at further cost and delays.) The possibility of using a separate secured channel for the transfers can be looked into.

  4. Building the libraries. This seemed to go well initially. But they are only made available with Makefiles for the Windows interface, and there is no Visual Studio compatible project. This should have been a red flag. Both C and C++ are supported. I attempted to use C++ first.

  5. Resultant library testing. Barely 1/3 of the tests provided by the pubnub_fntest.exe passed. Out of 18 tests, the failures were 3-6, 9-12, 14, 16, and 17. Only one was fixed (#8) by using my own pub/sub keys instead of "demo/demo".

  6. Integrating the code into MSW. This proved to be surprisingly difficult. The library is split into several subfolders, each having its own headers as well as C or CPP files. When integrating this into MSW, these paths ALL have to be added to the search path for include files (4 at last count). Even so, the build succeeds but Intellisense still has troubles finding the files. Perhaps the path is too long?

  7. Unresolved externals. So I have been able to build and compile in the libraries via the header pubnub.hpp. But when I go to use any object (pubnub::context is first and most important), I get unresolved externals, even though I have added the libraries to the build properly (I believe). I have communicated this on my open support ticket #4342, but have yet to hear back. I have had one round-trip with their engineer Vladamir, though, and he reminded me of the generally difficult nature of supporting this old compiler and its interfaces. Especially support for multithreading issues, which I am not clear yet if they are needed.

Further Pubnub issues and updates will go here until we are clearly no longer using this product.

mmehr2 commented 6 years ago

Reporting back from a nearly successful use of this library. Here are the lessons learned above:

  1. Integration was mostly due to some misunderstandings on my part. I prematurely dropped the C++ interface in favor of C, but that turned out to be an issue of linking with the right import libraries. The library only requires two: ws232 (sockets) and rpc4rt (remote procs). If you don't link, you get unresolved externals for the futres dtor (C++) or various pubnub* functions (C).

  2. This one is ongoing, especially if as it seems now that the SDK itself does many messages in response to one call (pub or sub) by me.

  3. The file transfer is mostly doable now, and will be sent base64-encoded anyway, so any random interception shouldn't be an issue. Whether the client will be reassured by this remains to be seen. But using TLS is some extra work I'm choosing not to do just yet.

  4. I have rebuilt the library from source many times now. My issue back then was using a down-rev version of the source (v2.2) vs the latest (v2.3.0), and several things that were broken were fixed that week. The Windows makefile seems to work fine. I haven't customized anything yet, the generic builds seem to work.

  5. The Pubnub C++ engineer (Vladamir) assured me that these functional tests where there for the Posix compliance testing, and would mostly not work well on Windows, and no one had plans to port them at the moment.

  6. This regarded having to include too many paths to the source in the project options for VS2010. While true, once we got it worked out, it worked fine enough. They agree that it's a bit crufty and are looking into a change in their v3.0 release. Something to look forward to. (Changing releases this often does not necessarily lead to a stable product, implying the need for ongoing maintenance to keep the code current and functioning correctly. I don't believe this fits Eric's business model well.)

  7. This particular one was a simple matter of not including the two required linker import libraries (ws2_32.lib and rpcrt4.lib). Oops.

Most of these have been fixed. Of the two open (2 and 3), I will see that issues are opened. Point 2 above corresponds to #13 and point 3 to the creation of file transfer code. I'll close this one in favor of individual issue tracking now.