Add Cloud.app v2.0.2

[amanaplan]

Naming this app was challenging. The public/marketing name of the app and related service is CloudApp, but the developer named its Mac OS X application bundle simply Cloud.app.

I realize that in the Cask Naming Reference documentation, both

• Remove .app from the end

and

• Remove the term "app" from the end, if the developer styles the name like "Software App.app". Exception: if the term "app" describes functionality, as in rcdefaultapp.rb.

seem indicate that the application's collection of names should generally be:

App Name on Disk	Canonical App Name	Cask Name	Cask File	Cask Class
Cloud.app	Cloud	cloud	cloud.rb	Cloud

However, the app and service are just simply never referenced, marketed, or themed (in the app's UI) as Cloud, and the use of this term alone seems very ambiguous. One might even be able to argue, albeit utterly pedantic, that the "app" does indeed describe functionality as it's a desktop app companion to a cloud service.

I think it may be advised to except this app from the "letter" of the naming rules in order to better follow their spirit and intent. Instead, I've suggested (in this pull request) to use the following collection of names:

App Name on Disk	Canonical App Name	Cask Name	Cask File	Cask Class
Cloud.app	CloudApp	cloudapp	cloudapp.rb	Cloudapp

I think making this adjustment better relates to and identifies the app, and using cloudapp will certainly increase its utility and findability as a cask to homebrew-cask users.

Thank you for your amazingly useful contribution! ...And, thanks in advance, for taking a look at this pull request.

[rolandwalker]

Hi!

Thanks for the contribution and the analysis. One of the reasons we adopted predictable naming rules was to avoid duplicate submissions. This PR is a duplicate: see cloud.rb as per the naming conventions.

Cask names are ruled by several different constraints: they are filenames on disk, must have corresponding Ruby class names, be unique, and be searchable. It's asking too much, and you are right that Casks which meet the other requirements are not always searchable.

To address this, in #4953 we are adding a tags stanza to give more data to search against. I'd also like to search against the app link (in case it differs from the Cask name) and would not be against searching the URL if it was helpful in some cases.

We are also breaking the constraint that Cask names correspond to Ruby classes in #5365.

[radeksimko]

As @rolandwalker mentioned, this is a duplicate of an existing cask, so I'm closing this.