Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Message-ID: <3FBC489F.4050902@iseran.com>
Date: Wed, 19 Nov 2003 20:52:47 -0800
From: Steve Loughran <steve_l@iseran.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: Ant Developers List <dev@ant.apache.org>
Subject: Re: In case you haven't seen this yet
References: 
 <DD35CC66F54D8248B6E04232892B63386DB55E@RED-MSG-43.redmond.corp.microsoft.com>
In-Reply-To: 
 <DD35CC66F54D8248B6E04232892B63386DB55E@RED-MSG-43.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Alex Kipman wrote:
> Hello everyone,
> 
> At the risk of reliving a very painful subject, I wanted to point the 
> community to the published "chapter 2" of Brent Rectors book entitled 
> Introducing Longhorn for Developers.  The link is here:
> 
> _http://msdn.microsoft.com/Longhorn/understanding/books/rector/default.aspx?pull=/library/en-us/dnintlong/html/longhornch02.asp#longhornch02_topic1_
> 
> You will note Brent re-wrote the entire section about "Why not 
> Ant/NAnt", and what you see on this link is what you will see printed on 
> the book when it hits your local bookstore.  In other words what was 
> printed in the PDC copy of the book will no longer be printed.  I hope 
> you find the current text to be more precise and especially less 
> adversarial. 

Yes, it is. It still tries to put a positive spin on the situation, but 
it is written from a position of greater understanding.

Myself, I'd have written

"Although MSbuild derives its notions (and terminology) of Project, 
Target and Task from Ant, the design goal of seamless integration with 
the VS IDE forced it to move the dependency logic from inside the tasks 
into declarative statements in the build file. This permits the build 
engine to determine dependencies without executing the tasks, and lets 
the IDE show these dependencies. The primary weakness with this approach 
is that it forces build file authors to determine the dependencies by 
hand, rather than letting the task authors encode the rules into their 
tasks. Were it not for seamless IDE integration, this would make MSBuild 
more 'expensive' to support in terms of build file effort. The secondary 
weakness is more subtle and a longer term issue: by explicitly relying 
on file system based dependencies, the tool cannot comprehend 
dependencies other than between files on locally mounted file systems 
-such as between components in zip files, or between a local system an 
an SSH- or FTP- connected server. This will not be an issue with the 
initial task suite or uses, but could prove to be a long term handicap"

Of course, Brent is free to write what he wants, and you are free to put 
what you want up on MSDN. I shall save that paragraph for use in the 
next edition of Java Development with Ant.

> 
> Just thought you should know,
> 
>    Alex Kipman (_AKipman@microsoft.com_ <mailto:AKipman@microsoft.com>)
> 
>    Program Manager
> 
>    MSBuild Team

no problem. Now that I have read the rest of the book, I can say that I 
felt the bits on distributed systems (indigo) and laptops weak. 
Specifically:

-There was no clear understanding of the fundamental issues with past 
distribution technologies (RPC, OSI, ANSA, CORBA, EJB, DCOM), without 
which the arguments in favour of an XML-based asynchronous only 
communications protocol talking to remote services, not remote objects 
doesnt make sense. A little bit of history would go a long way, not 
least a reference to "A Note on distributed computing", Kendall et al, 
Report Number: TR-94-2, 
http://research.sun.com/techrep/1994/abstract-29.html; as it is the 
seminal paper that argues against making the fact that one is making a 
network call transparent (which of course RPC based systems all try to do).

-Having worked on laptop futures a few years back, and the co-inventor 
of various obscure laptop patents over that time, I felt the chapter on 
mobility missed out on the fundamental users issues regarding laptops. 
Which is, by and large, laptop battery life is acceptable for most 
users, it is the adaptation to changes in network state and use context 
that is missing from today's applications (cf 
http://iseran.com/Steve/papers / the secret life of notebooks; an 
adaptive and context aware laptop). Writing all the various P/Invoke 
wrappers to laptop power state API calls and then integrating with the 
app is usually a waste of development effort -writing an app to handle 
the sudden disappearance and then return of a network is far more 
tangibly useful.

Its never a good sign when you read a book about some new technology (in 
this case longhorn) and you end up with the impression that for every 
bit in the book about which you had any detailed knowledge, the author 
didnt really understand the problem. It gives you deep misgivings about 
the quality of the coverage of the areas you dont have detailed knowledge...

-Steve


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org