Peter,
> The parameter syntax for property opencard.terminals in opencard.properties
> is just a convention
> and depends on the specific CardServiceFactory.
> If your CardServiceFactory needs more/less parameters feel free to
> implement it that way.
Thanks, that's what I thought. That means that it's not as easy to
create an OCF administration tool that can administer the entries
for arbitrary card terminals (I guess that currently the OCF admin
tool is your favorite text editor :-).
Why was the scheme where there is a single property for all the
card terminals chosen, instead of something like:
opencard.terminals.gemplus.factory = com.[...].GemPlusFactory
opencard.terminals.gemplus.MyReader.modelname = gcr400
opencard.terminals.gemplus.MyReader.port = /dev/cua/a
opencard.terminals.gemplus.MyReader.baudrate = 9600
opencard.terminals.gemplus.MyReader.parity = none
Where the "MyReader" part of the property name refers to a particular
instance of a gcr400 reader (specified in the "modelname" property
for example), rather than the long and convoluted single-property
mechanism? Same for the "services" property - it seems that having
a number of terminal or service-specific properties would be a lot
easier to administer than having a single long property.
mike
--
----------------------------------------------------------------------------
Michael Bender E-Mail:
[EMAIL PROTECTED]
Sun Microsystems, Inc. Tel: 650-786-0498
901 San Antonio Road Tel Pager: 888-423-9066
Palo Alto, CA 94303-4900 URL Pager:
http://www.skytel.com/Paging/
Mailstop: UMPK18-110 Pager PIN: 4239066
----------------------------------------------------------------------------
Visit the OpenCard Framework's WWW site at http://www.opencard.org/ for
access to documentation, code, presentations, and OCF announcements.
-----------------------------------------------------------------------------
To unsubscribe from the OCF Mailing list, send a mail to
"[EMAIL PROTECTED]" with the word "unsubscribe" in the BODY of the
message.
