[646] in Enterprise Print Delivery Team
Re: Quick Debrief from Chat with Susan
daemon@ATHENA.MIT.EDU (David F Lambert)
Wed Nov 1 08:24:56 2000
Message-Id: <10011011324.AA06045@MIT.EDU>
Date: Wed, 01 Nov 00 08:22:13 EST
From: David F Lambert <LAMBERT@MITVMA.MIT.Edu>
To: Enterprise Printing Delivery Project Team <printdel@MIT.EDU>
In-Reply-To: Message of Tue, 31 Oct 2000 22:04:43 -0500 from <durland@MIT.EDU>
I'll pursue the KLPR issue with Thornton. -Dave
On Tue, 31 Oct 2000 22:04:43 -0500 Lynne said:
>
>At 06:34 PM 10/31/2000 -0500, David F Lambert wrote:
>>Here are some brief comments from my chat with Susan.
>>
>>The security statement Ted wrote in the R-Ready days (predating our
>>current org structure) is fine with her. However, she has no plans
>>to formally adopt this statement nor update the ITAG printing Web page.
>>She said this was too far down on her list to bother with. I suggested
>>it would have been nice for her or Jeff to indicate this when the
>>discussions began over 20 months ago. Case closed.
>>
>>She was unaware of the way KLPR for Windows would not do the hesiod(?)
>>db query upon every execution of the command. She said this was lower
>>level information than she usually tracks. She suggested we ping Tom
>>Thornton (Mr Pismere) if we feel this is a real issue.
>
>YES this is an issue, as it limits the ability to "switch" a printer from
>an Athena to ipm without requiring human intervention on the
>desktop.................and that is just my first thought on the matter.
>
>
>>Her concerns and issues re Mac dev work we heard from Theresa were
>>based upon limited Mac dev resources in IS and the fact that it was
>>felt that few Mac users would be taking advantage of the IPM client
>>and service. She felt that Mac developer resources would be better
>>utilized on code which would end up on more MIT Mac desktops (biggest
>>bang for the buck basically).
>>
>>Susan would clearly prefer the use of Apache over Lotus Domino but
>>did not say it was mandatory. Given the estimated additional cost,
>>this seems like a no-brainer decision. Let's proceed with Apache.
>
>Long term maintenance etc would be easier with the Apache server since
>there is knowledge in house.
>
>
>>-Dave
>
>
>Lynne
