Sarah Jelinek wrote: > Hi Ethan, > > >> >> >> The original comment notes "provide a mechanism to >> enable SSH". The mentioned consumers actually provide >> the mechanism as an *end* user facing switch --a grub >> menu entry. I don't see how this level of "mechanism" >> could be provided for by the engine. >> >> If what's meant is just the act of turning on SSH or >> whatever the remote accessibility medium is, then I don't >> quite see the value of the engine providing the mechanism >> to the consumer. Why couldn't the consumer just turn >> on ssh itself? >> ... or is what's intended here that the engine abstract >> what "remote accessibility" means? > > It seems to me the engine should provide the support for remote > accessibility. So that individual consumers don't have to implement this > and so we don't have redundant code in each consumer. Even if they > provide a grub entry that switches on remote accessibility, the > consumers should be able to enable this via an engine interface. So, > that each client doesn't have to know the details of the remote > accessibility implementation. >
It's not at all clear to me that there are common requirements for remote accessibility defined, or that it's really an engine function. What would the engine be expected to do with a request to enable remote access if it were running in the context of an already-installed and configured system, where it's creating a new, alternate instance? Dave
