SCORM：这是将数据提交到 LMS 的正确行为吗
SCORM: is this a proper behaviour for commiting data to the LMS
我遇到了流动性问题。我有一个正在构建的服装课程，它基于 SCORM 2004 第 3 版，并且部署在 SABA LMS 上。
我正在做的是：
我用“API.SetValue”来设置一些数据
我使用“API.Commit”将数据保存到LMS
（我正在使用 wrapper library 但它仍然使用核心功能）
现在我对不同的数据字段做了几次，我们称它们为“X”、“Y”和“Z”。
我对服务器的第一个请求的期望是只看到“X”被发送，而这正是我所看到的。然后在第二个我希望只看到“Y”，但这是我不明白的，我看到 API 正在发送“X”和“Y”。当然，第三个是发送“X”、“Y”和“Z”
你能理解我的顾虑。我知道每次我想要保存 0.1k 的数据时，我都必须提出 40-50K 的请求。
如果这是 SCORM、我正在使用的特定 LMS (SABA) 的问题，或者是我做错了什么，有人可以向我解释一下吗？
这不是 SCORM 的事情。 SCORM 只是告诉您 API - GetValue、SetValue、Commit 等 - 以及每次调用的一般行为。但它并没有规定 LMS 实际上是如何做这些事情的。 LMS 似乎正在保存数据客户端。因此，当您设置 X 时，它会将其保存在本地。当您调用 Commit 时，LMS 获取客户端的所有数据并将其发送回服务器。稍后当您设置 Y 和 Z 时，它会做同样的事情 - 获取所有数据并发送回 LMS。
除非让 LMS 改变其行为，否则我认为您对此无能为力。我遵循的经验法则是仅在您真正需要时才提交。您可以只为 X、Y 和 Z 调用 SetValue，然后仅在转到另一个 SCO 或到达您决定必须将此数据保存到 LMS 的位置时才提交。
首先我想说你没有做错任何事，这完全是 API 的错 - 这是我今天遇到的第二个 API（巧合哈哈）不良做法：
有好的做法和想法，也有不好的做法和想法 - 不幸的是，不好的做法和想法编码起来要快得多，所以人们在组装客户端时往往不会考虑这些事情 API。
- 最简单和最糟糕的（字面意思）做事方式是简单地将所有数据设置在一个对象中，并在调用 Commit 时发送整个对象。
- 对此的一个改进是缓存自上次提交后更改的 键 - 好处是并非所有内容都被发送，缺点是不发送的值更改再次发送。
- 最好的办法是缓存调用提交时发送的值，然后在下一次比较它们 - 这样只发送已更改的值.
- 最后是合并上述两种方法 - 缓存键，这样您只检查这些值而不是每个值。
其他注意事项：
- 压缩数据是值得的 - zip 在 Javascript 中很容易做到，并且会显着减少网络带宽。
- 发送哈希或幻数来验证数据也应该是一项要求 - 让服务器知道应该设置它。
- 回复一个散列或幻数很重要，这样客户端就知道缓存需要更新（发送时更新有点安全，但不如等待回复并知道服务器与客户）。
API 中的数据可以以多种方式存储，但如果有选择，我会选择标准 Javascript 对象，每个键都是 cmi 键，值作为具有各种标志和缓存值以及当前值（用于后续的 GetValue / Commit 调用）的对象（或数组）。
最后记住 Commit 本身是可选的 - API 本身应该在调用 SetValue 一段时间后有效地调用它。
所以重复我的第一句话 - 不是你的错，完全是 API 提供的错。对其进行更改对他们来说应该很容易 - 在服务器端，它只需要支持合并而不是替换发送的数据。
我遇到了流动性问题。我有一个正在构建的服装课程，它基于 SCORM 2004 第 3 版，并且部署在 SABA LMS 上。 我正在做的是：
我用“API.SetValue”来设置一些数据
我使用“API.Commit”将数据保存到LMS
（我正在使用 wrapper library 但它仍然使用核心功能）
现在我对不同的数据字段做了几次，我们称它们为“X”、“Y”和“Z”。
我对服务器的第一个请求的期望是只看到“X”被发送，而这正是我所看到的。然后在第二个我希望只看到“Y”，但这是我不明白的，我看到 API 正在发送“X”和“Y”。当然，第三个是发送“X”、“Y”和“Z”
你能理解我的顾虑。我知道每次我想要保存 0.1k 的数据时，我都必须提出 40-50K 的请求。
如果这是 SCORM、我正在使用的特定 LMS (SABA) 的问题，或者是我做错了什么，有人可以向我解释一下吗？
这不是 SCORM 的事情。 SCORM 只是告诉您 API - GetValue、SetValue、Commit 等 - 以及每次调用的一般行为。但它并没有规定 LMS 实际上是如何做这些事情的。 LMS 似乎正在保存数据客户端。因此，当您设置 X 时，它会将其保存在本地。当您调用 Commit 时，LMS 获取客户端的所有数据并将其发送回服务器。稍后当您设置 Y 和 Z 时，它会做同样的事情 - 获取所有数据并发送回 LMS。
除非让 LMS 改变其行为，否则我认为您对此无能为力。我遵循的经验法则是仅在您真正需要时才提交。您可以只为 X、Y 和 Z 调用 SetValue，然后仅在转到另一个 SCO 或到达您决定必须将此数据保存到 LMS 的位置时才提交。
首先我想说你没有做错任何事，这完全是 API 的错 - 这是我今天遇到的第二个 API（巧合哈哈）不良做法：
有好的做法和想法，也有不好的做法和想法 - 不幸的是，不好的做法和想法编码起来要快得多，所以人们在组装客户端时往往不会考虑这些事情 API。
- 最简单和最糟糕的（字面意思）做事方式是简单地将所有数据设置在一个对象中，并在调用 Commit 时发送整个对象。
- 对此的一个改进是缓存自上次提交后更改的 键 - 好处是并非所有内容都被发送，缺点是不发送的值更改再次发送。
- 最好的办法是缓存调用提交时发送的值，然后在下一次比较它们 - 这样只发送已更改的值.
- 最后是合并上述两种方法 - 缓存键，这样您只检查这些值而不是每个值。
其他注意事项：
- 压缩数据是值得的 - zip 在 Javascript 中很容易做到，并且会显着减少网络带宽。
- 发送哈希或幻数来验证数据也应该是一项要求 - 让服务器知道应该设置它。
- 回复一个散列或幻数很重要，这样客户端就知道缓存需要更新（发送时更新有点安全，但不如等待回复并知道服务器与客户）。
API 中的数据可以以多种方式存储，但如果有选择，我会选择标准 Javascript 对象，每个键都是 cmi 键，值作为具有各种标志和缓存值以及当前值（用于后续的 GetValue / Commit 调用）的对象（或数组）。
最后记住 Commit 本身是可选的 - API 本身应该在调用 SetValue 一段时间后有效地调用它。
所以重复我的第一句话 - 不是你的错，完全是 API 提供的错。对其进行更改对他们来说应该很容易 - 在服务器端，它只需要支持合并而不是替换发送的数据。