<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I find it easier to just apply the patches to the tree to have a
better context. Some of the things I've found may be from the past.<br>
<br>
* TPSEngine -<br>
- you have defined a number TKS_RESPONSE_xxx constants which I
have defined in IRemoteRequest.java. I think IRemoteRequest.java is
a better place since I have TKS server side using those constants as
well. If agreed, how about removing those 6 constants from
TPSEngine? I checked and i see in your code you are not using them
yet anyway, so it should not be too much trouble.<br>
<br>
* TPSFormatProcessor<br>
- In our old tps, I have always questioned the existance of the
RA_Format_Processor as well as the other xxx_Processor's other than
the RA_Processor.cpp and RA_Enroll_Processor.cpp where the real
code were in.<br>
My question is, is there going to be an attempt of putting real
format code into the TPSFormatProcessor, etc, or we are merely going
to do a direct conversion of C++ to Java? The reason why I ask is
because the TPSFormatProcessor and all probably serve not much
purpose unless we put something useful in them. We can probably
leave them as is for now and think about it later. I just want to
bring it up so we can keep it in mind to ponder on.<br>
<br>
* Would it make sense for APDUResponse to carry a boolean status so
that checkTokenPDUResponse() only needs to be processed once and
status set at the time? Anyway, if there is concern of veering off
to far from the old tps course then we can keep the return rc style.<br>
<br>
* I don' t see in the format() where you pass in the skipAuth value.<br>
<br>
* I may have missed it, but I don't see you checking if cplc_data
< 47 (a magic number in old tps). <br>
<br>
* why do you change the variable name token_status to status? I
think token_status, or if you wish, tokenStatus, is more
descriptive.<br>
<br>
* why do you check if (session == null) in the middle of assigning
major and minor versions? Could you not have checked this earlier,
like near the beginning of format()?<br>
<br>
* the old tps might be wrong, but I just want to know why is it that
it would assign 0 to all those versions if token_status == NULL,
while you bumped it out?<br>
<br>
* perhaps we want to consider keeping the tokenType somewhere we can
retrieve (not re-calculated and re-retrieved) easily during a
session, instead of passing it around as a parameter. Where is a
good place to do that?<br>
<br>
that's it for now.<br>
Christina<br>
<br>
<div class="moz-cite-prefix">On 03/13/2014 04:29 PM, John Magne
wrote:<br>
</div>
<blockquote
cite="mid:1322965798.35507730.1394753357470.JavaMail.zimbra@redhat.com"
type="cite">
<pre wrap="">Ticket #895 <a class="moz-txt-link-freetext" href="https://fedorahosted.org/pki/ticket/895">https://fedorahosted.org/pki/ticket/895</a>
Further work on TPS Processor, format operation.
This patch gets a bit farther on the TPS format operation, just before applet upgrade, which will also need secure channel functionality.
Also, patch provides some misc clean up and functionality.
1. Method to calculate the token type.
2. Some added convenience methods to get various config params for the Format operation.
3. More progress for the format operation up until we attempt to upgrade the applet.
4. Added TPSException that holds a message and end op return code. Can be used to throw from anywhere and the return code makes it back to the client.
---
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Pki-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pki-devel@redhat.com">Pki-devel@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pki-devel">https://www.redhat.com/mailman/listinfo/pki-devel</a></pre>
</blockquote>
<br>
</body>
</html>