Projects/Windows CCAPI - Revision history

SamHartman: Update blocking objections

2008-04-03T18:30:48Z

Update blocking objections

Kpkoch: TODO done; removed.

2008-03-13T20:47:00Z

TODO done; removed.

Kpkoch: Remove TODOs that are code changes instead of code policy.

2008-03-13T20:46:28Z

Remove TODOs that are code changes instead of code policy.

Kpkoch: Clarify this is not an external API document.

2008-03-13T20:40:11Z

Clarify this is not an external API document.

Kpkoch: Update todo text.

2008-03-10T14:46:21Z

Update todo text.

Kpkoch: Update server initialization description.

2008-03-10T14:39:55Z

Update server initialization description.

Kpkoch: Remove obsolete text marked as [old].

2008-03-10T14:31:29Z

Remove obsolete text marked as [old].

Kpkoch: Update text of Server endpoint functions.

2008-03-10T14:27:04Z

Update text of Server endpoint functions.

Kpkoch: Update client endpoint function descriptions.

2008-03-07T21:54:58Z

Update client endpoint function descriptions.

Kpkoch: Update client endpoint function descriptions.

2008-03-07T21:50:33Z

Update client endpoint function descriptions.

@@ Line 365: / Line 365: @@
 ===Discussion===
 * Actually act on all the todo items that are things that need to happen to this proposal before submitting for approval.
 * For todo items that are things that need to happen to the code, open bugs targeted at the 1.7 release; the project page is mostly not supposed to change once approved unless design changes are needed.
 * You need to follow API conventions  I.E. ccs_* needs to be a server side routine.
 * Why do you believe that  having elevated process be unable to access tickets is  the correct  behavior for the product?
 --[[User:SamHartman|SamHartman]] 14:07, 4 March 2008 (EST)

← Older revision		Revision as of 20:47, 13 March 2008
Line 340:		Line 340:

	===Overview===		===Overview===
−	* Add CCAPI V2 compatibility description.

	===Code / implementation===		===Code / implementation===

← Older revision		Revision as of 20:46, 13 March 2008
Line 343:		Line 343:

	===Code / implementation===		===Code / implementation===
−	* Recover from weird error in RpcMgmtIsServerListening
−	* If the server's SST doesn't match the SST from the client it means this is a new server. Server must return an error indicating that the previous connection was lost.
	* Be explicit about sizeof(SST) [64 bits].		* Be explicit about sizeof(SST) [64 bits].

@@ Line 5: / Line 5: @@
 ===Client/Server Transport===
 The CCAPI is a local service provided to local clients.  The implementation is operating system independent, but the transport between the clients and server is not.  The transport is what's described here.
 ===Client Definition===

@@ Line 337: / Line 337: @@
 ===Overview===
 ===Code / implementation===
@@ Line 347: / Line 347: @@
 ===Explorations===
-* Verify:  If a user has tickets and then starts a process with elevated privileges, the elevated process will not be able to communicate with the pre-existing credential cache.
+* Confirm or deny:  If a user has tickets and then starts a process with elevated privileges, will the elevated process be able to communicate with the pre-existing credential cache?
 ==Review==

@@ Line 218: / Line 218: @@
 ===Server initialization:===
-Server is initialized by client starting a new process. There should be only one server process per Windows username.
+The server is initialized by client starting a new process. There should be only one server process per Windows username.
 * Capture server start time (SST).
 * Start listener thread, create listener endpoint, listen on krbcc.<LSID>.ep endpoint.

@@ Line 156: / Line 156: @@
 ====ccapi_rpc_request_reply(msgtype, TSP*, UUID, SST, replylen, reply, status)====
 Operating system independent routine ccs_server_send_reply calls ccs_rpc_request_reply to send any data to be returned as a result of a CCAPI function call.  The client will copy the reply data to a cci_stream that the client CCAPI code can interpret.
-There is exactly one ccapi_rpc_request_reply per ccs_rpc_request.
+There is exactly one ccapi_rpc_request_reply per ccs_rpc_request.<br>
 '''msgtype''' CCMSG_REQUEST_REPLY.<br>
 '''TSP*''' Address of the client's thread specific storage.  The reply procedure uses TSP to know which thread's storage to put the '''reply'''.<br>
@@ Line 164: / Line 164: @@
 '''status''' return code indicating successful receipt of the call, not successful execution of the reply function on the client.
-====ccapi_listen(hBinding, msgtype, status)====Called asynchronously from Windows-specific code when a connection is being established.
+====ccapi_listen(hBinding, msgtype, status)====
 ==Test Plan==

@@ Line 148: / Line 148: @@
 ====ccapi_rpc_connect_reply(msgtype, TSP*, UUID, SST, status)====
-Sends result of the connect request to the client.
+Sends result of the connect request to the client.  '''msgtype''' CCMSG_CONNECT_REPLY.<br>
 '''TSP*''' Address of the client's thread specific storage.  The reply procedure uses TSP to know which thread's storage to put the '''reply'''.<br>
-'''UUID''' The client's UUID.  Used by the server to construct the client's endpoint so it know's which client to send the reply to.<br>
+'''UUID''' The client's UUID.  Used by the reply procedure to construct an event name used to signal the client thread that a reply has been received.<br>
+'''SST''' The time when the server started.  If it is different from the SST the client saved when '''connect'''ing, it means the server has restarted since the connection was established.<br>
 ====ccapi_rpc_request_reply(msgtype, TSP*, UUID, SST, replylen, reply, status)====
-Operating system independent routine ccs_server_send_reply calls ccs_rpc_request_reply to send any data to be returned as a result of a CCAPI function call.  There is exactly one ccapi_rpc_request_reply per ccs_rpc_request.
+Operating system independent routine ccs_server_send_reply calls ccs_rpc_request_reply to send any data to be returned as a result of a CCAPI function call.  The client will copy the reply data to a cci_stream that the client CCAPI code can interpret.
 '''msgtype''' CCMSG_REQUEST_REPLY.<br>
 '''TSP*''' Address of the client's thread specific storage.  The reply procedure uses TSP to know which thread's storage to put the '''reply'''.<br>
-'''UUID''' The client's UUID.  Used by the server to construct the client's endpoint so it know's which client to send the reply to.<br>
+'''UUID''' The client's UUID.  Used by the reply procedure to construct an event name used to signal the client thread that a reply has been received.<br>
 '''SST''' The time when the server started.  If it is different from the SST the client saved when '''connect'''ing, it means the server has restarted since the connection was established.<br>
 '''reply[replylen]''' CCAPI data - a counted binary array.  Any data the CCAPI function needs to return to the caller.<br>

@@ Line 145: / Line 145: @@
 ===Client endpoint functions===
 Each client thread creates a CCAPI_<UUID> endpoint. It has the functions
-* ccs_rpc_connect_reply(msgtype, TSP*, uuid, SST, status)<br>Called from Windows-specific code.
+====ccapi_rpc_connect_reply(msgtype, TSP*, UUID, SST, status)====
 ==Test Plan==