SCORM: это правильное поведение для передачи данных в LMS?

У меня течет проблема. У меня есть курс костюмов, который я создаю, он основан на SCORM 2004 3-го издания и развернут в SABA LMS. Что я делаю:

  1. Я использую API.SetValue для установки некоторых данных

  2. Я использую API.Commit для сохранения данных в LMS.

    (я использую библиотеку-оболочку но тем не менее он использует основные функции)

теперь я делаю это несколько раз для разных полей данных, назовем их X, Y и Z.

Я ожидаю, что при первом запросе к серверу будет отправлено только X, и это именно то, что я вижу. Тогда на втором я ожидаю увидеть только Y, но вот чего я не понимаю, я вижу что API отправляет и X и Y. Ну и конечно же 3-й отправляет X, Y и Z

вы можете понять, что меня беспокоит. Я дошел до того, что каждый раз, когда я хочу сохранить 0,1 КБ данных, мне приходится делать 40-50 КБ запросов.

Может ли кто-нибудь объяснить мне, является ли это проблемой SCORM, конкретной LMS, которую я использую (SABA), или это что-то, что я делаю неправильно?


javascript scorm scorm2004
person Nikola.grancharov    schedule 29.09.2015    source источник
comment
У вас есть 3 пути, по которым LMS может пойти с попыткой студента. Не кешируется, кешируется. и кэшированный гибрид. У каждого есть свои плюсы и минусы в реализации, но то, как они справятся с этим, полностью зависит от LMS. Это также зависит от того, как данные отправляются и в каком формате они находятся. Таким образом, вы можете увидеть что-то около 12-15 КБ для отправки JSON, и вы можете даже увидеть больше, если файлы cookie прикреплены. Cached-Hybrid — самый компактный из кэшированных вариантов, поскольку он отправляет только то, что изменилось. Non-Cached совершает множество обращений к серверу, что может создать нагрузку на DNS, снижающую производительность.   -  person Mark    schedule 30.09.2015

Ответы (2)


arrow_upward
2
arrow_downward

Это не SCORM. SCORM просто сообщает вам API — GetValue, SetValue, Commit и т. д. — и общее поведение для каждого вызова. Но это не диктует, как LMS на самом деле делает эти вещи. Похоже, LMS сохраняет данные на стороне клиента. Поэтому, когда вы устанавливаете X, он сохраняет его локально. Когда вы вызываете Commit, LMS берет все данные со стороны клиента и отправляет их обратно на сервер. Позже, когда вы устанавливаете Y и Z, он делает то же самое — берет все данные и отправляет их обратно в LMS.

Если не считать того, что LMS изменит свое поведение, я не думаю, что вы можете что-то с этим поделать. Эмпирическое правило, которого я придерживаюсь, заключается в том, что вы совершаете коммит только тогда, когда вам это действительно нужно. Вы можете просто вызывать SetValue для X, Y и Z, а затем фиксировать только при переходе к другому SCO или при достижении точки, когда вы решите, что эти данные должны быть сохранены в LMS.

person tom creighton    schedule 29.09.2015
comment
хорошо, это подтверждает то, что я думал, 10x. Только один дополнительный вопрос к этому. Поскольку я должен следить за тем, чтобы каждое взаимодействие с пользователем (а их предостаточно) сохранялось, но, очевидно, нецелесообразно совершать фиксацию после всех из них, имеет смысл добавить одну фиксацию onbeforeunload в дополнение к сокращенному набор коммитов, как вы и предполагали? - person Nikola.grancharov; 29.09.2015
comment
Только что сам опубликовал ответ, но, несмотря на то, что Commit не является обязательным, вы должны вызвать его перед завершением в обработчиках событий beforeunload и unload. Я лично тоже ставлю Commit на 30-секундную задержку после установки чего-либо — чтобы попытаться уменьшить количество сетевых событий ;-) - person Rycochet; 29.09.2015
comment
Если бы мне нужно было ранжировать проблемы: перегрузка сети и потеря данных, потеря данных была бы более серьезной проблемой, поэтому я рекомендую делать коммиты чаще. Однако это не означает, что вам нужно выполнять коммит после каждого SetValue. Найдите темп, который подходит вашему SCO, например, один раз на странице или один раз за урок. Никогда не ограничивайте его одним разом за курс, потому что учащийся может потерять все. Так происходит все время. - person pipwerks; 29.09.2015
comment
Кстати, я написал об этом сообщение в блоге некоторое время назад, чтобы привести несколько примеров: pipwerks.com/2010/07/27/scorm-tip-dont-forget-to-commit - person pipwerks; 29.09.2015
comment
Хороший блог - единственное, что я бы добавил, это когда данные устанавливаются программно, поэтому на самом деле у вас нет хорошей последовательности SetValues ​​​​для приятного места впоследствии - почему размещение setTimeout в вызове оболочки работает хорошо как общий на все лады :-) - person Rycochet; 29.09.2015

arrow_upward
2
arrow_downward

Во-первых, я хочу сказать, что вы не делаете ничего плохого, во всем виноват API - это второй API, с которым я столкнулся сегодня (совпадения, лол), который использует плохие методы:

Есть как хорошие методы и идеи, так и плохие — к сожалению, плохие кодируются намного быстрее, поэтому люди, как правило, не думают об этих вещах при сборке API на стороне клиента.

  • Самый простой и худший (буквально) способ сделать что-то — просто установить все данные в одном объекте и отправлять весь этот объект всякий раз, когда вызывается Commit.
  • Улучшение заключается в кэшировании ключей, которые изменились с момента последней фиксации. Преимущество в том, что не все отправляется, а недостаток в том, что значения, которые не изменились, отправляются снова.
  • Лучше всего кэшировать значения, которые отправляются при вызове фиксации, а затем сравнивать их в следующий раз — таким образом отправляются только значения, которые изменились.
  • Наконец, объединяет два вышеуказанных метода — кэшируйте ключи, чтобы вы проверяли только эти значения, а не все.

Другие вещи, которые следует иметь в виду:

  • Сжатие данных имеет смысл — zip легко сделать в Javascript, и это значительно снизит пропускную способность сети.
  • Отправка хэша или магического числа для проверки данных также должна быть требованием — сообщите серверу, что это должно быть установлено.
  • Ответ с хэшем или магическим числом важен, чтобы клиент знал, что кеш необходимо обновить (обновление при отправке является своего рода безопасным, но не таким безопасным, как ожидание ответа и знание того, что сервер соответствует клиенту).

Данные в API могут храниться несколькими способами, но, учитывая выбор, я бы выбрал стандартный объект Javascript, где каждый ключ является ключом cmi, а значением является объект (или массив) с различными флагами и кешем. значения, а также текущее значение (для последующих вызовов GetValue/Commit).

Наконец, помните, что Commit сам по себе необязателен — сам API должен эффективно вызывать его через определенный период времени, когда вызывается SetValue.

Итак, повторю мое первое предложение - не ваша вина, а полностью вина предоставленного API. Внесение изменений в него должно быть легким для них - на стороне сервера просто необходимо поддерживать слияние, а не замену отправленных данных.

person Rycochet    schedule 29.09.2015
comment
На практике Commit не является обязательным. Я сталкивался с LMS, которые не будут сохранять данные, если вы в какой-то момент не вызовете Commit самостоятельно. - person pipwerks; 29.09.2015