Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 53147 invoked from network); 6 Apr 2004 22:21:27 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 6 Apr 2004 22:21:27 -0000 Received: (qmail 97736 invoked by uid 500); 6 Apr 2004 22:21:09 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 97696 invoked by uid 500); 6 Apr 2004 22:21:08 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 97681 invoked from network); 6 Apr 2004 22:21:08 -0000 Received: from unknown (HELO pulse.betaversion.org) (62.140.213.123) by daedalus.apache.org with SMTP; 6 Apr 2004 22:21:08 -0000 Received: (qmail 24363 invoked from network); 6 Apr 2004 22:21:13 -0000 Received: from unknown (HELO apache.org) (stefano@127.0.0.1) by pulse.betaversion.org with SMTP; 6 Apr 2004 22:21:13 -0000 Message-ID: <40732D5C.9040605@apache.org> Date: Tue, 06 Apr 2004 18:21:16 -0400 From: Stefano Mazzocchi Organization: Apache Software Foundation User-Agent: Mozilla Thunderbird 0.5 (Macintosh/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [Kernel22] How to develop a component? References: <4072B5A6.5060803@apache.org> <40730DEA.8020201@apache.org> In-Reply-To: <40730DEA.8020201@apache.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060202090706060209070705" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N This is a cryptographically signed message in MIME format. --------------ms060202090706060209070705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sylvain Wallez wrote: > Nicola Ken Barozzi wrote: > >> Carsten Ziegeler wrote: >> ... >> >>>> I strongly suggest that we start with org.apache.cocoon.* to avoid >>>> these problems down the road (including, yes, gump problems) >>> >>> >>> >>> Yes, I understand of course all these problems, but I'm really afraid >>> of changing all the components now from Avalon interfaces to Cocoon >>> interfaces which are more or less the same but just use a different >>> package. In that case these components run in Cocoon but not in any >>> other container anymore that provides Avalon compatibility. And >>> that's imho bad. Not every project uses Cocoon, so it's absolutely >>> preferable to have components that I can use in several projects. >>> >>> Ok, I think if we decide to use our own versions of the interfaces it >>> will still be possible to do some hacky things and still provide >>> compatilibity with the Avalon versions. >>> >>> So what do others think? >> >> >> >> Cocoon components will never work putside of Cocoon. >> Non-cocoon components should not use the Cocoon interfaces. >> >> I don't see the problem, as long as we don't mix all like we did with >> Avalon. > > > > IMO, the answer isn't so simple. A lot of people chose to use Avalon > interfaces to implement component-based systems, especially for > components related to business logic. These components can run inside > Cocoon, but not only. And this choice was made possible because the > COP-related interfaces are defined by outside of Cocoon, i.e. they > aren't tied to the web tier in a more global architecture. > > Now what if COP-related interfaces are defined within Cocoon? People are > left alone to write their business-related components. This is a giant > step back. > > > Also, I think the block kernel and ECM serve different complementary > purposes. The kernel is useful to implement coarse-grained entities > (blocks) that can be hotdeployed and hotswapped. ECM is useful to > implement fine-grained entities (components) that need to be configured, > eventually pooled, etc. But ECM-managed components aren't individually > hotswappable (they don't need to). > > So we can consider that there actually exists two levels of > containement. Blocks are managed by the kernel, and components are > managed by an ECM-type container, which, being part of a block is itself > managed by the kernel. > > This approach has the benefit of being an evolutionary path of what we > have today and still allows people to benefit from COP interfaces to > implement their own components, be them integrated into Cocoon or not. > > WDYT? On paper, yes, but in real life it's not so simple. Avalon/ECM cannot define hotswappable components. This means that if your block has ECM components they cannot be exposed to other blocks, otherwise they would create "hard wires" between the two components that will not allow the blocks to be hotswappable. So, like we already said before, it is *totally* possible to have a block load avalon components thru an avalon sandbox (sort of a avalon->cocoon adapter). This allows you to reuse your avalon stuff "AS IS". But this also means that your block cannot expose those components outside of that block. This *is* already planned and allows you to keep your existing stuff, but there is no way you can have the avalon interfaces cooperate with the existing cocoon kernel functionality because of the intrinsic nature of an hotswappale mechanism. -- Stefano. --------------ms060202090706060209070705 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII7TCC AtEwggI6oAMCAQICAwsi0jANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDMxMTEzMDE0OTU4WhcNMDQxMTEyMDE0OTU4 WjBEMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSEwHwYJKoZIhvcNAQkBFhJz dGVmYW5vQGFwYWNoZS5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC2CMYD GJqn0K4hpdDlpgbFlGxlFh2mp5EZyY3cu9nmp2wcl+vGn1Wcc103mshOV7BYHnBnR9CBNI5E /l/S/hKj0jgd0jH9/aKqmExZkLWsC7kCLANKPPDFl/sPGTHnpkQhvUbDjlUZa/h77oVFowBg IZjdJWadNzssPJ5wnGdfuYr+4ZI2xEWjH0tZY6V4TpILRg/jp3F6x/avqjNGBA1KOp6OzXdh 0RfvXEMEXDu6AZTD+flQxOjKp+IHtSO7suwkKg9ffx7Gh2LGKE24sBNE8SEPYHRtchutpQh9 YFW30HVgLgq9rM8lUx6JA7D4akj/A2Wc3tr+BBqpUkvgm3b/AgMBAAGjLzAtMB0GA1UdEQQW MBSBEnN0ZWZhbm9AYXBhY2hlLm9yZzAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AGfFFcM8lPwGLk1c5dHqMMbvR+i9MAWCNVoA2mHloOHW3Lv0peihvloRht8+lIK4+LpoygMQ beh+piuu/tcP+Z8W0Gee1pPiy0WfDbg5ZHfNvUswUSkoBP/nxL1yoHifBffxIm5IZNIxIj/l fStsMv5X8Tb/+KZY4T+iU/QU5t6UMIIC0TCCAjqgAwIBAgIDCyLSMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wMzEx MTMwMTQ5NThaFw0wNDExMTIwMTQ5NThaMEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBN ZW1iZXIxITAfBgkqhkiG9w0BCQEWEnN0ZWZhbm9AYXBhY2hlLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBALYIxgMYmqfQriGl0OWmBsWUbGUWHaankRnJjdy72eanbByX 68afVZxzXTeayE5XsFgecGdH0IE0jkT+X9L+EqPSOB3SMf39oqqYTFmQtawLuQIsA0o88MWX +w8ZMeemRCG9RsOOVRlr+HvuhUWjAGAhmN0lZp03Oyw8nnCcZ1+5iv7hkjbERaMfS1ljpXhO kgtGD+OncXrH9q+qM0YEDUo6no7Nd2HRF+9cQwRcO7oBlMP5+VDE6Mqn4ge1I7uy7CQqD19/ HsaHYsYoTbiwE0TxIQ9gdG1yG62lCH1gVbfQdWAuCr2szyVTHokDsPhqSP8DZZze2v4EGqlS S+Cbdv8CAwEAAaMvMC0wHQYDVR0RBBYwFIESc3RlZmFub0BhcGFjaGUub3JnMAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZ8UVwzyU/AYuTVzl0eowxu9H6L0wBYI1WgDaYeWg 4dbcu/Sl6KG+WhGG3z6Ugrj4umjKAxBt6H6mK67+1w/5nxbQZ57Wk+LLRZ8NuDlkd829SzBR KSgE/+fEvXKgeJ8F9/Eibkhk0jEiP+V9K2wy/lfxNv/4pljhP6JT9BTm3pQwggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECAwsi0jAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA0MDYyMjIxMTZaMCMGCSqGSIb3DQEJ BDEWBBRJKQ1L1OTAM2zBqs6Xc2IclFkC3TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg SXNzdWluZyBDQQIDCyLSMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwsi0jANBgkqhkiG9w0BAQEFAASCAQA/TEaG pVbgPSkuCpaJ9FSy2j4eUil8aI7P+t18ePJwXLCfogVYMOhiXnR7/WE720foLUV4UvwoVwlE RRBHJja2ELy3mO3h/+r5mrkkq3F8m1hkITYzCJHXjEaStc0jvAHq/jKa7rthtzKL825V5C/f aZEmtWsN7v7TNGMYwqdQZHrnVGWdiKPS13Z68ZqIVjD6Wwfm6EG6ww04zhtxylFuUmJOdImN mqOrNG5kjkbl9bb0d1AenHimMNfScyUJASbcS7niD2hHrJa3UZ5G3trxsXNzq5VIvaugvTyG F0fPUUVH20DROPNgc2FyWFl0kfZtL0AbAmdPYmIIo3JNym02AAAAAAAA --------------ms060202090706060209070705--