用于开发Spotify桌面应用程序的语言或技术是什么？ [英] What language or technology was used to develop the Spotify desktop application?

问题描述

有人知道用于开发Spotify桌面应用程序的语言或技术吗？
它稳定，美观，轻巧。

Does anybody know which language or technology was used to develop the Spotify desktop application? It's stable, good-looking and lightweight.

推荐答案

从此处： http://www.quora.com/What-is-the-technology-behind- the-Spotify-desktop-app

日期：2014-09-09

From here: http://www.quora.com/What-is-the-technology-behind-the-Spotify-desktop-app
Dated: 2014-09-09

Andreas Blixt， Spotify的5年员工：

Andreas Blixt, 5-year Spotify employee:

我们所有客户的核心都是C ++，但是自从拉斯穆斯（Rasmus）的
职位被压缩以来，这个核心一直都存在，功能被拆分为模块。随着
Spotify在越来越多的平台上可用以及
拥有更丰富的功能集，我们需要确保核心不会使
变成一点点的东西。这意味着需要将
的某些功能（例如播放控制）分解为各自独立的
模块。这些模块仍然是C ++，但是具有足够的独立性，因此它们的逻辑理论上可以用其他
语言实现。我们将这些模块的接口层称为 Cosmos，
的工作方式与HTTP不太相似。 Cosmos允许客户端的任何部分
使用任意路径和
有效负载与模块进行通信，从而实现更加灵活的体系结构。
的一些明显好处是版本接口（例如：GET sp：// player / v1 / main
返回播放器状态）和用于传递数据的JSON。
对于我们的桌面客户端中的另一次更改很重要。

The core of all our clients is C++, but that core has since Rasmus's post gotten condensed, with functionality split out into modules. As Spotify becomes available on more and more platforms as well as getting a richer feature set, we need to ensure that "core" doesn't become "a little bit of everything". This has meant breaking out certain features, such as playback control, into their own separate modules. These modules are still C++ but are self-contained enough that their logic could theoretically be implemented in other languages. We call the interface layer to these modules "Cosmos", and it works in a way not too dissimilar from HTTP. Cosmos lets any part of the client communicate with a module using arbitrary paths and payloads, allowing for a much more flexible architecture. Some obvious benefits are versioned interfaces (example: GET sp://player/v1/main returns player state) and JSON for passing data around. This is important for another change in our desktop client.

这些天，我们的许多桌面用户界面实际上正在使用Chromium Embedded
Framework（CEF ），这基本上意味着我们的视图由
JavaScript，HTML和CSS提供支持。对于我们所有的功能团队来说，能够
来处理其功能而不必担心会破坏其他人的视图，每个
的视图都放在自己的浏览器中（我想您可以认为
的视图作为标签在Chrome中显示，但我们在
时显示了多个视图）。但是，这带来了一个限制：在视图之间共享数据
变得更加困难。这就是Cosmos出现的地方，
确实简化了核心（C ++）和JavaScript
土地之间的通信：JS客户端可以发出任意请求，并且如果有
绑定，则该请求得到处理并回应。一个示例是
的消息端点，它允许任何视图将JSON数据推送到其他正在侦听的
个其他视图（类似于HTML5中的window.postMessage，
除外，该视图也可以接口） C ++模块）。这也是客户端中
的所有播放按钮如何知道轨道是否在播放或
不在，或者它是否可以脱机使用（另一个Cosmos模块），或者
是否保存了一个

A lot of our desktop UI these days is actually using Chromium Embedded Framework (CEF), which basically means our views are powered by JavaScript, HTML and CSS. For all of our feature teams to be able to work on their features without fear of breaking someone else's view, each view is sandboxed in their own "browser" (I guess you can think of the views as tabs in Chrome, except we show more than one at a time). This brings with it one restriction though: sharing data between views gets more difficult. This is where Cosmos comes in and really simplifies the communication between core (C++) and JavaScript land: the JS clients can make arbitrary requests and if there's a binding, that request gets handled and responded to. One example is the "messages" endpoint which lets any view push JSON data out to any other view that's listening (kind of like window.postMessage in HTML5, except this one can also interface with C++ modules). This is also how all the play buttons in the client know whether a track is playing or not, or whether it's available offline (another Cosmos module), or whether you've saved a song to your music.

我们的技术堆栈的另一个重要变化是，我们将
的某些逻辑进一步退回了视图聚合服务。因此，在
之前几乎只在客户端中执行所有逻辑的情况下，仅使用
后端作为数据存储，我们现在在数据存储和数据存储之间的逻辑层
中做更多的工作。客户端，暴露端点非常类似于Cosmos的
（实际上，您可以像调用Cosmos模块一样以
的方式调用后端，因此在各层之间移动并不麻烦）。
的原因有两个：一个是，它使我们能够更快地扩展到更多的
平台，因为实现
的客户端逻辑更少，其二，这确实有助于我们保持客户端行为更一致的
和最新的版本，因为客户端更愚蠢。为了缓解由此可能导致的
减慢，我们确保所有数据都有
缓存规则，以便客户端仍将数据
保留在本地，这不负责
曾经是业务逻辑。

Another important change to our technology stack is that we've moved some logic further "back", into view aggregation services. So where we would before do almost all logic in the clients, only using the backend as a data store, we now do much more work in a logic layer between the data stores and the clients, exposing endpoints very similar to Cosmos (in fact, you can call a backend the exact same way you call a Cosmos module, so moving between layers is not a hassle). The reason for this is two-fold: one, it lets us expand to more platforms more quickly because there's less client logic to implement and two, it really helps us keep our client behavior more consistent and up-to-date because the client is more "stupid". To mitigate any slowdown that might come from this we have ensured that there are caching rules for all data, so that the client will still keep data locally, it's just not responsible for as much business logic as it used to be.

这篇关于用于开发Spotify桌面应用程序的语言或技术是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！