On 26-Aug-06, at 12:09 PM, David Sanchez wrote:
On Aug 26, 2006, at 11:42 AM, Paul Lynch wrote:On 26 Aug 2006, at 16:04, David Sanchez wrote:On Aug 26, 2006, at 6:31 AM, Paul Lynch wrote:On 26 Aug 2006, at 09:19, David Sanchez wrote:Looking into J2EE, Cayenne/Tapestry can compete with WO?No. Integration in a framework and the quality of its tools count for a lot (and are usually undercredited).I do not understand this fully. So, WO integrates better and have better tools (even though those are not from Apple).Most web server environments don't include all that is in WO. Making them all interface smoothly is a major task, and involves considerable extra work when compared to a pure WO deployment. The (Apple supplied) WO tools, XCode, WOBuilder and EOModeler, make managing the definition files that are required very much easier. Try a Spring/Hibernate deployment, or J2EE, to see what I mean. Configuration files can amount to more lines than your actual code, and maintaining them by hand isn't a joyful experience - WO tools substantially reduce this hassle.This is one area where Rails is strong - their philosophy is to avoid configuration files by assuming reasonable defaults, what I call "programming by consensus". WebObjects approach isn't as extreme, and has the advantage of being more flexible.I know. I absolutely agree with every thing you say.I hope, XCode will be used to develop WO in the future. I do not know how because Cocoa-bridge is deprecated. They would need to re- write all the WO apps to use Objective-C and generate Java code, made them full Java Apps or just do not provide them anymore.But if Apple thinks about making all the WO tools pure Java (or pure Objective-C), Why did they not show those apps first and later deprecate the old ones? Instead of deprecating and leave amateurs wondering....That's the little thing that I cannot understand.
Lets look at this from a completely different (hypothetical) angle:The WO Frameworks have a very large number of Apple developers pounding on them daily. These developers are working on projects that range from internal ones we never see to the external high profile ones like iTMS and .Mac. Some of the projects arguably are the highest trafficked WebObjects applications on the planet. I'm sure these developers are finding bugs - and fixing them because they need their stuff to work and they have access to the code. Many (though not all) are *not* using Xcode+WOBuilder+EOModeler to build their apps.
The WO Tools have a very small number of Apple developers assigned to them (Maybe 4, maybe less). The task of completely recreating the WO tools stack (I used "stack", do I get a prize?) sans a dependency to the Cocoa-Java bridge is virtually impossible given the resources available.
So from a completely pragmatic standpoint, if you were in charge of allocating resources for the tools within Apple, and you saw that the WOCommunity(tm) was doing an arguably better job at the task you were facing, would that not give you some ideas? Might you not say: "If we drop the tools development, we can free up resources to focus on improving the Frameworks and integrate the fixes and enhancements our internal groups are finding into the public releases".
That is what I think happened.For me, the bottom line is this: Regardless of what is going on in house at Apple, the boost this has given the WOCommunity is priceless.
Disclaimer: This is all conjecture, I have no inside information, feel free to dismiss it if you wish.
-- ;david -- David LeBer Codeferous Software 'co-def-er-ous' adj. Literally 'code-bearing' site: http://www.codeferous.com blog: http://david.codeferous.com -- Toronto Area Cocoa / WebObjects developers group: http://www.tacow.org
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to archive@mail-archive.com
