>Gianugo wrote: >Fernando Padilla wrote: >> Sorry for the digression. But I hold a slightly different view. >> Filesystems do not have a transactional nor a distributed interface. > >And sorry for the disgression, but what about NFS/CIFS coupled with a >journaled filesystem? > >Ciao, > >-- >Gianugo Rabellino
:) I meant not to send that email :) and was surprised that I had inadvertently sent it :) oops. but now that it's open, I guess we can indulge in a little academic sparring, but not too much, alright ;) ps - this is a digression and anyone can easily ignore this ( i hate to force my ramble on people ). transactions: A journaled implementation has nothing to do with transactions. I don't know of any filesystems that allows you to say, openTransaction, do a lot of operations, then either rollback, or commit all of those operations in an atomic format. If there is one, I would love to learn about it. I'll give it to you that there are distributed filesystems that are great solutions to many system requirements - ignoring such issues as administration overhead and platform dependencies. But I guess, the transaction and ACID rules that any "filesystem" lacks is what gets to me. So I see Databases filling two roles, an ACID and transactional Data Storage role, then an optimized/efficient Data Querying role. Filesystems provide neither of these, by design. I guess the metaphor is comparing UDP to TCP. Yes, most of the time UDP will get there, but you would NEVER assume that it will get there 100% of the time. If you use the filesystem, most of the time the system will maintain a coherent view ( data will not be missing and properly synchronized), but the filesystem NEVER said it would guarantee that for you; at least not for multiple file operations, etc, etc. Anyway, this is just academic sparring :) Programming is sometimes an artform, with no blank and white, as to practice, technique and design. I for one am a little lazy, and feel that requiring a database to implement ACID transactions for me, and leveraging that for all of the system's data storage needs, is a good thing. UDP is a fine protocol, but everyone feels more comfortable using TCP. Because it provides service guarantees that UDP does not. Because no one in their right mind would try to reimplement a protocol that has similar service guarantees as TCP ontop of UDP for each project they work on. Because you worry less, your designs have to make less assumptions, and your implementation is simpler. But then again, we don't have a Database equivalent of TCP, that provides efficient service guarantees for any data storage needs. So I have been discussing the ideal, maybe unreachable today. But that is what I hope Xindice will do. So as we go and evolve Xindice, and turn it into what it will become in the future, we shouldn't do things because that is the way they've been done, we should strive for the ideal, for what we want it to be. the sometimes pedantic, Fernando Padilla
