[/b/] [/d/] [/tu/] [/a/] [/ph/] [/wa/] [/cg/] [/t/] [/p/]

[Burichan] [Foliant] [Futaba] [Greenhell] [Gurochan] [Photon] - [Home] [Manage] [Archive]

[Return]
Posting mode: Reply
Leave these fields empty (spam trap):
Name
Link
Subject
Comment
File
Verification
Password (for post and file deletion)
  • Supported file types are: GIF, JPG, PNG
  • Maximum file size allowed is 20480 KB.
  • Images greater than 200x200 pixels will be thumbnailed.

File: 1520724963399.webm -(3869327 B, 1920x1080) Thumbnail displayed, click image for full size.
3869327 No.4628  

Зашёл я в архив http://nowere.net/a/arch/ и был удручён его видом, так как подкаталоги отсортированы в алфавитном порядке их имён, что не соответствует числовому порядку их, и порядку времени создания (наиболее важному) также не соответствует.

Если оглавление каталога создаёт Apache Server, то предлагаю воспользоваться упомянутою по адресу http://httpd.apache.org/docs/2.4/mod/mod_autoindex.html#indexorderdefault директивою «IndexOrderDefault Ascending Date» и тем невозбранно достигнуть желаемого.

>> No.4632  

Оно не апачем отдается.

>> No.4634  

Это за пределами досягаемости вакаба-движка.

>> No.4635  
File: 1520809320332.webm -(1727484 B, 1920x1080) Thumbnail displayed, click image for full size.
1727484

Моя следующая догадка гласит, что оглавление каталога создаёт nginx.

Если эта догадка вполне справедлива, то тогда нельзя ли воспользоваться модулем, по адресу https://github.com/aperezdc/ngx-fancyindex предлагаемым (или некоторым другим аналогичным модулем по вкусу администрации сайта), для устройства сортировки по дате?

>> No.4637  
File: 1520833582139.png -(10250 B, 569x75) Thumbnail displayed, click image for full size.
10250

Помоему сортировка по дате будет еще менее логичной

>> No.4639  

Вроде как определённая логика всё же есть за этим.

Если я вѣрно понимаю, то порядок номеров отражает собою порядок создания, а порядок дат подкаталогов отражает собою порядок попадания в архив.

>> No.4699  

Просто оставлю это тут

https://github.com/WagonOfDoubt/IIchan-archive-search/

>> No.4702  
File: 1523152072650.webm -(17324298 B, 1920x1200) Thumbnail displayed, click image for full size.
17324298

>>4699

Спасибо, воспользовался.

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

Более того: сделалось не трудно увидеть, что в 2010 году в архив попадали, главным образом, обсуждения из 2008 года, а в 2011 и в 2012 и в 2013 году — обсуждения из 2009 года, а в 2014 и в 2015 году — обсуждения из 2010 года, а в 2016 и в 2017 и в 2018 году — обсуждения из 2011 года, так что разница между временем обсуждения и временем архивации является и многолетнею, и возрастающею, так что возросла ужé и до семи лет.

>> No.4703  

И этому семилетнему сроку я скорее рад, потому что на протяжении того же времени сохраняется работоспособность URLов: можно кому-нибудь дать гиперссылку и не опасаться того, что она через несколько месяцев (или даже к 2023 году) начнёт вдруг бездействовать и выдавать ошибку 404 вместо того, чего надо.

Лучше того могло бы быть только автоматическое создание на сервере перенаправлений («HTTP/1.1 301 Moved Permanently») по мере отправления материалов в архив — в этом случае работоспособность гиперссылок на архивированные материалы равнялась бы длительности существования всего сайта, но движок Вакабы вроде как на такое создание не считается способным.

Возможно, ещё лучше того могло бы быть только сохранение материалов не в централизованном архиве, а в P2P-распределённой файловой системе (наподобие IPFS, например), хотя и у той есть ведь какой-то конечный срок жизни, равный сроку употребления используемой хэш-функции (SHA-256 в случае IPFS), после нахождения коллизий в которой неизбежною сделается и неработоспособность прежних адресов. Так что ещё не может быть известно, Nowere ли переживёт IPFS или наоборот.

>> No.4704  

>>4703

> Возможно, ещё лучше того могло бы быть только сохранение материалов не в централизованном архиве, а в P2P-распределённой файловой системе (наподобие IPFS, например)

Его всегда можно скачать и сохранить любым другим способом.

>> No.4705  

>>4704

Это соображение совершенно справедливо, но скачивание и сохранение способно достигнуть одной только сохранности контента, но не высшей цели работоспособности первоначального URLа его, ранее опубликованного в каких-либо таких средах, в которых его нельзя уж после публикации редактировать (а именно таковы и большинство имиджборд, и реплики в Твиттере, и гипертекстовый Фидонет, и так далее).



Delete Post []
Password

[/b/] [/d/] [/tu/] [/a/] [/ph/] [/wa/] [/cg/] [/t/] [/p/]