Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 46902 invoked from network); 5 Dec 2003 20:25:30 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 5 Dec 2003 20:25:30 -0000 Received: (qmail 86733 invoked by uid 500); 5 Dec 2003 20:25:18 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 86363 invoked by uid 500); 5 Dec 2003 20:25:15 -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 86349 invoked from network); 5 Dec 2003 20:25:14 -0000 Received: from unknown (HELO pulse.betaversion.org) (217.158.110.65) by daedalus.apache.org with SMTP; 5 Dec 2003 20:25:14 -0000 Received: (qmail 23475 invoked from network); 5 Dec 2003 20:25:18 -0000 Received: from unknown (HELO ?192.168.1.4?) (stefano@131.161.244.42) by pulse.betaversion.org with SMTP; 5 Dec 2003 20:25:18 -0000 Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: References: <6AAEAD98-2371-11D8-9AA1-000393D2CB02@apache.org> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-30-7006606; protocol="application/pkcs7-signature" Message-Id: <571D3490-2761-11D8-AB98-000393D2CB02@apache.org> From: Stefano Mazzocchi Subject: Re: [RT] Converging the repository concept in cocoon Date: Fri, 5 Dec 2003 12:26:43 -0800 To: dev@cocoon.apache.org X-Mailer: Apple Mail (2.606) 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 --Apple-Mail-30-7006606 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 5 Dec 2003, at 02:17, Andreas Hartmann wrote: > Stefano Mazzocchi wrote: > >> I looked into the repository block and I find a *lot* of things >> (locking, permissions, properties) that look very much like a >> duplication of effort. The Slide project spent years optimizing and >> polishing issues like transactionality and locking, do you really >> want to implement a layer to "emulate" those things in case the given >> source is not capable of handling it itself? > > I have a basic question: When you talk about a > "repository", does this imply that operations on > ressources are transactional, or is this an optional > feature? That's up to us to define what level of transactionality we want/need/able-to-implement-shortly. For me, now, transactionality is not that important, but it would be a good thing to have (for example, making the saving of one document that contains images an atomic thing) -- Stefano. --Apple-Mail-30-7006606 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGGDCCAtEw ggI6oAMCAQICAwsi0jANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMxMTEzMDE0OTU4WhcNMDQxMTEyMDE0OTU4WjBEMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSEwHwYJKoZIhvcNAQkBFhJzdGVmYW5vQGFwYWNoZS5v cmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC2CMYDGJqn0K4hpdDlpgbFlGxlFh2m p5EZyY3cu9nmp2wcl+vGn1Wcc103mshOV7BYHnBnR9CBNI5E/l/S/hKj0jgd0jH9/aKqmExZkLWs C7kCLANKPPDFl/sPGTHnpkQhvUbDjlUZa/h77oVFowBgIZjdJWadNzssPJ5wnGdfuYr+4ZI2xEWj H0tZY6V4TpILRg/jp3F6x/avqjNGBA1KOp6OzXdh0RfvXEMEXDu6AZTD+flQxOjKp+IHtSO7suwk Kg9ffx7Gh2LGKE24sBNE8SEPYHRtchutpQh9YFW30HVgLgq9rM8lUx6JA7D4akj/A2Wc3tr+BBqp Ukvgm3b/AgMBAAGjLzAtMB0GA1UdEQQWMBSBEnN0ZWZhbm9AYXBhY2hlLm9yZzAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAGfFFcM8lPwGLk1c5dHqMMbvR+i9MAWCNVoA2mHloOHW3Lv0 peihvloRht8+lIK4+LpoygMQbeh+piuu/tcP+Z8W0Gee1pPiy0WfDbg5ZHfNvUswUSkoBP/nxL1y oHifBffxIm5IZNIxIj/lfStsMv5X8Tb/+KZY4T+iU/QU5t6UMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlm aWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAz MDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1 BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fx H5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wID AQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2Ny bC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkG A1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOB gQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZ foSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4 gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLItIwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDMxMjA1MjAyNjQzWjAjBgkqhkiG9w0BCQQxFgQUlgr0Qppx Wys4EQxk1FfD/ttnaQMweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECAwsi0jB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLItIwDQYJKoZIhvcNAQEBBQAEggEAF3a1TvPy RgfBhGl0YZ8HSZ4izFPVTYs9BjkCSsPN2QZslXThXmcAeciUQDL20UOpfxH7fSWvjrLaMojgEZSc d7neptddvCl2LAuzv2KCeElpCOjs7ykJW/wvklNcfQVHaB21Not6oFBxq/QzQwjGAVGawxBCEDC6 1EMO7KiWDFOGBJH0poGtu//LdFZzdV+naBuIg8TPworzDx4tSVMiU6boNeUV3Uvcp/ncexLBsXGY M2UzECt5R1fC9+eSnheftVpO22xlaJwbnGgSkOZhxabaTjZLdDMOIZbqU3lCW6tYSEPIsaNFsnUB w4W3yzqA5Ab6eM4jQiqAB9rMSl3QcwAAAAAAAA== --Apple-Mail-30-7006606--