Dict и 21-ый век

Юрий Лейкинд / @less_software

На повестке дня:

  • Что же такое dict?
  • Анализ
  • JSON & REST
  • dict2rest
  • Что дальше?

Что же такое dict?

A Dictionary Server Protocol

RFC 2229: http://tools.ietf.org/html/rfc2229

1997 год

Клиент - сервер

RFC 2229 определяет протокол общения клиента с сервером.

Клиенты

  • dict(1)
  • dictem (для Emacs)
  • gdict
  • kdict
  • dikt
  • различные библиотеки на различных ЯП

define

dictionaries

стратегии поиска

поиск

Клиент, который всегда с тобой

Обратите внимание на эту милую точачку и response status code!

Или так

Анализ

Два аспекта:

  1. Клиент-серверная архитектура
  2. Протокол

1. Клиент-серверная архитектура

Веб-сайт - это тоже клиент серверная архитектура

Пример: mijnwoordenboek.nl

Отличные, просто замечательные словари

Ужасный сайт, ужасный UI, реклама!

Закрытые словари!

Google translate

вебсайт и мобильные приложения

Тоже клиент-серверная архитектура

но это плохой словарь

Кран: une grue (FR)

Кран: un robinet (FR)

Кран: een kraan, een bouwkraan (NL)

Кран: een kraan (NL)

Клиент-серверная архитектура

Мы пользуемся зоопарком словарей с разными UI, разным качеством словарей, как клиент-сервер, так и программ, которые устанавливаются на компьютер.

Ergo:

Словари, находящиеся в публичном доступе, со стандартизированным интерфейсом, не требующие инсталляции/апгрейда на компьютер пользователя - это очень, очень хорошая идея!

2. Протокол

Взгляд из 2104 года на 1997.

Да, он telnet friendly.

На этом список достоинств заканчивается.

Самый главный вопрос: Зачем вообще нужен специальный особый протокол/формат данных для передачи словарных данных?!!

А?!!

Давайте забабахаем текстовый over tcp протокол для API Github! Или для API Dropbox.

Давайте изобретем по отдельному протоколу для каждого из 100500 AWS, от S3 до Amazon Cloudsearch!

Понатыкаем своих собственных field & record separators, свои response codes. (Мне нравятся фигурные скобки, давайте фигурные скобки).

Будет круто!

Можно будет телнетом обращаться к API's:


$ telnet my_own_theme_park_with_blackjack_and_field_separators.github.com 6666

Trying 66.66.66.66...
Connected to my_own_theme_park_with_blackjack_and_field_separators.github.com.
Escape character is '^]'.

GIMME {jquery}/{jquery-mobile}!

{SUCCESS}
{"private": false}
{"html_url": "https://github.com/jquery/jquery-mobile"}
{"description": "jQuery Mobile Framework"}
{"fork": false}
!!!-34-OKEY!!!
{{
Connection closed by foreign host.

Круто, да?

Response codes?


In response to every command, the following general status responses
   are possible:

             500 Syntax error, command not recognized
             501 Syntax error, illegal parameters
             502 Command not implemented
             503 Command parameter not implemented
             420 Server temporarily unavailable
             421 Server shutting down at operator request

Вам это ничего не напоминает?

Аутентификация?


The client can authenticate itself to the server using a username and
   password.  The authentication-string will be computed as in the APOP
   protocol discussed in [RFC1939].  Briefly, the authentication-string
   is the MD5 checksum of the concatenation of the msg-id (obtained from
   the initial banner) and the "shared secret" that is stored in the
   server and client configuration files.

Аутентификация в протоколе передачи словарных статей?!!

К счастью, современный интернет работает не так.

Вышеупомяное обращение к github API через несуществующий протокол на самом деле делается вот так:

https://api.github.com/repos/jquery/jquery-mobile

JSON &REST

JSON

JavaScript Object Notation

  • Number
  • String
  • Boolean
  • Array
  • Object a.k.a. associative array

По совместительству - подмножество Javascript.

Читабельно.

REST

REpresentational State Transfer - архитектурный стиль

http://en.wikipedia.org/wiki/Representational_state_transfer

Применительно к вебсервисам:

  • Использование уже существующей инфраструктуры HTTP, как-то:
  • HTTP response codes
  • HTTP methods (verbs):
    • GET - чтение ресурса
    • DELETE - удаление ресурса
    • POST - создание ресурса
    • PUT - модификация ресурса

JSON RESTful веб-сервисы.

Они везде.

Ткните пальцем в вебсервис - это будет JSON RESTful веб-сервис.

А как Вы думаете, как игрушка на Вашем смартфоне общается со своим сервером?

Есть и другие способы общения программ, но JSON RESTful - это решение по умолчанию

  • Таким образом, вместо изобретения велосипедов мы используем существующую инфраструктуру World Wide Web
    • Proxies
    • HTTPS
  • Библиотеки для JSON есть на всех ЯП
  • Браузер становится нашим telnet'ом

Последние несколько слайдов я чувствую себя Капитаном Очевидность

Однако если есть люди, считающие, что протокол dict имеет какое-либо право на существование в 2014 году, я готов доказывать очевидный факт:

Словарный dict сервер должен быть обычным RESTful вебсервисом

dict2rest

простой dict to REST прокси, написанный на Erlang + webmachine
https://github.com/leikind/dict2rest

API

- Однако теперь 10 запросов будут открывать и закрывать 10 соединений к dict серверу!

- Как насчёт persistent connections:



#!/bin/bash

REQ1="GET /strategies HTTP/1.1\r\nHost: dict2rest.herokuapp.com\r\nConnection: keep-alive\r\nAccept-Language: en-US,en;q=0.8\r\n\r\n"
REQ2="GET /dictionaries HTTP/1.1\r\nHost: dict2rest.herokuapp.com\r\nConnection: keep-alive\r\nAccept-Language: en-US,en;q=0.8\r\n\r\n"
REQ3="GET /define?w=apple HTTP/1.1\r\nHost: dict2rest.herokuapp.com\r\nConnection: keep-alive\r\nAccept-Language: en-US,en;q=0.8\r\n\r\n"

(echo -ne $REQ1; echo -ne $REQ2; echo -ne $REQ3) | netcat dict2rest.herokuapp.com 80

HTTP rocks!

- Ты решаешь не ту проблему! Самая большая проблема - это словари, это наполнение!

- Я согласен, качественные словари - это большая проблема. Но мы можем по-крайней мере модернизировать dict инфраструктуру, сделать её современной, более понятной и привлекательной, возможно, это увеличит шансы на качественные словари в формате dict...

Что дальше?

Что дальше с клиентской частью?

dict(1) аналог, имеющий почти такой-же CLI, но использующий RESTful веб-сервис.

Не должен тащить за собой 20-мегабайтовый runtime, то есть

  • либо быть на компилируемом ЯП (C, Go)
  • либо shell + curl + что-то для парсинга json

А не хотите ли Вы поучаствовать и пописàть Open-Source код?

Что дальше с серверной частью?

  • Вариант 1: поддержка множественных dict серверов...
    dictd остаётся нетронутым...
    но dict протокол остаётся там...
    несколько интересных вопросов...
  • Вариант 2. Используем dictd как внешнюю библиотеку ...
    erlang код из dict2rest использует dictd как внешний процесс...
    вместо клиента dict протокола в dict2rest будут прямые вызовы dictd (external OS process + erlang port + erlang connected process)
    libdict?

Ваше мнение?

Fork me hard: https://github.com/leikind/dict2rest

Fork Cheusov gently: https://www.sf.net/projects/dict

Присоединяйтесь

Спасибо