Date: Mon, 08 Jul 2002 18:37:55 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Doug Barton <DougB@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: Package system flaws? Message-ID: <3D2A3E73.8A6BFA16@mindspring.com> References: <20020708150549.D84324-100000@zoot.corp.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Barton wrote: > > If it's good to put metadata in a file seperate from the data it > > describes, then the judgement of "goodness" is universal. > > This I disagree with. Insert obligatory quote about "foolish consistency." > > > We do this because it makes the data and metadata non-severable, > > See a later post by me on this thread where I clearly state severability > as a specific, and desirable goal for this application. Insert obligatory quote about "1 0wn y00r b0x". 8-). I don't understand your severability argument. Or maybe I just disagree with it at such a fundamental philosophical level that it just seems like I don't understand it. > In this case, I think that the costs of synchronization are very small, > and easily addressable by existing tools. Whereas, the benefits of > severability are very great, and easily offset the costs of both not > keeping them together, and the cost of actually performing and maintaining > the severance. I give: What are the benefits of having to downlaod multiple files, rather than a single file, via HTTP protocol? > > It also gets rid of the implied graph edge for locking of data and > > metadata, which can lead to an undetectable deadly embrace deadlock . > > I agree that this is a factor we need to keep an eye on. However, I think > that the problem space is sufficiently small that we'll easily pass the > 90/10 rule, and may even get as high as 95/5 with little additional > effort. The current code partially solves the problem. If 90/10 is OK, then the problem is solved, and we can quit discussing it, as 90% of the direct needs of people are satisfied already, I think. > > All of these arguments apply equally well to bundling package > > metadata with package data: conceptually, that metadata is no > > different than file ownership, flags, or permissions. > > And here is where we would need to actually define which metadata we're > considering splitting out where. I think dependancy data is a slam dunk > for being split out into a seperate file, both because it's already been > identified as something we need to know before we download the whole > binary package, and because it is rather likely to change independent of > the actual binaries themselves. OK, you need to clarify what you mean by "file". Do you mean "archive content element", or do you really mean *file", as in "down load this archive *file* and download this metadata *file* seperately, and hope nothing gets lost or outdated". > I'm studiously trying to avoid focusing on implementation details because > I'd like to spend some more time discussing the problem space, but if > it'll help us understand the problems better, I could describe what I have > in mind in a little more detail.... OK. But be aware that we may have different ideas of the problem space... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D2A3E73.8A6BFA16>