From bug 46135: > Scott and/or Ben, could you please provide ... > documentation for each of these helper app fields: > > Description -- ? > Value -- ? > FileExtensions -- what format(s) are allowed? > Path -- ? > SaveToDisk -- ? > AlwaysAsk -- ? > HandleInternal -- ? > PrettyName -- ? > are there any general docs on working with nsIRDFDataSource? > In particular, how do I properly handle the likely case that > an old RDF database might be used when looking for new fields? Thank you!
(I asked these questions a while ago, and I'm pulling them out to a new bug because the answer will help solve both the blocked bugs marked here.)
Resetting the QA Contact to original -- I have no idea who it should be, but the RDF QA Contact might be the most likely to know where the information is supposed to be documented once it has been. Sairuh and Shrir can watch via cc.
QA Contact: sairuh → tever
Summary: please document helper app database fields → please document mimeTypes.rdf helper app database fields
See also: http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperApp Service.cpp
I'd like to take this opportunity to point out these two confusing adjacent lines in mimeTypes.rdf, which Ben G. and I discussed briefly without any real resolution: 22 <NC:handleInternal>true</NC:handleInternal> 23 <NC:handleInternal>false</NC:handleInternal> Clearly the former is what you would expect in the definition, as it is for text/html, so can line 23 be deleted? Thank you, Scott, in advance.
No longer blocks: 61025
> <NC:handleInternal>true</NC:handleInternal> > <NC:handleInternal>false</NC:handleInternal> Bug 56224
Is there any chance of this ten-minute task being done any time soon?
Michael: Would you please ask that this be made an immediate priority?
If this still is a blocker for bug 58811, please re-consider priorities. Mozilla gets badwill from the fact that the demos here < http://java.sun.com/products/javawebstart/demos.html > don't work.
1) This is not a 10-minute task. I know how the fields are used, and I estimate it would take me an hour and a half or so to document them. I happen not to have that hour and a half at the moment.... 2) It's assigned to the wrong person, imo (ccing law, who would be more likely to be able to document this)
Even ten minutes of documentation on this database would help with the block on a lot of the content-type dispatch issues. Please help now.
PLEASE PLEASE PLEASE!
ugh, taking. This has gotten ridiculous; here's hoping drivers take a comment-only patch during freeze. ;)
Assignee: mscott → bzbarsky
Status: ASSIGNED → NEW
Priority: P3 → P1
Target Milestone: --- → mozilla1.3beta
wrong component, too. Where do people think the documentation should go? I suppose I could stick it in the default mimetypes.rdf as simple XML comments; it would get clobbered in the in-profile generated versions, I presume, but... The other alternatives would be to put this documentation in nsExternalHelperAppHandler, in a document on mozilla.org, etc. Please let me know (I'd rather have on location and have other places pointing to it than having multiple copies of the same text; this makes me lean toward putting it on mozilla.org, somewhere in http://mozilla.org/catalog/libraries/uriloader/ or something).
Component: RDF → File Handling
QA Contact: tever → sairuh
Note that I plan to create an nsIRDFMIMEService which would be able to return MIMEInfo objects or persist such objects out to mimeTypes.rdf. At that point I will move the documentation to that service implementation, since there will be no incentive for anyone to munge the datasource directly.
Summary: please document mimeTypes.rdf helper app database fields → [FIXr]please document mimeTypes.rdf helper app database fields
Comment on attachment 112432 [details] [diff] [review] something like this.. >+ NC:useSystemDefault - "true" if we should handle per defauly OS setting, defauly => default >+ Each ""urn:mimetype:externalApplication:major/minor" resource can have the ""urn: => "urn:
Attachment #112432 - Flags: review+
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Marking verified per last comments.
Status: RESOLVED → VERIFIED
Boris, I hope this is a quick question: Does NC:externalApplication and/or NC:path use input filename %s substitution and/or stdin? Can you answer for at least the big three platforms please? Thank you.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
It does not, on any platform. See bug 57420. The reason that I did not put any more comments than I did in there is that that field is a serialization of a file object which is more than just a file path (at least on MacOS). In any case, please do not reopen bugs just to ask a question....
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago → 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.