From CometWiki

Revision as of 19:28, 23 April 2012

Comet Meeting -- April 17, 2012

Comet32

Comet32 is our current product. No more development will be done on Comet16 (CosH). There are 2 runtimes in Comet32 - one to run Comet16 objects and one to run Comet32 objects. The goal is for Comet16 objects to run as closely to how they run under CosH. This is not necessarily the case for Comet32 objects because of the new features available in the Comet32 compiler.

Comet32 can use up all of the memory on the computer so be careful! The memory is used up not just by the bigger object files allowed but also through the use of dynamic strings. You can, for example, read an entire file into one dynamic string variable.

It is no longer necessary to configure a WinSock gateway to use TCP. Comet32 has a device called TCP by default. This means you can simplify code by eliminating the "type 3" gateway search. Instead, just do this:

OPEN (LUN) "TCP"

XAP2

XAP2 in Comet32 is a superset of XAP in Comet16. Your existing XAP applications will run without modification. XAP2 is still in beta testing but is coming along nicely.

There is a new Replace statement that offers powerful merge capability. Also useful will be the STL Map structure. Refer to the STL Container discussion below for more information.

With XAP2 those of you using SSL Relay will be able to do this processing natively in XAP2. You will buy and install your certificate from a certificate authority such as GoDaddy, Network Solutions, or Verisign. We will be writing some documentation on the steps required how to request and install the certificate. Certificates have expiration dates and are generally purchased for one or multiple years at a time.

This can be used for those of you doing PCI compliance for credit card processing. There was some discussion amongst those who have done this who warned that there are multiple levels of compliance and that is can be very difficult to meet all the requirements. It is recommended that you apply for the lowest level of compliance that is necessary.

Robert asked if there was a way for an XAP2 program to tell which port a request is coming from so he can identify whether it's SSL or not. Jim added that the SSL port should be reserved only for SSL traffic.

DocMgr Enhancements

Barb gave a refresher of the latest enhancements added to DocMgr noting especially the programmer interfaces. There are programs in XTL that allow you to:

• Create a multi-keyed archive so you can write programs to process it by secondary keys of your choice (DocMgrMK.ibs)
• Easily write a program to import any file into a document archive (DMImp.inc)
• Start the "Print Text Docs" unspool option programmatically, including the "forever mode" option (DMUnspl.inc)
• Process one or more user-selected documents any way you want, for example, print them, email them, export them,etc (DocProc.ibs)

There was interest in having archives that are not necessarily tied to any printer. Furthermore it was requested that a user running DocMgr be able to create one of these as a sub-archive to an existing archive. The sub-archive would not have to be in the same directory as the original archive. DocMgr may have to do a dynamic access if this is the case. This feature could be used to further categorize documents from the original archive.

Robert noted that the archive record allows for the number of pages and lines in a document but they are always zero. It is not clear whether this info can be provided especially for .pdf documents. We will investigate.

CometAnywhere Mobile

The big news was Justin's demo of CometAnywhere Mobile. This is CometAnywhere running on an iPad! You will be able to write applications for the iPad in Internet Basic. The demo was a customer inquiry/maintenance program which made use of familiar tablet capabilites such as touch interface, scrolling, interface to the iPad's camera, and email capability.

You will use simple mnemonics to describe the layout of your screen. Programming this will be very similar to what you do now for hyperlinks using an event processor. As these mnemonics are still under development, Justin wrote procs to simulate the mnemonics using hex codes. The mnemonics will replace the hex codes making your programs easier to read. You can check out the source for the demo by downloading m5.ibs

At its simplest, the basic program flow for the demo program is:

• Choose the view type. iOS provides various views. Each view has certain properties and behaviors that make it especially well-suited to display certain types of information. The demo program used the "split view" type. If you have seen the native email app on an iPad you've seen a split view. It has a list on the left side (in our case a list of customers) and the detail for a selection from that list on the right side (in our case the detail info for the currently selected customer).

• Initialize the view with labels and initial data.

• The event processing loop, updating the view as required. For example when a customer was selected from the list an event fired telling the program to retrieve the customer's record from the file and display the details.

We will have to write a QMONITOR replacement for the iPad to present a login screen and/or menu. We still need to investigate printing capabilities.

Of course we were asked about Android. We actually looked at it first but abandoned it first because there are too many platforms to support and second because the iPad clearly has the market share. Perhaps we will revisit Android once the iOS version is completed. If Android support is required by your customers, you can always write XAP apps which would work on any platform but are much more complicated because of all the layers. Plus CometAnywhere Mobile gives you access to the iPad's accessories such as the camera and location services.

CometAnywhere Mobile is CosW written for iOS. It looks to Comet exactly like a regular CometAnywhere client.

We have not yet decided on how CometAnywhere Mobile will be sold, distributed, or licensed. There was discussion about a possible free license option to handle mass market apps. CometAnywhere Mobile may only be available to Comet32 users.

CADev

CometAnywhere Client Install

The CA install process is one that has been reworked many times. Just when we thought we had it right Windows 7 came along. We used to install the files in a sub-folder to "Program Files" but in Win 7 this is protected and requires the user have full admin privileges. Now we recommend you run a full Comet install for your CA clients and choose a folder such as C:\Comet.

There are some unresolved problems with this method. First the current Comet install is simply a self-extracting .zip. It has no way of offering to create the desktop shortcut. Perhaps we can get WinZip to run a setup.exe program to create the shortcut. Second existing shortcuts pointing to the old "Program Files" location need to be changed.

Clients are kept up to date either through automatic updates or manually. If automatic updates are enabled, CMONITOR compares the host's version to the client's and will update the client if the host has a newer version. Automatic updates may be turned on or off by running the CAUPD program. In order to turn them off you must be using the secured version of QMONITOR because the on/off flag is stored in the QMONITOR password file. To do a manual update, run CAUPD from the client. CAUPDATE should not be used. It is obsolete and will be removed from REL in the next release.

Robert suggested that the CA shortcuts should point to Comet.exe from the full Comet release on the host. When Comet.exe is run, it would automatically copy the current versions to the client's temp folder so they would always be up to date.

Marc wanted to know exactly how the remote's version was retrieved by CMONITOR. Here's the code which gets the Comet build number for the client. This is compared to the host's version stored in CAUPDVSN.TXT in TMP:

RemoteVsn$ = strip(str(IHexDec(Sub(Sts(0), 19, 2))))

TLS Support in Emailptr

STL Containers

CometPDF

Wish List

Greg asked for IB access to new VS 2010 MFC controls. This would require converting CosW to VS 2010 and adding support for themes. No decision was made.

Greg requested help using WinSock to access web services from sites such as USPS, Google Maps, FedEx, etc. Robert posted a sample program to the Code Library

Greg requested some way to get Comet.exe to load Comet32 by default even for 32-bit systems.

Several people were interested in eliminating the need for the physical dongle for Comet security. Jim proposed that maybe we could host a dongle server that would send a unique dongle id to the client using SSL. We need to work out the details. Obviously this would only be available to security servers with internet access.

There was a request to indicate on the QTILITY menu which utilities have CometExplorer versions. It was pointed out that since CometExplorer is a subscriber product little support for multi-keyed files is available thru QTILITY. Along the same line, it was pointed out that since document archives are a subscriber product and Comet32 doesn't support QSPOOL that non-subscribers have no spooling option at all in Comet32.

CometConnect and Disaster Recovery

Jim spoke for a few minutes reminding everyone of the availability of the CometConnect and Disaster Recovery products.

With CometConnect users connect to one of our servers and run their own programs on their own data. The Comet Connect server is maintained by Signature Systems. It will always have the latest stable versions of Comet and the Comet File Server. This is perfect for users who don't want the hassles of maintaining their own full network in-house. It can also be useful as an archive for customers who have left Comet but still want access to their historical data. Every night CometConnect makes a zip file containing your data and puts it on a separate server for safe keeping. There is no better backup than a backup scheme that copies your data off site. If you choose, it can be automatically transfered to your designated user when they log on each day.

The Comet Disaster Recovery Service uses CometAnywhere technology to duplicate your existing Comet data and programs on a remote server providing a redundant system that can be initialized quickly in case of a disaster. By making automated, periodic updates to the remote server, you are insured that if something happens to your local system, there is an up-to-date and physically distinct remote system capable of resuming normal business operation with minimal downtime. Each day, at a time you choose, all of the changes to your data files is transmitted securely to one of Signature System's servers. It is then made available for your testing to make sure all was duplicated successfully. In the event of a disaster, once Signature Systems is notified, we will immediately increase the number of users and sessions for your account. At this time your users can log into the server with Comet Anywhere in order to continue their work remotely. You will be able to get to all of your data immediately and even be able to perform basic business tasks. We will be there, working side by side with you to work through any issues you have and help you recover. Once new hardware is in place, we will send a copy of all your data and programs back to you, which should put you right back in business.

Next Meeting

Grant, this one's for you. By overwhelming majority San Diego was chosen as the location for the next meeting. Alan mentioned that he recently had a good corporate experience at the Courtyard Marriott at Hotel Circle. We are planning for Fall 2013. Speaking of Grant... several attendees expressed their gratitude for all the help he gives them on the forum. Thank you, Grant!!