Closed Bug 37275 Opened 25 years ago Closed 25 years ago

fix the progids

Categories

(Core :: XPCOM, defect, P3)

Product:
Core
Component:
XPCOM
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jband_mozilla, Assigned: rayw)

References

Details

(Whiteboard: [nsbeta3+])

We should convert the existing progids to have the form: "unique_module_name.unique_name_in_module.number" I do *not* think that they ought all start with "mozilla". They certaly should not have URL syntax. We need to do this sooner rather than later. The progid is a part of the contract of the component forever. We need to get rid of the funky overloading of the progid to do dispatching: "component://some_component_that_does_dispatching?additional_info" This is not appropriate. We should use the category manager for that. Some dispatch function is free is register as many progids as it wants in order to accomplish its funky thing. Besides the stuff like this that rdf does, look at sspitzer's comment in http://bugzilla.mozilla.org/show_bug.cgi?id=4263 He has made the commandline arg dispatcher require that services which want to be started from the command line must declare a screwy progid. Do we really want to do this?
it's not that screwy. a progid of that for is is currently required, because basically doing this. progID = "component://netscape/commandlinehandler/general-startup"; progID += <your command line argument>; /* example, "-jsconsole" nsCOMPtr <nsICmdLineHandler> handler = do_GetService(progID,&rv); we do tricks like that all over the place. I can fix my code to play nice with "unique_module_name.unique_name_in_module.number", and make it so all the progIDs for all commandline handlers have the same format. "commandlinehandler.jsconsole.1" or what ever. same trick. different way of building the progID.
I'm wondering if we should try to 1) prefix some of them with "mozilla" or something - since something like the command line service is specific to mozilla, but would not be used by another consumer of XPCOM 2) however we do the initial prefix, it would be excellant if we could sync this up with the components and sub-componets as defined by chrome, such as global, communicator, communicator/prefs and so forth. (because chrome is basically the only other place that we distinguish between parts of the project in a text string)
I do have to agree with jband though - I think progids should be atomic strings that are not "dynamic" - I'm guilty of doing this myself simply because we didn't have categories up until recently. But I've posted to .xpcom before and said that any time you have to do a dynamic progid, you should stop, and think categories instead.
I think we should dump the url syntax fast and clean. The "two dot" scheme is what MS uses. I think the trailing number has potential for *great* future versioning benefit. However, it has been suggested that the limitation of only two identifiers is unnecessary. I agree. Likelyhood of uniqueness is important. Simple dot separated identifiers with a trailing number is good. We should allow (and encourage?): org.mozilla.xpconnect.runtime.1 ..and... com.evilmen.really_evil_men.evil_module.bfg.1
In the meantime several components use a mozilla.<name>.1 scheme already. One with moz: mozilla.consoleservice.1 moz.jsloader.1 mozilla.scripterror.1 mozilla.jssample.1 mozilla.categorymanager.1 I like the Javaesque scheme. I have been using digitalcreations.* for now, but I like com.digicool.* or org.zope.* better.
Do you really need the TLD at the front of the progID? It doesn't convey much information and is not likely to be useful in preventing collisions. One thing I have always disliked about Java's package syntax is that "." is too overloaded. I would have preferred <dotted-package-name>::<class-name> [ ::<static-member> ] But the word was that it reminded Gosling too strongly of C++ :-). I think that it would be well worthwhile syntactically separating the "installation granularity" component name from other information. The version should be distinct too. So how about, say, evilmen.really_evil_men.evil_module:bfg.powerpack,1 i.e. <dotted-package-name>:<dotted-component-name>,<version>
We need some rules. Mostly, the particular syntax does not matter - it just needs to be consistent. - I'd like to have the identifier subparts be legal identifiers in most languages. - I doubt that anyone will want or need to parse the different subparts *except* to distinguish the trailing number. I see nothing wrong with using all dots. I think that having different puncuation to mean different things is not helpful and just sets us up for more instances of non-compliance and more likelyhood of parsers confused by their real-world input. I just don't see benefit in what roc+moz@cs.cmu.edu suggested. - The Javaish "com.company.division.module.class.number" scheme is clear and based on a commonly understood convention. One of the rules of particular importance is that if one adds a progid into such a namesspace that one had better have approval of the 'owner' of the namespace. there is a lot of risk that novices will add "mozilla.mymodule.1" (cuz' we're *all* mozilla contributors). A longer more explicit name will help, but stressing the point that people need to make up their own names and not inject themselves into organizations is important. We should *soon* implement code in the component manager's ProgIDToCLSID routine to allow translation with no trailing number. i.e. Given that foo.bar.1 and foo.bar.2 and foo.bar.8 are registered then is omeone asks for foo.bar they should get the CLSID for foo.bar.8 . I think most clients will not need to specify the number if we do things right.
If the "package name" is clearly identified within the progID, then you can trivially map the progID to a package. I thought this might be useful if progIDs need to interact with an installer/package manager, or with other package-aware subsystems (e.g. chrome). Maybe there won't be any such interaction, but why bet against it? If the version number is separated out within the progID, by say a comma, then you can later introduce dotted version numbers if you decide they're useful. > Given that foo.bar.1 and foo.bar.2 and foo.bar.8 are registered then is omeone > asks for foo.bar they hould get the CLSID for foo.bar.8 Maybe, but there's a big iceberg lurking here: release to release, bug for bug compatibility is too hard and does not work. If component A has been tested and debugged with version 5 of component B, and works well with it, then you often don't want it to start using B v6 when that suddenly appears. There are a number of interesting documents at Microsoft about this. In my opinion, when someone asks for a component from a progID, they should provide their own progID as well. That would allow the component manager to use a flexible policy, from "always use latest version" to "use latest version known to work according to the latest published compatibility matrix".
Since clients are asking for progids of particular versions, I think that major.minor version numbers are too messy and error prone. I don't think we should suggest or allow for anything other than integer version numbers. KISS We should decide the issue of "closest matching". There is something to be said for the form "foo.bar.v1" so that all subparts are valid identifiers in many languages. But, I still think that language mappings (e.g. xpconnect) should not try to let the user represent the ProgID as anything other than a quoted string. So, "v1" as opposed to "1" is not really a plus (just thought I'd bring it up - though I'd vote against it). I'm really voting for minimal divergence from the MS model. I like the removal of the "two dot" restriction and a convention of reverse domain name, etc. But otherwise I see little to gain from divergence.
I'd just like to add my agreement with the objection to toplevel domains in progids (i.e. org., com., etc) - these provide no value other than to distinguish com.foo and org.foo, a collision I highly doubt will happen often. .. not to mention that "com" could be confused with XPCOM and "net" could be confused with necko (network library) to the fresh developer. I also like the idea of delimiting the object name from the version with different character, such as ',' - mostly because of what jband just said.. mainly I'm worried about someone stupidly naming their component foo.bar when there is already a foo.bar.1 - then when someone asks for "foo.bar" do we give them foo.bar.1 or foo.bar? foo.bar is an exact match, but foo.bar.1 has a later version number if you think about it that way What happens if someone makes a foo.bar.goo or foo.bar.4.goo? what happens then when someone asks for foo.bar? if we said that it's comma delimited, it seems like we could do some better tests to at least see if the comma is there, so the above objects would be foo.bar,1 (foo.bar version 1) foo.bar (foo.bar no comma => no version) foo.bar.goo (foo.bar.goo no comman => no version) foo.bar.4.goo (foo.bar.4.goo no comma => no version) foo.bar.5.goo,2 (foo.bar.5.goo version 2)
Depends on: 36666
While I'm all for improving on COM, the reason for doing things differently in this case isn't at all clear to me after reading all this. Specifically, what needs to MS-style progids not address?
Ray, this is a good thing to fix. I am with jband's just stick with COM's progid semantics. It is easy.
Assignee: dp → rayw
then we should not map a.b.c to a.b.c.1, it should be a straight strcmp
Changing Platform and OS to "All", since this is obviously an XP issue. Also see bug 26013, which is either a dup or a dependency.
OS: Windows NT → All
Hardware: PC → All
I think we should set the precedent of some standard prefix to the module name. It doesn't have to be long, like mozilla-. It could be short, like MZ- or NS-. It looks a bit uglier, but is much cleaner for the long term to identify who introduced a progid and prevent collisions. Otherwise, we have to know all of the simple names that might be in use by small sets of users who will be really up in arms if we collide, and may even try to preemptively define, start using, and distribute simple names.
Um, can we please *not* resort to cryptic initialisms? When you talk about remembering words versus remembering abbreviated forms, remembering words is almost always easier for most humans. I don't see how words vs. initials is going to do anything to solve the collision problem. That problem probably needs to be solved by creating an official repository of progIDs in which new progIDs can be registered.
A central repository does not handle the problem well. There is a social problem - people will ignore a central repository or be ignorant of its existence. The whole point of a reverse domain name convention is to avoid the need for a central repository.
The reverse domain name system does not avoid the need for a central repository, it just leverages the use of an existing repository. There are a few quirky problems with that--like what happens when a domain changes ownership, what if someone doesn't want to affiliate their work with a domain name--but nothing too major. And as alecf notes, the need to differentiate between com, net, org, and the like is debatable. So if we whack that part off, then we're back to the MS style. I guess, in essence, you're contending that having the org, net, com, etc. there at the front of the identifier makes it more likely that people will "get the idea" and go to some effort to make their progIDs unique. I'm not sure if I agree or not. The reverse domain name convention certainly has a rather spotty following where it has been proclaimed for Java package naming.
"And as alecf notes, the need to differentiate between com, net, org, and the like is debatable. So if we whack that part off, then we're back to the MS style." Not quite -- there would be at least three dots and four components: mozilla.library.class.version (or sun.library.class.version, e.g.). Or more, if you were at self.sunlabs.com and wanted to distinguish yourself from some other part of that empire via sunlabs.self.library.class.version. MS has only library.class.version, IIRC. I like conventions that cause people to "get the idea", too -- memes can be good and powerful. Isn't the objection of some Java developers to the reverse FQDN based on long-winded-ness in the package statement of every single Java class? See http://www.flex-compiler.lcs.mit.edu/Harpoon/HOWTO/code-conventions.html, which anyway puts the Flex team's rejection of the Sun standard off to their being "too lazy". Braden, can you comment on what other reasons people give for not following the official Java convention? Also, if the objections arise from peculiarities of the Java language, perhaps we can make distinctions based on where and how often progids will be used. I'd prefer shorter prog-ids too, all things equal. But since collisions are a worry, and given that we don't believe yet another central registering authority is the right solution, why not leverage the almost fully-qualified domain name? Separate comment: I agree with alecf that unless we use , or another character than . to separate version from what comes before, *and* we allow an arbitrary number of non-version parts > 2, then we are asking for trouble by implicitly mapping some.long.prog.id to some.long.prog.id.8. /be /be
First, forget that I, as a compromise, suggested an abbreviation (unless someone again suggests having no ownership prefix at all). Second, I searched for COM progids on the internet and in a Windows registry. They did not seem to follow a single standard, and often clear ownership was not there. Third, The java scheme does solve contentious issues such as, "who gets to use <some overloaded term or trademark>". I am aware of a few cases where it is not followed in current practice. Where it is not followed, the deviant example still usually identifies the ownership, avoids collision, and implicitly assumes responsibility for collisions caused by not following the standard. Fourth, The (major) version number is good in some cases, but version can often be a function of the module, rather than of the component, which might make alternative forms preferred in other cases. I doubt that automatic matching between versionless and versioned names is a good idea, when we can let this sort of thing be solved in a mostly module-specific way at registration time by having extra progids, thus keeping better flexibility by avoiding hard-coding a magic interpretation of dot-delimited parts at all. On the other hand, it would seem important to understand the versioning that is likely to occur in the future on existing modules, as it is likely to affect the immediate names we choose. Fifth, does anyone have an opinion on how to deal with conflict resolution when multiple dlls supply an implementation of the same progid (more likely to occur over time than initially). Who wins? Is it whoever registers last, or does the second registration attempt fail? Either seems somewhat problematic for the user, even if they are easy to program. Do we need something more? For example, should related registrations in the same dll be transactional -- all or nothing?
ProgIDs should uniquely identify an implementation so there is never an issue of multiple DLLs providing the same ProgID.
rayw: There exist conventions for progIDs, and they are described in the standard COM references (i.e., Box, Rogerson). It is true that they are not always followed. Regardless of what convention is decided on here, expect that trend to extend to XPCOM progIDs. It's my understanding that the versionless -> versioned mapping described here is reflected in the COM conventions. For that reason, I think it is safe and sensible to incorporate it into XPCOM as well. I don't see why the version number should ever be a function of the module. If I'm requesting an interface, there's no reason I need to care about the module's version as long as the components have been versioned correctly. And I agree with those who've suggested we stick to a single integer version number. That eliminates ambiguity about when and how the number should be changed: if you changed the component, you increment the version before you release it. Simple. roc: Should, yes. Must, no. CIDs provide the universal uniqueness requirement. In the progID namespace, it is up to the individual component implementors to make sure collisions don't happen. In the event of a collision, which CID gets returned for the duplicated progID is undefined: it's up to the implementation (XPCOM). So it's in component implementors' interest to take it upon themselves to ensure they aren't stepping on anyone's toes. In light of this, I would suggest that the implementation randomize which CID is returned in the situation where multiple components on the system have the same progID. That way we can't have a situation where one component implementor uses XPCOM's behavior to step on another component implementor's toes.
I'd like to add that the only *really* good reason I can see to even *have* progIDs is to be able to request the "latest version available" of a component. Otherwise, I might as well just request it by its CID.
roc: No, in our system *CLSID*s are supposed to uniquely identify an implemention, not so for ProgIDs. It is reasonable for new-and-improved implementations to register themselves using the ProgID previous registered for some other implementation. Doing so implies a promise of full compatability from the client point of view. We *expect* that this will occur. To rayw's question five: I would say that the last one to register wins. Unless you go back to verify the existence of previous registrants, the newest one is the one most likely to still exist next time the app runs! There is also the assumption that the module is being intentionally added into the system. Unfortunately we currently make no promises about registration order when a full re-do of autoregistration happens. This is a problem. FWIW, the xpti system I recently implemented (for .xpt files) has clear rules for registration ordering that take into account previous registrations first and then file type, size, and name to make for a predicatable ordering of registration. It places more trust in older (presumably working) files than new ones. However, that system is different because it works with files of interface type data that is not *supposed* to change. So changed information about a given interface is suspect. This is not the case here where we are mapping key strings to prefered component factories.
here is my reason for opposing mozilla.rdf.parser.1 instead of rdf.parser.1 Progid is used by many applications. There could be many vendors implementing the progid using their own CIDs. An application if it cares that it wants the implementation from mozilla or SUN should use the CID. As long as the SUNs implementation and mozilla's implementation are compatible, they say "I do rdf.parser" progid. That is whole idea behind having the progid. Uniqueness is an issue. A secondary one to the primary issue of sharing. If component vendors start marking progids with their trademark, then sharing will be lost. Since MS lives with this, I vote for MS style.
dp: That kind of transparency is clearly needed for interfaces. I do not see that it is needed for components. The fact that I am even requesting a component says that I want *some particular party's" implementation. The level of genericness you're suggesting would appear to make such a request impossible to fulfill reliably. And is the fallout from your claim that it would just be okay to have two rdf.parser.1's on the system, or would we have different vendors for the same component having to make sure their version number is coordinated with all the other vendors for that component? You say "MS lives with this". Well, looking at my Windows registry, I have a *whole lot* of progIDs that begin with something like either "Microsoft" or "MS". Apparently Microsoft has found it necessary to put their vendor name in the progID even in the absense of a dot separator for it. So do we want "mozillaRdf.parser.1", or "mozilla.rdf.parser.1"? I prefer the latter. In the event that someone *is* interested in the component name independent of the vendor name, the latter form makes that information easy to get.
branden: "*some particular party's implementation" Isnt that defined well by the CID. If so, then why a progid ?
dp: The CID corresponds to a single implemetation. This will be a specific version. The progID simply provides a means for requesting the latest version. If multiple vendors are thrown into the mix, then you also need to provide a means of specifying *whose* latest version. I really think we don't want to go there. brendan: Right--not quite back to the MS convention; I misspoke. I do favor starting with the vendor name. And no, I don't know of any reasons for not following the Sun convention other than laziness or ignorance. Whether or not we stick org/com/net/edu/gub/etc. on the front is not something I have strong feelings about either way. I personally don't think it's necessary, but if folks here think it would make the convention more likely to be followed, then we might as well do it. Exactly what trouble are we asking for by mapping a request for "some.long.prog.id" to "some.long.prog.id.8"? Doesn't MS do it this way? If we don't have a way for clients to request the "latest version" of a component, why have progIDs at all? Why not just use CIDs and dispense with this whole "potential collision" mess?
Whatever name convention we end up with for ProgIDs - and even if the version number magic does not happen - they also serve the purpose of allowing a reasonable way to impersonate and superceed components without the drastic step of reusing the CLSID. They provide a useful level of indirection and a human readable form. I disagree with a "we don't need them if they don't do X" argument. It would be confusing if we had to call each US chief executive "George Washington". One level of indirection is good here. Even without number magic a new implementation might register as the component that does "foo.bar.2" AND "foo.bar.1". If we stick with two dots, then lets fix any place with a leading "mozilla" and encourage people to lead with their - presuably unique - module name.
*** Bug 26013 has been marked as a duplicate of this bug. ***
Braden, regarding what trouble brews if we allow a.b.c, a.b.c.1, a.b.c.d, and a.b.c.d.e.f.3: alecf has sketched some confusing hypothetical cases in this bug already, but maybe they're too stupid to live in the real world. Formally, the extension to MS-COM that allows for an arbitrary number of dotted name parts makes for ambiguities in deciding what a progid names (exact vs. latest version) without also looking in the registry to see what's installed and registered; i.e., it makes purely syntactic analysis (no semantic feedback) useless. Big whoop, I suppose. Dot for version separator is not how I would have done things, but I admit MS COM's progid precedent weighs heavily upon us. Everyone: I'm posting a summary of the comments in this bug, preceded by my shorter summary of open issues and my recommendations and rationales, to mozilla.xpcom. Can we take this to the newsgroup? I really want message threading and a better composition UI than this damn six-line textarea, don't you guys too? /be
I should add, hastily, that my formal problem with a.b.c being syntatically ambiguous supposes that c could be a version name or a class name (a.b.c would mean "the latest version of class a.b.c"). But if we restrict version names to be natural numbers, *and* if we require all other name parts to conform to the usual lexical rules for identifiers in modern C-like programming languages (or something like that), then there is no syntactic ambiguity. Your syntax parser just has to classify natural number literals differently from identifiers. Duh! So I'm not really bugged by overloaded-dot, to bring this back to a very early roc+moz@cs.cmu.edu comment. We aren't starting from a clean slate. We could do worse than to extend MS-COM progids in XP-COM in a way that, as Braden showed by his perusal of his Windows registry, just codifies a first-part naming convention that MS itself uses. /be
brendan: I think the potential syntax constraints you've described are very sensible. But I think that if we establish and document a convention for versioned and versionless progIDs, it's fair to say "you takes you chances" to people who don't follow the convention. That said, I don't favor an arbitrary number of dotted parts. I think we should decide on what resolution we think is necessary and codify it. To summarize my position... MS COM uses 2 parts plus an optional version number. However, Microsoft's (and some other vendors') practice of prepending the first part with characters signifying the vendor name suggests utility in a distinct 3rd part for the vendor name.
*** Bug 35547 has been marked as a duplicate of this bug. ***
Blocks: 35548
I have posted a list to the newsgroups of the progids from the registry that would have to change. It is not clear to me that the proposed 4-part name is adequate. I will wait for a response.
Status: NEW → ASSIGNED
Target Milestone: --- → M18
Per beta2 PDT mtg, this will be needed for nsbeta3. Adding that keyword.
Keywords: nsbeta3
Making nsbeta3+ status.
Whiteboard: [nsbeta3+]
wasn't this the carpool that went in last night?
Yes. It is done (except for the related filters bug which is being fixed now).
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.