jiri sasek - Sun Microsystems - Prague Czech Republic wrote:
> Samba is only the available CIFS server in Solaris 10. Solaris 10 is
> production system.
>
> Please do not concentrate only on the particular solutions. In scope
> of this case is support of off-line files also on production system.
But I presume you also want support this on Solaris Nevada/OpenSolaris.
Unless you are proposing a case *only* for Solaris 10, we need to have a
solution that works for our solutions on future operating systems as well.
Architecturally, my concerns still stand. Unless we have a solution for
OpenSolaris and CIFS, my vote would remain a deny.
-- Garrett
>
> Jiri
>
> Garrett D'Amore wrote:
>> Darren J Moffat wrote:
>>> Alan.M.Wright wrote:
>>>> Providing this as a temporary solution to relieve a customer problem
>>>> is excellent. My disagreement is that it should be committed as a
>>>> long term solution for offline support when we already have a defined
>>>> system attribute mechanism that could be used to solve the problem
>>>> via libc.
>>>
>>> Given the above I'm derailing this case for the purpose of writing
>>> an opinion with Advice to fund the above mentioned project and to
>>> point out the issue of adding Solaris/Sun functionality to Samba
>>> with no planned match for the in kernel CIFS server.
>>>
>>> PSARC members please are you willing to vote based on the above our
>>> would you like to see draft opinion text first. I've marked the
>>> case as "waiting need vote" for now.
>>>
>>> Note that this is *derail* not *deny* (though depending on the vote
>>> it could be but I doubt it).
>>>
>> I was the original +1. I would normally have thought to vote to
>> approve, but given the recent discussion, I'm not sure I am ready.
>> Since this solution to the problem is temporary, and since binary
>> relief is already available to the customer, I am inclined to vote to
>> deny this project until they have a solution that works with both
>> kernel CIFS and Samba.
>>
>> On a higher level, as yet another case where we have redundant
>> functionality in two (or more) different systems, it seems like
>> someone (PAC) ought to start funding an effort to consider reducing
>> the complexity of the system by also reducing the number of
>> duplicated subsystems. (Do we need both of these SMB servers? Do we
>> need a bunch of different web servers? Do we need both cups and
>> lpsched? Then the array of various different packet interception and
>> filtering mechanisms in our stack boggles the mind... at what point
>> does the fact that we have so much choice actually become a liability
>> to our customers rather than a benefit? Its *clear* to me that it is
>> already a liability in the cost to Sun engineering....
>>
>> -- Garrett
>>
>
