April 2012 Meeting Minutes

From CometWiki

(Difference between revisions)
Jump to: navigation, search
(DocMgr Enhancements)
(modified tls printer section)
Line 85: Line 85:
  RemoteVsn$ = strip(str(IHexDec(Sub(Sts(0), 19, 2))))
  RemoteVsn$ = strip(str(IHexDec(Sub(Sts(0), 19, 2))))
-
==[[TLS Support in EmailPtr]]==
+
==[[TLS and SSL Support in EmailPtr]]==
-
For Comet32 only, this allows email to be sent through providers that require authentication beyond a user name and password.  Its use requires only a small change to your email.ini:
+
For Comet32 only, this allows email to be sent through providers that require authentication beyond a user name and password.  Use of TLS does not require any change to your email.ini file or any special mnemonic.
-
 
+
-
SecureServer = TRUE
+
-
ServerAuthenticate = TRUE
+
-
 
+
-
There will also be mnemonics to set these parameters.  This will be released in Comet32 version .460 and requires REL 12.06 or higher.
+
 +
If the response to the EHLO command sent to the server includes the phrase STARTTLS, the email printer will switch the connection to TLS to conclude the authentication process. This is especially useful when using the GMAIL server.
 +
==[[STL Containers for Comet32]]==
==[[STL Containers for Comet32]]==

Revision as of 04:24, 1 June 2012

Contents

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 be in a folder directly under the parent archive. DocMgr will attempt a dynamic access if the user doesn't have access to the sub-folder. 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

Brian gave a recap of the CADev_-_CometAnywhere_Remote_Development utility. This provides a facility for editing and compiling IB programs over a CometAnywhere connection. Be sure to run CometUESetup.exe once on the client before running CADev even if the CA client has already been setup to do IB compilations locally. You will find CometUESetup.exe in your Comet executables folder $(COMET).

There was a request for an option to automatically transfer to the client all include files for the source program being edited. Currently you need to specifically choose each file you want to edit.

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 and SSL Support in EmailPtr

For Comet32 only, this allows email to be sent through providers that require authentication beyond a user name and password. Use of TLS does not require any change to your email.ini file or any special mnemonic.

If the response to the EHLO command sent to the server includes the phrase STARTTLS, the email printer will switch the connection to TLS to conclude the authentication process. This is especially useful when using the GMAIL server.

STL Containers for Comet32

Justin recapped the concept of containers, recently introduced for Comet32. STL_Containers are C++ data structures for storing collections of data. They are similar to arrays but each container is designed for a different use and each has its own set of utility functions. We implemented 5 containers for IB: vector, list, map, stack, and queue.

The vector and the map can easily be related to IB concepts you are already familiar with. Think of a vector as an IB array but with no declared limit on the number of elements. You can add any number of elements at runtime and the vector will grow in size as required. And while for an IB array you must declare its type (string or numeric), in a vector any element may be of either type. You reference an individual element by its element number just like an array.

You can think of a map as a good old fashioned Comet keyed file but in memory instead of on disk. Each entry in a map consists of a key and the data associated with that key. You reference an individual element by its key rather than its element number. Like a vector it grows dynamically as needed. The example of the new Replace function in the XAP2 discussion above uses a map to perform a merge.

Each container type has associated functions that are designed specifically for the properties of the container. Some examples are first and last, next and prev for iteration, element counting, and push/pop functions. We would like to expand on these especially the addition of a sorting function. It was pointed out that it would be great if the sort function could use the concept of a formatted STR function to define the format of the sorted data via an editmask (see request for this in "Wish List" below).

For all the details of our implementation check out the STL_Containers Reference on the wiki. You can get additional theoretical info by googling "STL Containers".

CometPDF

Brian recapped CometPDF which is an installable PDF printer for use on Comet systems using a freely available printer driver obtained from Bullzip. Recently a new mnemonic Mnemonics_"S"#.28SetViewportOrg.29 was added allowing you to set the margin offsets for the printer. Unlike other pdf printers CometPDF uses "edge-to-edge" margins with no offset by default. Offsets will be reset when the printer is closed.

Robert asked if the searchable text in the pdf could be removed to make the .tif file smaller for emailing and processing. He says other products have this option.

Greg was surprised nobody had asked for the ability to password protect the .pdf.

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, and FedEx. Robert posted a sample program to the Code Library (ws-test.ibs) demonstrating how to do this.

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.

Robert requested a variant of the STR function that allows an edit mask as a 2nd parameter to define the format of the result. This was a popular request. Jim suggested that another way to do this now is to use GetFormat. (Since the meeting I tried this and it didn't seem to apply the edit mask in the format to the string in the GetFormat.)

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.

There was a request for a search utility for .ibs programs that would process all the include files when searching for a string - similar to SEEK in CED. Currently the only way to search .ibs files is either to use the QTILITY search or the UE Search->"Find in Files" however both of these methods search an entire folder rather than searching specifically the files involved in the .ibs.

Jim requested that we have the option to eliminate or at least reduce all the CFAMNetServe log files. Currently a new file is created for each day. Brian suggested they could be off by default with an option to turn them on for debugging. The setting could be stored in the registry.

Greg requested a Comet system level event that would fire under circumstances such as a particular file being updated. He would use this to run a special program in reaction to that update. Robert suggested he might be able to catch file updates by monitoring the Windows event log. Robert also does something like this by having his program write a log file which he then monitors from a background partition. Greg would prefer being able to set this up at the system level so as not to have to modify every program. Jim suggested the file system transaction backup project could possibly have provided a solution. This project is not currently being worked on however.

Miscellaneous

Greg recommended the new power management mnemonics (SetThreadExecutionState) and (GetSystemPowerStatus) Mnemonics_"G"#.28GetSystemPowerStatus.29 be used to prevent a Comet computer from going to sleep as this can cause the network connection to be lost.

It was mentioned that when DHCP is renewed while Comet is running this can cause issues for the security server even if the IP address doesn't change.

A couple of attendees recommended using mySQL to archive Comet data for easy reporting, interfacing with external systems, and web access.

Robert mentioned he had been unable to get the Comet Services working on a Windows 7 machine but couldn't remember the details. He thinks it had to do with errors seeing the USB security token. He moved the token to an XP machine in the network and all is well.

The wiki needs work. Documentation is incomplete. There are broken links, etc. Jim pointed out that it is a wiki and you are all invited to edit. Contact us if don't yet have a user name and password for that.

Jim posed the question of whether requiring one file server license for each file server accessed was a problem. This requirement means that you can consume file server licenses faster than Comet licenses if you need access to more than one server.

Someone asked about using the Comet32 TRACE capability from a CA client. This won't work because the trace window lives on the host.

Jim asked Barb to remind everyone that we had added the ability to access the Windows registry from IB programs - even in Comet16. Your entries may be under either HKEY_CURRENT_USER\Software or HKEY_LOCAL_MACHINE\Software. This is a great place to store user settings for your application. The new Registry_Mnemonics are: (RegCreateKey=), (RegSetValue=), (RegGetValue=), (RegDeleteKey=), and (RegDeleteValue=).


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!!

Personal tools