[Jposloader-discuss] JCL Status

[Ron K. <ron...@ya...>]

JCL-ers,
   
    Greetings.  Along with Boyd Dimmock of IBM, I am the co-lead of the JavaPOS committee.
   
    The JCL project, as the saying goes, has been quiet ... too quiet.  I know that Michael Maximllian (or Dr. Max as he is known to his intimates) has moved on to other things, and hasn't been actively involved in years ... yet he is still listed as the project leader.  
   
    The last release (JCL v2.2) was completed over 2 years ago, and there has been no response to the 5 open bugs in at least that long.  To that I would add one more, which comes directly from Home Depot, a major retail industry JavaPOS adopter.
   
    It originally came with a proposed solution ... but I think getting a clear understanding of the requirements is more important then jumping to define a solution.
   
  **********************************************************************************************
  To configure a device for use by a POS application, today an end user needs to 

  1) configure the JCL properties file to specify the populator file name;
2) add a Jpos entry for every device services in the populator file.
 
To the end user, the JavaPOS entry, serves 2 purposes - to provide factory class name and service class name to JCL for binding, and to provide configuration parameters to the device service implementation  This is of no particular interest to the end user.  However, the end user bears the burder to do this configuration, and maintain the in-store configurations for all POS terminals.  
   
  In practice, many retailers might have different equipments in different store groups.  That means, the retailer needs to keep multiple versions of the populator file, or need to find a way to differentiate them.
  **********************************************************************************************
   
    In other words, there is a clear desire to move the JCL towards a more "plug and play" functionality, from the point of view of the retailer, and also from the point of view of the Device Service writer, who wants to release one jar with a minimum of initial configuration requirements.  The JCL does the job, but the administrative burden gives JavaPOS  a disadvantage in the marketplace ... especially given something like the recently released POSNet Explorer
   
   One imagines adding some sort of callback for a Device Service, when, after being init'd, it could query the JCL for configuration info, or reply with what it knows.  Something like that.  I'd ask someone more knowledgable about the JCL to phrase this in a formal bug / request for enhancement. 
   
    But the more immediate need is reactivating this project, which is one of the lynchpins of JavaPOS, and essential for its success.  Can those folks who are active and willing to participate in the community re-identify themselves?

  Much thanks,
   
  Ron Kleinman
  Sun Microsystems

		
---------------------------------
Relax. Yahoo! Mail virus scanning helps detect nasty viruses!