[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: 2nd call: binary incompatibility



I'd say break it in order to go with X/Open on this one. I make money off
this code as it now stands but I would find it much more advantageous in a
long-view to have things keeping with X/Open. 

Now, I have a question. What can members of the linux-pam using community
(read the free pam using community, as I'm aware this is being ported to
fbd and hpux too) to have any say in X/Open? If nothing, how about at
least being in the "notify" loop of X/Open, so we find out as this stuff
pops up?

Best,
Jim Hebert
jhebert@compu-aid.com

--
[W]ith IBM having abandoned any attempt to keep OS/2 in the low-end
niche, it looks like Linux is increasingly the only viable, ______________
non-Microsoft-assimilated desktop PC operating system.     /   jhebert
-- David Sewell <dsew@packrat.aml.arizona.edu> in c.s.m.a / @compu-aid.com

On Tue, 16 Sep 1997, Andrew G. Morgan wrote:

> Hi,
> 
> I didn't get any feedback last time from Red Hat or Caldera, so here it is
> again..
> 
> The long and the short of it is that our developed API is incompatible with
> that of Solaris and hence X/"Open".  (The incompatibilites stem from the
> vagueness of the RFC and the fact that Sun decided to change something
> without mentioning it to us..) I asked before what people thought
> about how we should proceed and I was hoping to get comment from some
> business that is likely to have to field more help-line calls than I do...
> 
> The two functions in question are pam_strerror() and the conversation
> function/protocol.
> 
> In the former case, Solaris decided to require the pamh argument to be
> supplied to the pam_strerror() function.  We (in keeping with the PAM RFC)
> do not.
> 
> The latter case concerns the pam_response structure and how it is filled. 
> In some cases they do as we do and in others we differ.
> 
> I am on the verge of saying 0.58 is still development code in my book and it
> is thus ok to simply break with the past.... However, I am sympathetic to
> what those that make money off this code want, so please discuss!  Perhaps
> all I should be concerned with is that those with a commercial interest are
> aware that we are going to break backward compatibility.  But I'd rather know
> now than later...  :^)
> 
> Cheers
> 
> Andrew
> -- 
>                Linux-PAM, libpwdb, Orange-Linux and Linux-GSS
>                   http://parc.power.net/morgan/index.html
> 
> --
> To unsubscribe: mail -s unsubscribe pam-list-request@redhat.com < /dev/null
> 



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []