Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 54733 invoked by uid 500); 21 Apr 2003 14:34:43 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 54579 invoked from network); 21 Apr 2003 14:34:42 -0000 Received: from onramp.i95.net (205.177.132.17) by daedalus.apache.org with SMTP; 21 Apr 2003 14:34:42 -0000 Received: from apache.org ([66.208.12.130]) by onramp.i95.net (8.12.9/8.12.9) with ESMTP id h3LEYfwT027938; Mon, 21 Apr 2003 10:34:41 -0400 Message-ID: <3EA40180.9060908@apache.org> Date: Mon, 21 Apr 2003 10:34:40 -0400 From: Berin Loritsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Vincent_tenc=E9?= , dev@avalon.apache.org, cocoon-dev@xml.apache.org Subject: Re: [RT] Distilling the requirements for Block Support References: <3EA00212.6040603@apache.org> <001c01c306f2$70906770$7a00a8c0@tux> In-Reply-To: <001c01c306f2$70906770$7a00a8c0@tux> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Vincent tenc� wrote: > There seem to be interest in the block concept at avalon-dev as well, which > is rather good news. But where do we go from there? What actions should we > take to bring it one step further? Unless it's already been thought/written > by some Peter out there ;-) I think everyone at Avalon agrees that there is a need, but the name should be changed to "Bundle" or "Assembly" or something like that. I personally prefer Bundle. > Serioulsy, I'd like to make that a reality because I think it's vital to > GuiApp. I don't think it can wait too long either. Maybe it's something we > should experiment on our own and then adapt to Avalon specs when they come > out. Stefano seems to have great interest in this as well for Cocoon. Maybe > he already has something working? :) Well we could do that. Stefano has a general concept, but I am not sure they have it working fully, yet. > Do you have any action plan? Anyway I need to think about this myself and > see what would be my requirements. One resource that would be good to look at is here: http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/Bundles/index.html or in PDF form here: http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/SystemOverview.pdf I would like to extract what makes sense and ignore what doesn't. I like the simplicity of how Bundles are supposed to work. Apple provides an API to access the bits in the bundle, which would be a good thing. That way as the contents/layout of bundles change, we can still get at them. Also we need to look at things like Eclipse plugins or IDEA plugins for integrating UI elements together as one cohesive whole--without requiring the plugin writer to have a bunch of management code. I.e. as declarative as possible. -- "You know the world is going crazy when the best rapper is a white guy, the best golfer is a black guy, The Swiss hold the America's Cup, France is accusing the US of arrogance, and Germany doesn't want to go to war. And the 3 most powerful men in America are named 'Bush', 'Dick', and 'Colon' (sic)". -----Chris Rock