Привет. Хочу использовать fetch через API. Проблема в том, что через API, запуск fetch повторяет свой статус бесконечно, пока не будет прерван '/cancel'. Это создает сложности. Требуется, чтобы кто-то (например, я) реализовал совершенно другой метод для использования '/tool fetch' в Mikrotik через API. Это несовместимо со стандартом API и обработкой ошибок.
Пример того, как выглядит успешная загрузка:
<<< /tool/fetch
<<< =url=http://ftp.pl.debian.org/debian/README
<<<
>>> !re
>>> =status=connecting
>>>
>>> !re
>>> =status=finished
>>>
>>> !re
>>> =status=finished
>>>
>>> !re
>>> =status=finished
>>>
>>> !re
>>> =status=finished
>>>
/cancel
<<< /cancel
<<<
>>> !trap
>>> =category=2
>>> =message=interrupted
>>>
>>> !done
>>>
>>> !done
>>>
Пример, когда загрузка не удалась:
<<< /tool/fetch
<<< =url=http://wp.pl/100
<<<
>>> !re
>>> =status=connecting
>>>
>>> !re
>>> =status=failed
>>>
>>> !re
>>> =status=failed
>>>
>>> !re
>>> =status=failed
>>>
>>> !re
>>> =status=failed
>>>
>>> !re
>>> =status=failed
>>>
/cancel
<<< /cancel
<<<
>>> !trap
>>> =category=2
>>> =message=interrupted
>>>
>>> !done
>>>
>>> !trap
>>> =message=failure: 301 Moved Permanently
>>>
>>> !done
>>>
Как видите в обоих случаях нужен '/cancel'.
Что бы я (как разработчик) хотел бы видеть: когда fetch запускается, не выводить никакой информации. Просто ждать, пока не закончится загрузка/выгрузка. В случае успеха заканчивать это с помощью '!done'. Возвращать .id нового файла при завершении загрузки. В случае неудачи заканчивать это с помощью '!trap' и добавлять =msg=ДЕТАЛЬНОЕ СООБЩЕНИЕ О ПРОИЗОШЕДШЕМ. Это хорошо бы соответствовало концепциям API и облегчило бы перехват исключений. Это облегчит работу любому программисту без какого-либо "spagetti code".
Разработчики Mikrotik, пожалуйста, присмотритесь к этому, потому что некоторые из нас действительно хотели бы видеть, как это работает без каких-либо "грязных хаков".
Это также обсуждалось здесь:
Пример того, как выглядит успешная загрузка:
<<< /tool/fetch
<<< =url=http://ftp.pl.debian.org/debian/README
<<<
>>> !re
>>> =status=connecting
>>>
>>> !re
>>> =status=finished
>>>
>>> !re
>>> =status=finished
>>>
>>> !re
>>> =status=finished
>>>
>>> !re
>>> =status=finished
>>>
/cancel
<<< /cancel
<<<
>>> !trap
>>> =category=2
>>> =message=interrupted
>>>
>>> !done
>>>
>>> !done
>>>
Пример, когда загрузка не удалась:
<<< /tool/fetch
<<< =url=http://wp.pl/100
<<<
>>> !re
>>> =status=connecting
>>>
>>> !re
>>> =status=failed
>>>
>>> !re
>>> =status=failed
>>>
>>> !re
>>> =status=failed
>>>
>>> !re
>>> =status=failed
>>>
>>> !re
>>> =status=failed
>>>
/cancel
<<< /cancel
<<<
>>> !trap
>>> =category=2
>>> =message=interrupted
>>>
>>> !done
>>>
>>> !trap
>>> =message=failure: 301 Moved Permanently
>>>
>>> !done
>>>
Как видите в обоих случаях нужен '/cancel'.
Что бы я (как разработчик) хотел бы видеть: когда fetch запускается, не выводить никакой информации. Просто ждать, пока не закончится загрузка/выгрузка. В случае успеха заканчивать это с помощью '!done'. Возвращать .id нового файла при завершении загрузки. В случае неудачи заканчивать это с помощью '!trap' и добавлять =msg=ДЕТАЛЬНОЕ СООБЩЕНИЕ О ПРОИЗОШЕДШЕМ. Это хорошо бы соответствовало концепциям API и облегчило бы перехват исключений. Это облегчит работу любому программисту без какого-либо "spagetti code".
Разработчики Mikrotik, пожалуйста, присмотритесь к этому, потому что некоторые из нас действительно хотели бы видеть, как это работает без каких-либо "грязных хаков".
Это также обсуждалось здесь:
