October 2013 Meeting Minutes
From CometWiki
Contents |
Comet Anywhere Mobile
Justin talked about the latest changes to the API and changes required for iOS 7. You can find out the details here [[1]] The API is currently distributed as a pre-release product and is not available thru iTunes. Therefore the UDID of each device participating in the testing must be compiled into the app. There is a limit of 100 UDIDs so if many more customers want to participate we may have to make multiple copies of the app, or even copies specifically for any large customer.
Louisa requested more comprehensive documentation examples and information about how to design for the environment. Justin offered to research and suggest a couple of links to documentation about the view types and various controls.
Louisa also said she would need access to the iPad's GPS and camera for a project she expects to do for DGR. Justin explained it may be easier to gain access to the camera roll rather than the camera because we'd have to write an whole camera app to do that.
Barb demoed the invoicing app she wrote for the Kauai Beer Company. Attendees with iPads were able to participate in the demo by running the app from the mobile account on our cc32 CA host. You can see screenshots and download the KBC programs and source here [[2]].
Windows API and Support for Other Mobile Platforms
Grant requested we make a WDL32 that could take advantage of Comet32's long strings. He has an issue with data begin truncated due to the string length limitation in Comet16.
There was discussion about updating the Windows API to use the Comet32 proc compiler so that IB programs will be easier to develop and read. The benefits of this are evident when comparing programs written for the Windows API to those written for the iOS API.
There was discussion about supporting other mobile platforms. Justin reported that prior to implementing the iOS API he had spent months testing out a solution for Android. The programming language used for this is Java and he found that it did not easily adapt to our file-system-based applications. Android development is also complicated by the number of variations in both hardware and software versions. Windows Metro may be the next platform to consider.
XAP and SSL
Stan reported problems passing COMMON between XAP programs in Comet32. Jim explained he had recently been working on this and perhaps it still needed more work. It is a very complicated part of Comet32, numerics are particularly tricky, as is passing between Comet16 and Comet32 objects. Jim suggested concatenating all of COMMON into one long string and/or leaving XAP programs as Comet16 objects rather than recompiling with Comet32.
COMMON storage is done differenly in Comet32 than in Comet16. Comet16 stored COMMON in temp files in the COS folder. Comet32 keeps them in memory. Louisa suggested Stan use cookies instead of COMMON. Steve says another option is to use hidden fields instead of COMMON. Both of them indicated that their methods had been trouble-free.
XAP in Comet32 has some new features including the ability to get the entire http header and the post data passed from the brower. Comet32's longer strings make this possible. You can get more info on these and other enhancements here [[3]]
It was reported that if an XAP program compiles with an error and then someone attempts to run it, the program file (which is SEQ because of the compilation errors) is left open. It will require investigation to determine whether it is XAP or the file server which is doing this.
There was a question about the status of native SSL in Comet32 XAP. This was discussed at the meeting in New Orleans. Brian reported that we had started working on it but that some problems had surfaced and further work was stopped. One issue is that it needs to be able to listen on 2 ports to be able to support both http and https.
Frank Caton reported daily crashes on his Comet16 XAP server. While he has not been able to narrow down the circumstances around these events he said there is also a batch process going on to copy files to the server. He's going to move that process to another machine to see if the crashes continue or follow the batch job. Jim also suggested looking at the XAP log to see what the last activity was prior to the crash.
Frank also reported that his SSL process just stops occasionally. Jim advised that this is very difficult to debug. He suggested manually starting it from cmd.exe so that if it shuts down he'll see it in the command prompt window. Alternatively try running it hidden.
Security Server
The Virtual Dongle Server was announced. Instead of having a dongle plugged in to your server the Security Server software will validate your licenses by connecting to our corporate dongle server. To use this method you must sign a new EULA and return your hardware dongle to us. Plug swapping fees apply. The new EULA contains a paragraph stating that you will maintain a reliable internet connection so that the Security Server will be able to connect to our dongle server at unspecified intervals. Here's a link to the EULA: [[4]]
Generous tolerances have been coded to allow for those occasional unavoidable ISP and hardware downtimes on both sides. Jim made the promise that if Signature Systems decides to go out of business he would release a version of the Security Server for virtual dongle users that will continue to work even after the dongle server has been taken out of service.
The Virtual Dongle Server will be available in the Server Products 13.00 release. To install your virutal dongle you will receive an email containing a file called DRB.txt. It looks something like the current license certificate file. Place the DRB.txt in your Comet Services folder, then restart the Comet Services. (If you have a hardware dongle be sure to remove it first.) Registration of your dongle may require several seconds as it will connect to both the dongle server and then the certificate server to retrieve and install the certificate for your new dongle. Once installed, you maintain your licenses as you always have. Anytime you make changes to your Comet licenses you will receive a new license file just as you do now.
Greg asked if you'd be required to install a new virtual dongle if you went thru a Windows upgrade on your server. Brian replied you shouldn't unless you did a total reinstall which would wipe out the registry.
Other Security Server discussions... It was reported that if someone does not shutdown Comet properly the licenses they were using are not being returned to the pool, even if that user reconnects. There was a request for some way to manually log a user out of the server. Jim suggested something that could be run from a Comet client like SECLIC. It would have to log them out of the file server also.
There was a request for an option to disallow multiple users with the same profile name. It was suggested this could be done thru a check box on the Security Server UI.
Greg requested a way to assign a different port for use by the Security Server, perhaps in the SERVER section of the Comet.ini. After some discussion I believe this request was withdrawn as another solution to their problem was proposed.
Comet32 Compiler
Grant requested that the Program Memory Requirements be displayed in the UE output window just as they were when using the Comet16 compiler. This would include byte counts for COMMON, LOCAL, CONSTANTS, FORMATS, and CODE.
There was a general concensus to create the .LST file (created when using OPT L) in the TMP folder instead of in the source file folder.
There was a request to get just errors listed to the .LST file (like OPT E). This would be especially useful for those compiling outside of UltraEdit.
One report of an issue with the Comet16 compiler came from Robert. He claims a program may compile without errors even if it's a few bytes larger than the size limit. These programs have problems at runtime.
Printing
Stan reports that his Comet32 users occasionally have problems with CosP hanging up and staying active even after Comet has been stopped. This requires him to manually shut it down thru the Windows Task Manager. Brian reported that this is probably due to CosP waiting for something for which it never got a response. Stan requested that we kill off any remaining instances of CosP when Comet is starting up. Brian will look in to this. If this works perhaps we should consider automatically killing off other left over pieces of Comet that will prevent us from starting successfully.
There was a general concensus that customers are happy with Comet PDF.
Grant pointed out that Comet PDF files are larger than those produced by other products. Jeff suggested he look at the printer properties and adjust the dpi to reduce the file size.
Grant requested there be an option to turn off the tray notification from Comet PDF. He says it becomes annoying and slows the process down when printing several documents in a row. Others agreed and we will make this the default.
Grant reported that he can't print to more than one Comet PDF printer in a program, while PDF Factory allowed him to do this. Jeff tried it in the meeting on Windows 8 and said it worked. Windows 8 has a different version of the Bullzip driver. Brian reported that it seems a few problems were addressed by the new driver and perhaps even non-Windows 8 users should install it. We will look in to changing our install program to do this.
Steve reported that PDF Factory currently has a bug that can cause Comet to get an E30. You must reboot to recover from this. PDF Factory is aware of the problem.
Jeff shared a trick for embedding "hidden" text in a pdf file. One advantage to writing to PDF files in cooked mode is the ability to change font, size, and color. Besides the obvious purposes for using this, its also useful for 'hiding something in plain sight' in the PDF file. Setting the font color to a very dark grey, and choosing a very small font size can be useful for embedding information in a horizontal line. Or choosing a font just slightly off white can allow you put data anywhere in a pdf. Very small fonts, such as .7 are undetectable to the naked eye, or on a printout. But zooming way in on a specific area when viewing a PDF file will make the data easily readable.
Email Printing
Jim reminded everyone that Comet32 can do TLS to send email thru providers that require authentication beyond a user name and password. To use this, put tls=true in your email.ini.
Louisa recommended adding PAUSE 10 after closing the email printer when sending multiple emails. Steve says he does PAUSE 9. Obviously a PAUSE of some duration is in order ;-)
Jim reminded everyone they can use the SILENT command to get notified of any email error rather than have the error message displayed to the user. The SILENT command is added to your email.ini. You may also optionally specify a program to be entered each time an error is encountered. In that case, # buffer will contain the error information (the text that would normally appear in the message box.)
Frank Caton reported problems using SENDMAIL. The solution is to convert to EmailPtr.
General Comet Discussion
The .476 release of Comet will now make use of an optional Windows environment variables for your
Comet installation: %COMETPROGS% and %COMETDATA%.
COMETPROGS - For Comet programs - tells Comet.exe where to copy the executables to
COMETDATA - For Comet data files such as CosW.ini and the logs
By default, Comet uses folders under AppData\Local. This new optional method can be useful for those
installations using roaming profiles. This option was added at the request of LOCIS.
Greg reported they have a lot of complaints about AVG generating false positive reports against the Comet executables. Brian suggested that we might be able to solve this by digitally signing our products. Jim had looked in to this in the past and was deterred by the cost involved. We will revisit this issue. Another possibility is to submit our executables for whitelisting by AVG.
Greg requested that we automatically open the firewall ports required for Comet. Our position on this is that it is the responsibility of the local administrator to manage the firewall, not us.
Greg requested a method for specifying a program to be run before Comet starts up, perhaps call it CometDealer.exe. Jim suggested that instead they change their Comet shortcut to run that program and have it conclude by running Comet.exe.
Along the same lines, Robert asked if we had ever implemented his request for a way to have Comet copy some additional files to the %TEMP% folder at startup along with the Comet executables. We did - way back in Comet 2011! You supply the list in a file called CometUserFiles.dat that you create in your Comet folder. Here's a link to info on how do format the list [[5]].
Robert reported that if you start a new Comet session from another, the windows cascade down the screen rather than using the coordinates from the CosW.ini. Brian says this is by design.
It was reported that the target of a Comet shortcut can't be a UNC name. Apparently this is because Windows doesn't support UNC to itself. Jeff says this is fixed in Windows 2012 Server and Alan says he doesn't have this problem as long as file sharing is invoked.
Alan reported when he assigns a certain partition to a Comet Anywhere user the status on that user indicates a PARTITION$ value of 9 less than what he assigned. This requires further investigation to understand.
Greg requested an easier way to SYSGEN. Jim suggested he try simply typing SYSGEN COMET.INI from QMONITOR. Your Comet.ini file must reside in your Comet folder for this to work.
Also about SYSGEN, someone reported that there were problems with it unless each line in the .ini file was terminated with a ";".
Greg requested a Comet uninstall program to remove all executables and registry entries. This request was denied.
Frank Caton asked about how secure the CometAnywhere encryption was. Brian explained that it uses the public domain algorithm, Blowfish, and does both compression and encryption. He feels that it should be adequate for most installations unless you are subject to certain government regulations. In that case you should implement a VPN.
Jim reminded everyone that performance can be greatly improved by running a CometAnywhere host on the same machine as the file server. Then use CA clients instead of full Comet clients for the users. This can be especially helpful for large installations. Several customers host more than 100 CA sessions from one host.
Programming and Utilities
Barb announced a new Source Search Utility for Comet32 UltraEdit users. It will search your IB source file including any imbedded usefiles for one or more specified strings. You can request case sensitivity and/or whole word matching. This requires Comet32 version .476 and REL 13.05 or higher. You can get more info here [[6]].
Stan requested a Rich Edit Control for IB. Brian explained that this is non-trivial because we'd have to implement all the additional controls to support its features such as colors and fonts. There's also the issue of how to get large amounts of data back and forth. Brian will study it somemore.
Greg reported that since the implementation of Windows themes and the version 6.x of Windows controls that his calendar control is no longer working as expected. Since the meeting Brian has investigated and found that Greg had been relying on an undocumented behavior of the Calendar control that happened to work as a month picker. The updated controls were introduced in Comet version .474. If he must use this older control they will have to revert to CosW from .473. We have no way to change the behavior of the Windows controls.
There was some discussion about whether numeric CSV fields were being stripped properly. Tests done by Grant during the meeting indicated that it was working as intended. You should use PRINT if you want stripping and WRITE if not. STRIPFORMAT can be used to quickly strip each field in a FORMAT (variations are STRIPRFORMAT and STRIPLFORMAT).
Alan reported that CometExplorer was unusable on a very large directory because of how long it takes to load the file names. We all agree with that! It was suggested that we have a quick view option that would list only info from the QDIR (which is stored locally) rather than waiting for the file server. Alternatively offer the choice of loading only a range of files.
Steve asked for an easy way to copy files for CometAnywhere clients. Two suggestions were given. First, use CUTLCPY. This is a utility that was written by and donated to the Comet community several years ago by Jon Sacks. You can get all the info here [[7]]. Grant offered a second solution. He wrote a replacement for DOSCOPY which he posted on the forum for all to use. Here's a link to more info and the files: [[8]].
Louisa reported that the KEY function returns E33 for an extracted record. Attempts to reproduce this in the meeting were unsuccessful.
Frank Caton asked if there was a way to stretch a wallpaper image rather than have it tile. Frank uses (Wallpaper Bitmap) to differentiate user logins and sees a problem when maximized. Brian said he'd look in to this. It may require a new mnemonic.
SymbioSystems and Comet Cloud
It'll be very difficult to summarize the incredibly energetic presentation given to us by Julian Sutter from SymbioSystems. His company hosts our corporate virtual servers at SymbioSystems' data center in San Francisco. We've heard from several of you that you're getting questions about cloud computing and virtual servers for Comet. They can provide a very nice solution for your customers. They assume all the duties of an IT staff including hardware and software installation and maintenance, backup, disaster recovery, and support.
Julian presented 2 different approaches you can take with running Comet in the cloud. One involves Signature Systems as well as SymbioSystems and the other just SymbioSystems. The Signature solution is a new product called Comet Cloud. In this scenario a virtual server at SymbioSystems will host your CometAnywhere host. All Comet users will run CA clients. This requires converting your full Comet licenses to CA licenses. The normal conversion fee will be waived for Comet Cloud customers. This change could result in a reduction of your annual Comet subscription fees since CA licenses are less expensive to renew than full Comets. Your monthly fee for the server includes all IT services listed above plus Comet installation, updates, and support done for you by Signature Systems staff.
The other scenario is a more comprehensive "infrastructure as a service" solution. SymbioSystems can host virtual servers that replace existing on-site servers (and all of their local applications and file sharing) and desktops for each of your users. Users access their virtual desktops from a variety of clients including 'computer-less' desktop thin clients and mobile devices. They can keep their current Comet configuration if they want. The monthly fee includes everything listed above except the Comet support. SymbioSystems will work with you and your clients to keep your Comet software up to date and running. In this case you also pay a fee for each desktop hosted.
Pricing is configuration-dependent. You should contact Julian Sutter to discuss your situation. You can reach him at (415)814-5370 or jsutter@symbiosystems.com.
Miscellaneous
Frank McKay asked for suggestions to replace Microsoft's Exchange Server. Jeff suggested Office 365. Justin suggested GMAIL. That's what we use. Go Daddy may also have a solution.
Greg requested that we guarantee a response time to problem submissions. He says LOCIS does this for its customers. Jim declined to offer a guarantee and assured him we do our best to address everyone's issues in a timely manner.
Jim announced that we may be able to begin accepting credit cards and bank transfers for payment. Credit cards would incur a service charge.
Jim announced that we are reworking the Price List for next year. We held off increasing prices during the recession, but now we will need to do it.
There was some discussion about how to get young programmers involved in Comet. Louisa says she has had some luck with college internships. One criticism of computer science students is that they have no knowledge of business applications. It was suggested that interning business majors with some programming experience might be an option. It was agreed that having one or more mobile IB APIs could be an enticement for new recruits.
Lastly, we always conclude by choosing the destination for our next meeting. Several cities were mentioned but the concensus was for Kauai! Mark your calendars for Spring 2015.
