Jason Tackaberry wrote: > On Wed, 2005-08-24 at 18:55 +0200, Dirk Meyer wrote: >> I know. I was thinking about making root always the same type, but >> that sucks. An audio disc is different from the root of my fs. BTW, >> how to find a disc? Is a disc always a 'removable media' or are DVDs >> and AudioCD different? > > It depends on what kind of attributes you want to associate. Yes, I see > them as different, because DVDs have different attributes from audio > CDs, and so you'd register a "dvd" type and an "audiocd" type.
OK, I agree. > The vfs would provide an interface to associate a "removable" flag > with new types and deal with removable types which are roots for > other objects as necessary. Yes >> Yes, that's a bad hack. I guess the best solution is to have a >> mountpoint. > > Actually I think it's a clever hack that, while conceptually kludgey, in > practice won't cause any problems and should perform well. > >> table mountpoint >> int id unique >> type string >> rootid int >> >> So for an audio disc with the entry 'removable', type is removable and >> rootid the id. So we point to this table for mointpoint to have one >> unique table for all mountpoints. > > I actually like my idea better. This solution means a new table that we > have to keep updated. Yes, one extra table. But is it a problem to have one more table? We would provide a 'add_new_removable' function and it will work without problems. > If the problem really is the 100 million file limit in my solution, > then we could concatenate root_type and root_id as strings. While > theoretically better, I like that idea less since concatenating two > strings is much more expensive than an multiply and an add. You > can't possibly think 100 million files is a limit anyone will ever > hit. :) It's not that I think someone will hit the 100.000.000, I only think it looks ugly. >> Maybe I can't. It sounds strange, but sometimes it is much easier to >> do stuff later. Maybe a searchable attribute can't be auto invalid. > > It's not really avoidable that attributes will be invalidated if you > allow other applications to share the same vfs. So if you don't handle > invalidated attributes right away, then you'll have to accept that > queries could potentially return wrong results. I don't see a way > around that. So you can't query on invlid fields. We do a query and remove all results were it is invalid. I see a problem with 'give me all changed files'. Lets assume we have Freevo running, all 100.000 files scanned and indexed. Now you start MeBox and it askes: 'something new?'. The result would be a query on _everything_!!! Dischi -- Viewer discretion may be advised, but it's never really expected.
pgpkQjWSK01QE.pgp
Description: PGP signature
