[644] in Enterprise Print Delivery Team
Re: Quick Debrief from Chat with Susan
daemon@ATHENA.MIT.EDU (Lynne E. Durland)
Tue Oct 31 22:05:18 2000
Message-Id: <4.3.2.7.2.20001031220151.00b0d6e8@po12.mit.edu>
Date: Tue, 31 Oct 2000 22:04:43 -0500
To: David F Lambert <LAMBERT@MITVMA.MIT.EDU>,
Enterprise Printing Delivery Project Team <printdel@MIT.EDU>
From: "Lynne E. Durland" <durland@MIT.EDU>
In-Reply-To: <200010312357.SAA05656@fort-point-station.mit.edu>
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="=====================_1843260==_.ALT"
--=====================_1843260==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
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
--=====================_1843260==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<font size=3>At 06:34 PM 10/31/2000 -0500, David F Lambert wrote:<br>
<blockquote type=cite cite>Here are some brief comments from my chat with
Susan.<br>
<br>
The security statement Ted wrote in the R-Ready days (predating our<br>
current org structure) is fine with her. However, she has no
plans<br>
to formally adopt this statement nor update the ITAG printing Web
page.<br>
She said this was too far down on her list to bother with. I
suggested<br>
it would have been nice for her or Jeff to indicate this when the<br>
discussions began over 20 months ago. Case closed.<br>
<br>
She was unaware of the way KLPR for Windows would not do the
hesiod(?)<br>
db query upon every execution of the command. She said this was
lower<br>
level information than she usually tracks. She suggested we ping
Tom<br>
Thornton (Mr Pismere) if we feel this is a real
issue.</font></blockquote><br>
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.<br>
<br>
<br>
<blockquote type=cite cite><font size=3>Her concerns and issues re Mac
dev work we heard from Theresa were<br>
based upon limited Mac dev resources in IS and the fact that it was<br>
felt that few Mac users would be taking advantage of the IPM client<br>
and service. She felt that Mac developer resources would be
better<br>
utilized on code which would end up on more MIT Mac desktops
(biggest<br>
bang for the buck basically).<br>
<br>
Susan would clearly prefer the use of Apache over Lotus Domino but<br>
did not say it was mandatory. Given the estimated additional
cost,<br>
this seems like a no-brainer decision. Let's proceed with
Apache.</font></blockquote><br>
Long term maintenance etc would be easier with the Apache server since
there is knowledge in house.<br>
<br>
<br>
<blockquote type=cite cite><font size=3>-Dave </blockquote><br>
<br>
Lynne<br>
<br>
</font><br>
</html>
--=====================_1843260==_.ALT--
