Re: [OpenAFS-GK] Re: rxk5 openafs for windows work in progress--seems to work

Wow, this needs to be pruned something awful.
>>
>> [1] k5ssl is in my opinion a horrible name. We aren't implementing
>> RFC 2712 and we aren't implementing "ssl" and if we were we should be
>> calling it "tls".   If this is a private version of a krb5 library for
>> openafs then lets call it that:  "afskrb5".   The fact that it is
>> implemented on top of OpenSSL's libcrypt is really irrelevant.

Someone has functions called afskrb5. How about k5afs or afsk5 or 
something of that ilk?

> //2 - com_err issues.
> 	Each of these might exist and is likely to be an afs issue in a
> 	given environment.  They all has gratuitous incompatibilities, and
> 	often also depending on version & build configuration:
> 		e2fsprogs	- tytso, debian linux
> 		heimdal		- kth, various
> 		mit		- from source for unix,
> 				also windows, macosx, solaris
> 	and especially (!) openafs
>
> 	problems include:
> 		compiling error tables

Where is compiling a problem?

> 		non-standard bases - or openafs special errors

We eliminated the odd bases in OpenAFS by switching to error tables of the 
correct case name. The special errors still suck.

> 		linking error tables into error table list.
> 		pthread support
> 		lower-case (negative) error codes
> 		long vs. int error codes.
> 	Presumably all of these can be worked out.  Someday.
> 	So far, people mainly ignore these.  In the openafs distribution,
> 	aklog reports numeric codes.  That sucks.

That was Ken's compromise to the "how do you link error tables" issue, 
istr.

> I've been telling rees & derrick about successive versions
> of rxk5.  With the next m release, I will tell
> 	[email protected]
> unless people object.  My hope is to shortly tell openafs-devel@
> about it as well.

Thanks.