submitter 382175 Branden Robinson <branden@debian.org> thanks On Mon, Aug 14, 2006 at 06:45:08PM +0000, Brian M. Carlson wrote: > On Sun, Aug 13, 2006 at 10:51:54PM -0400, Branden Robinson wrote: > > On Wed, Aug 09, 2006 at 09:56:53PM +0000, Brian M. Carlson wrote: > > > I agree. However, I am not willing to keep this bug under my name. As > > > I can be somewhat of a hothead, if this issue is important to you, I > > > suggest that you take the status of submitter. I have instructed > > > control@ to handle that, but it may not work. > > > > > > If you are unwilling to take that on, please reassign it to someone > > > else who is willing, or close the bug. > > > > I don't mind it being assigned to me if Adrian doesn't want it, either. > > That's fine. Would you take it, then? If Adrian wants it > after that, then you and he can argue it out. I haven't heard anything from Adrain since you sent this, so I'll take it for now. > I'm having troubles with the BTS which I am in the process of attempting > to sort out, but I don't expect this message to appear in the bug logs, > for example. Hopefully everything will work again for me within a few > days. Therefore, you may obviously send this message to the bug, if you > desire. Certainly. :) > > > I also was unable to write a replacement as I originally planned (which > > > would have solved the whole debacle), because the documentation is so > > > poor that I could not have possibly reproduced the relevant interfaces > > > correctly. > > > > Well, would you be willing to write a complete description[1] of the RPC > > implementation? That way it can be clean-roomed. > > I would be thrilled to do that. If there is anything special I need to > know (I'm at least vaguely aware of most of the standard procedures), > please do feel free to inform me. Awesome. No, I don't have any specialized knowledge about cleanrooming -- I just think I understand the basic principles. > I presume that I will need to document interfaces and the functionality > of each interface with sufficient detail to allow (as you said) "a > skilled C programmer" who is familiar with RFCs 1831 and 1832 to > reproduce code of equivalent functionality. Right. > I am aware that I should not expose any implementation details, Actually, I am not sure this is true. The classic cleanrooming scenario is when Phoenix Technologies had one team of engineers study the IBM BIOS ROM at the instruction level, and write a specification from that, and then gave that specification to another team of engineers who wrote a work-alike from scratch. It might be wise to avoid documenting implementation details for other reasons, particuarly if you see something egregiously bad in the existing code, like a memory leak or a security vulnerability. Admittedly, it might be easier to repel charges of plagiarism or copyright infringement if implementation details are omitted, especially for simple code which might end up looking nearly identical to the work being reimplmented due to common C idioms. But anything terribly clever implementation-wise could probably reasonably be documented in the specification. > but to what extent is binary compatibility an issue? Is it acceptable to > document the sizes of structures (taking into account 32- and 64-bit > machine differences)? These are good questions. Shooting for binary compatibility is probably desirable, but this is mostly a gut feeling on my part given the overall mission of replacement. I'd be inclined to defer to the programmers actually performing the reimplementation. It might be worthwhile to explicitly set off information like this, as well as any described implementation code, in some prominent way. Note also that'd I'd argue that anything which would break binary compatibility is an interface, whether it's characterized that way by the source code or not. If I can get a glimpse inside of your black box due to structure alignment, for example, then that part of your box is not black. :) > I also should not discuss implementation details or any other > "privileged" information with any potential reimplementor. I would not disclose things like extensive comment literals, names of symbols that are hidden to the library's users, or unreachable code. If there is a long comment that is important to understanding the code, it would be necessary to rewrite it, I would think. > If someone can provide a good online reference, or even a book that the > University of Houston or Houston Public Library is likely to have, then > I can educate myself before I start working. The only thing I know of is: Warden, R. (1992). Software Reuse amd Reverse Engineering in Practice. London, England: Chapman & Hall. ...which I found via Wikipedia. Amazon.com wants $187 for it, new. Yeesh. > > I've had some dealings with some Sun engineers and engineering managers on > > the operating systems side of things, and can pursue this further if the > > time is right for an overture. > > I will leave this decision up to you and relevant other Debian > developers. Okay. If the comments don't come to me I may have to go seek them out. :) > > I don't want to presume the success of the latter, so I think it would be a > > good idea to identify potential team members for a re-implementation under > > the LGPL or a GPL-compatible non-copyleft like the MIT/X11 license or > > 2-clause BSD. > > Yes, I think it is good to have a Plan B. And plus, doesn't the IETF > generally require two independent implementations? ;-) It's my understanding that the U.S. Department of Defense does... :) -- G. Branden Robinson | Half of being smart is knowing what Debian GNU/Linux | you're dumb at. branden@debian.org | -- David Gerrold http://people.debian.org/~branden/ |
Attachment:
signature.asc
Description: Digital signature