Sarah Jelinek wrote: > Ethan Quach wrote: >> >> >> Sarah Jelinek wrote: >>>> >>>> JJV Item 1: >>>> ----------- >>>> 5. Must provide support for development and testing. >>>> >>>> Should support for remote access be called out here? For example >>>> both the GUI and AI provide a mechanism to enable SSH to aid in >>>> testing and diagnoses. Should providing this type of hook be a >>>> requirement of the engine? >>> >>> Yes, I believe it should be. I will add. >>>> >>>> >>>> or would this fall under #7? >>>> >>> No, I think it is under deveploment and testing. >> >> This still seems more like a consumer issue to resolve. >> The engine can't possibly encapsulate the environment >> in which the consumer is operating in. The environment >> is what defines remote accessibility or not IMO. > I am not quite clear what you mean here. The engine is running in the > environment setup by the consumer. Enabling remote access can be done > by the engine, if the consumer requests it. > > Can you clarify?
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? thanks, -ethan
