Scripsit Anthony DeRobertis <[EMAIL PROTECTED]> > Henning Makholm wrote: >> Scripsit Anthony DeRobertis <[EMAIL PROTECTED]>
>>>That would, however, cover firmware and wind up sending X to >>>contrib. So maybe: ... iff it is stored on the local machine's file >>>system. >> That would be my *intuitive* understanding of how the mail/contrib >> difference works. > So would a web-based firmware loader, that never saved the firmware to > disk allow the drivers to be in main? Hmm. Maybe. If it was properly documented in the package description for the driver that its proper function relies on an external website that the user presumably has no control over, then perhaps. But I don't think I would be really comfortable with it. The line is difficult to draw in the area of relying on external services. At one end of the spectrum is cases where what a typical user really wants to use is the external service; he knows that the service is external and views the client as a mere conduit to access something that he knows he does not control. I _think_ everybody agrees intuitively that such clients can be in main. The canonical example would be a client for proprietary IM systems, but the situation is somewhat similar with, say. IRC clients. Even though main does contain IRC server software, the vast majority of users want to connect to existing external IRC networks, so having the source does not really help them control the service that they use. Yet nobody would suggest that the client does not belong in main for this reason (except perhaps as part as a reductio-ad-absurdum argument about the true meaning of the SC). Things begin to get murky when the client provides a local service that is useful in its own right, and only incidentally needs to contact external network sites to provide it. One could imagine an anti-spam tool that submitted checksums of message fragments to a central server for correllation with other user's data. (Never mind that such an anti-spam measure would probably not be effective, at least not if it became popular). Or one could imagine a heuristic keyword extractor for plain text files which, behind the scenes, queried Google to find out how common cetain phrases. In these cases the user is not primarily interested in interacting with an external service but is probably still aware that the quality of the results he gets owe something to the use of external resources. At the extreeme other end is situations where the net service the user actually wants ("I want to scan this photograph with my WinScanner") has no *extrinsic* reason to require a non-local resource. Web-based firmware loaders belong here. I have definite qualms about including something of the latter category in main, but I am not sure that I can support this judgement with deductions from a short clear-cut definition of what each word in the SC and Policy means. However, I don't think that such a deductive development is a necessary requirement for which policy the project should adopt. Bright-line tests are overrated anyway. -- Henning Makholm "Jeg køber intet af Sulla, og selv om uordenen griber planmæssigt om sig, så er vi endnu ikke nået dertil hvor ordentlige mennesker kan tillade sig at stjæle slaver fra hinanden. Så er det ligegyldigt, hvor stærke, politiske modstandere vi er."