From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Detecting display/frame capability in an Emacs daemon Date: Wed, 20 Feb 2013 15:24:51 +0900 Message-ID: <871ucbh58s.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1ev1uchryvm.fsf@LT-MMAUGER.office.techtarget.com> <1361060596.66870.YahooMailNeo@web160902.mail.bf1.yahoo.com> <87obfiwge8.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1361341520 12477 80.91.229.3 (20 Feb 2013 06:25:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Feb 2013 06:25:20 +0000 (UTC) Cc: michael@mauger.com, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 20 07:25:42 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U837b-0005mR-O0 for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2013 07:25:39 +0100 Original-Received: from localhost ([::1]:40285 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U837H-00021z-Ha for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2013 01:25:19 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:48790) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U837E-00021p-30 for emacs-devel@gnu.org; Wed, 20 Feb 2013 01:25:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U8379-0001es-En for emacs-devel@gnu.org; Wed, 20 Feb 2013 01:25:15 -0500 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:37806) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8378-0001P1-V9; Wed, 20 Feb 2013 01:25:11 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 6EEDC3FA0731; Wed, 20 Feb 2013 15:24:52 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0FAA31A27AE; Wed, 20 Feb 2013 15:24:52 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta32) "habanero" b0d40183ac79 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.223 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:157188 Archived-At: Richard Stallman writes: > > I am unfamiliar with the things you are using but I do it with > > rsync. It would be a clear thing if that damned "cloud" didn't > > obscure it. > > Not "obscure", "abstract". > > I meant "obscure". I know you did; you always mean what you say. That doesn't mean your meaning is always useful. In this case, I don't think it is. I think that Emacs should deal with this issue on the more abstract level of resource shared by hosts of varying capability, which is reasonably accurately expressed by "cloud". > The term "cloud computing" is not a clean abstraction but a > confusion between different and unrelated ways of using the > network. As you just wrote yourself, they're related by use of the network. Mere presence of the network already implies that Emacs users must be concerned with different instances of Emacs using the same resources in different contexts, with those differences being more or less unpredictable as hosts of varying kinds connect to and disconnect from the network. It may not be Emacs's business to be concerned with that, I don't know. However, "the cloud" makes such sharing far more accessible to both busy users who don't care to shoulder administrative burden of less sophisticated resource-sharing protocols, and unsophisticated users. I think the demand for an Emacs that works and plays well with both the "cloud" of transparently shared resources, and the varied underlying implementations of that idea, will increase in the future. > I think file synching is the right term for this. I disagree. File synching is an implementation. The OP doesn't care that the files exist in multiple places, however, and he would indeed have similar problems with NFS or Tramp (where the file is fetched over the network, though one is implemented in the OS and the other in Emacs) or with Coda FS (where the files are cached, the network use is reduced to a quick version check if the cache is fresh, and the cached files are not accessible to the user by a local name). The implementation doesn't matter; what matters is the abstract idea of a resource automatically shared by different instances of Emacs. "In the cloud" is a reasonable informal expression of this concept. > The difference between that and "sharing resources among his own > machines" is so small that they seem equivalent to me, which means > it is not wrong. Many resources are not file-based. For example, the OP's question about determining display capability would matter if you use Emacs to invoke a remote program that generates an image locally. I don't know what the capabilities of OpenCloud are, but I wouldn't be surprised if it included such remote processing. How is the difference between sharing such resources and synching files "so small that they seem equivalent"?