[WFX] CloudMailRu: работа с облачным хранилищем от mail.ru
Модераторы: Avada, CaptainFlint, Nik, d-view, Моторокер
Погонял пару дней в реальной работе, в связи с чем пару соображений:
может, совсем убрать опциональность копирования/переноса через линки и сделать его безусловным? Трудно представить, для чего нужна была бы возможность отключения, а в этом случае никаких проблем не возникает - плагин работает сразу в соответствии с интуитивно ожидаемым. А кому покажется медленным, можно будет глянуть в хелп и узнать об альтернативе (команды clone и rmdir (здорово всё же, что Вы их реализовали - полный функционал теперь!)).
Ну и хорошо бы папки x32 и х64 просто включить в релиз - чтоб сразу работало.
Это конечно если не стоит задача ограниченного распространения плагина (только администратором) - уникальная ж вещь, несущая неисчислимые блага любому, даже изредка пользующемуся облаками. А так - из десятка вполне продвинутых, кому я сначала сообщил просто ссылкой на релиз, ни один не стал пользоваться - "не работает" и всё, а сделал пакетик, включающий всё необходимое - море восторга у всех - революционный же буквально плагин
может, совсем убрать опциональность копирования/переноса через линки и сделать его безусловным? Трудно представить, для чего нужна была бы возможность отключения, а в этом случае никаких проблем не возникает - плагин работает сразу в соответствии с интуитивно ожидаемым. А кому покажется медленным, можно будет глянуть в хелп и узнать об альтернативе (команды clone и rmdir (здорово всё же, что Вы их реализовали - полный функционал теперь!)).
Ну и хорошо бы папки x32 и х64 просто включить в релиз - чтоб сразу работало.
Это конечно если не стоит задача ограниченного распространения плагина (только администратором) - уникальная ж вещь, несущая неисчислимые блага любому, даже изредка пользующемуся облаками. А так - из десятка вполне продвинутых, кому я сначала сообщил просто ссылкой на релиз, ни один не стал пользоваться - "не работает" и всё, а сделал пакетик, включающий всё необходимое - море восторга у всех - революционный же буквально плагин
В каждом облаке есть ограничение по количеству одновременно существующих публичных ссылок. Оно довольно большое, но оно есть. При создании новой ссылки поверх лимита удаляется самая старая.может, совсем убрать опциональность копирования/переноса через линки и сделать его безусловным?
Я исхожу из соображения, что возможна ситуация, когда юзер исчерпал этот лимит, в таком случае копирование через линки будет неочевидным способом удалять ему один старый линк. Да, проблема не очень большая, тем не менее, я предпочту, чтобы пользователь сам включал эту настройку, выражая, таким образом, понимание ситуации.
В планах увеличить скорость процесса, Гислер поделился одним неочевидным мне способом для этого.А кому покажется медленным, можно будет глянуть в хелп и узнать об альтернативе
Да, не вижу причин не делать этого, добавлю в релиз. Но это всё равно не поможет избежать проблем с пользователями, не желающими и не умеющими читать справку и разбираться.Ну и хорошо бы папки x32 и х64 просто включить в релиз - чтоб сразу работало.
Да, точно. Нельзя. Спасибо, что.D1P писал(а):возможна ситуация, когда юзер исчерпал этот лимит, в таком случае копирование через линки будет неочевидным способом удалять ему один старый линк.
Простите, что вынудил пояснять почти очевидное
У, здорово! Хоть и то, что Вы добавили rmdir, уже принципиально круто!D1P писал(а):В планах увеличить скорость процесса
Спасибо!
Последний раз редактировалось Ronim Чт ноя 17, 2016 15:53, всего редактировалось 1 раз.
Ronim
Я частично исправил ошибку с удалением каталогов при переносе без галки "Copying/moving between accounts via public link". Частично - потому что наткнулся на ограничения API, не позволяющие полностью решить проблему (в тикете все подробности).
Если интересно - можете взять последний билд и потестировать.
Я частично исправил ошибку с удалением каталогов при переносе без галки "Copying/moving between accounts via public link". Частично - потому что наткнулся на ограничения API, не позволяющие полностью решить проблему (в тикете все подробности).
Если интересно - можете взять последний билд и потестировать.
D1P
Насколько я понял, плагин занижает 2-гигабайтное ограничение мейла на размер файла. Мейл щедр, и считает, что 2 Гб = 2048 Мб, т.е., если я правильно посчитал, 2147483648 байт. По крайней, 2100 млн. байт мейл точно пропускает.
Я не знаю, какое у Вас принято значение, но при попытке загрузки файлов более него, но допускаемого менеджером загрузки мейла (хоть через браузер, хоть через агент), выдаётся ошибка. Причём, галочка paid не помогает.
Это, наверное, непринципиально для большинства применений, но при сохранении многотомных архивов, подготовленных ранее с этим пределом (а он стандартен почти для всех облак), возникает куча неудобств. Если собственные архивы можно просто перепаковать заново, то с многотомными архивами, созданными другими программами (бэкап-, ISO- и пр.-менеджерами, например) это сложнее... А встроенный в плагин сплитинг делает контент облака зависимым от ТС.
ТС 8.5, билд сегодняшний
Насколько я понял, плагин занижает 2-гигабайтное ограничение мейла на размер файла. Мейл щедр, и считает, что 2 Гб = 2048 Мб, т.е., если я правильно посчитал, 2147483648 байт. По крайней, 2100 млн. байт мейл точно пропускает.
Я не знаю, какое у Вас принято значение, но при попытке загрузки файлов более него, но допускаемого менеджером загрузки мейла (хоть через браузер, хоть через агент), выдаётся ошибка. Причём, галочка paid не помогает.
Это, наверное, непринципиально для большинства применений, но при сохранении многотомных архивов, подготовленных ранее с этим пределом (а он стандартен почти для всех облак), возникает куча неудобств. Если собственные архивы можно просто перепаковать заново, то с многотомными архивами, созданными другими программами (бэкап-, ISO- и пр.-менеджерами, например) это сложнее... А встроенный в плагин сплитинг делает контент облака зависимым от ТС.
ТС 8.5, билд сегодняшний
Ну, не знаю. Я очень чувствителен к этому вопросу - у меня несколько десятков тысяч зашаренных 2-гигабайтных томов архивов на разных ресурсах. Поэтому я всегда ограничиваю размер тома (на всякий) двумя млрд. байт (инвариантных относительно взглядов хозяев хостингов на то, что такое терабайт
Что мейл (общий, надеюсь) считает терабайтом 1099511627776 байт, можно убедиться, посчитав размер некогда раздаваемого (или свободно конвертируемого ныне в любую из валют) им фантастического терабайта
Всё же: мейл часто сбоит последнее время, и при загрузке больших файлов можно этот сбой принять за ошибку, связанную с превышением предела. Я понимаю, что Вам это излишне говорить, но на всякий.
Только что залил через браузер пару десятков файлов, размером 2097 млн. байт.
И про галочку Ignore ещё - она что, работает только с реально paid? Я думал, она должна просто пропускать (в облако; пытаться, по крайней) файлы более 2 000 000 000 (как теперь выяснилось) байт...
Последний раз редактировалось Ronim Чт ноя 17, 2016 21:55, всего редактировалось 1 раз.
Я перепроверю ограничение. Но когда я выяснял лимит, это точно не была ошибка из-за сбоя, API вполне корректно возвращало описание ошибки.
Вроде бы так и должно всё работать. Но если включены и paid и split, файлы больше 2Гб всё равно будут резаться.Я думал, она должна просто пропускать (в облако; пытаться, по крайней) файлы более 2 000 000 000 (как теперь выяснилось) байт
Split отключён (я эту возможность и не тестировал) - всё равно ошибка.D1P писал(а):Вроде бы так и должно всё работать. Но если включены и paid и split, файлы больше 2Гб всё равно будут резаться.Я думал, она должна просто пропускать
Может, можно позволить пользователю задавать этот предел? (если Вы не измените его, конечно). Хоть бы где-нить в .ini. Уж очень многие программы разбивают на тома исходя из 1 Гб = если не 1024 Мб, то 1000, но таки Мб, который = 1024 кб (странно, но это есть).
Последний раз редактировалось Ronim Чт ноя 17, 2016 22:03, всего редактировалось 1 раз.