On Thursday 17 April 2008 16:17:48 Michael G Schwern wrote: > chromatic wrote:
> >> We'd like folks to be able to add their own keys as they need without > >> first wondering whether it might be useful for others or worrying if we > >> might add a key of the same name, but different functionality, later. > >> Thus the separation of local from official keys. > > > > This part I think will not work. You can't pave the cow paths if you > > never see the pasture, and you can't not break the DarkPAN because the > > only way to know if the DarkPAN even exists is to see if light bends in > > its vicinity. > I don't understand, what will we break on the DarkPAN? The whole point of > separating user from official keys is so we don't break the DarkPAN. I've never thought there was an upgrade problem, but everyone else keeps saying that there's an upgrade problem and that there absolutely must be a separation between TAP keys and everything else because there's an upgrade problem and we don't want to break the DarkPAN. If we agree that that's not actually the real problem, good. > > Worse, if you make the argument that name collisions are bad, because you > > can't determine programmatically the semantics of a key from the > > surrounding TAP document (and I don't mind this argument; it's a > > designing principle of Roles in Perl 6 for example) as the reason why TAP > > keys need a separate namespace from user-defined keys, you've just moved > > the problem somewhere else. > > To wit: what if I use multiple producers/consumers which produce false > > cognate keys? > Again, I don't understand. Official Blessed TAP module: I use the keys TAPONLYFILENAME, TAPONLYLINENUMBER, TAPONLYEXPECTED, TAPONLYRECEIVED. Bob's unblessed TAP module: I use the key "time", which means the time of the test run. "Starttime" is just too long, and who wants to process an ISO-compliant datecode? Chuck's unblessed TAP module: I use the key "time", which means the duration of the test run. "Duration" is just too long. See the problem yet? chromatic: Gee, there's a collision between Bob's module and Chuck's module, which are both very very useful, especially when combined in the same program. If only TAP::ESP could disambiguate between the two. The problem is not upgrading. The problem has never been upgrading. The problem has always been name collisions. > > Solution one: don't try, at least for the general case. There's TAP keys > > and there's everything else, and if everything else doesn't play together > > nicely, them's the breaks. You get both pieces. > > > > Solution two: tag every key with an organizational prefix. This includes > > TAP keys. Any non-prefixed key is invalid. > > > > Can we enforce solution two? Not entirely; only as far as producers and > > consumers agree roughly on a version of the TAP spec. Further, we're > > pushing the namespacing problem in a different direction. Organizational > > names may conflict. However, they're less likely to have the false > > cognate problem. > > Now I really don't understand. Are you advocating key prefixes per > organization like "tap.foo" and "xerox.foo" and, dare I delve into Java > land, "com.google.foo"? If you remove the "Are you seriously suggesting we eat babies?" stink of the word "Java" there, yes I am -- if you want to solve the real problem of allowing arbitrary keys. -- c
