LINUX.ORG.RU
Новости — Open Source  

Пятая редакция стандарта XML 1.0 несовместима с XML Namespaces 1.0

 ,


0

0

Попытка сделать XML более интернациональным привела к несовместимости с текущей редакцией стандарта XML Namespaces 1.0.

Один из изобретателей XML, Тим Брей, написал возражение по поводу готовящегося принятия пятой редакции XML 1.0:

http://lists.w3.org/Archives/Public/x...

Суть проблемы заключается в следующем. До пятой редакции стандарт XML 1.0 позволял использовать символы Unicode, принятого в 1998 году. Это означает, что символы, добавленные в более поздней версии Unicode, не могут быть использованы в названиях тагов и атрибутов XML 1.0 до пятой редакции. К таким символам относятся, например, буквы Амхарского языка и языка индейского племени Чероки. Пятая редакция XML 1.0 позволяет пользоваться любыми символами Unicode, добавленными после 1998 года. Однако текущий стандарт на XML Namespaces 1.0 всё ещё не позволяет этого.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

 ← 1 2 3 4 5 6 7 8 →
Ответ на: комментарий от anonymous

>што такое ИИ
http://www.cs.cf.ac.uk/Dave/AI2/node63.html
http://en.wikipedia.org/wiki/Frame_language
in short - concentration on connection of objects and their labels (+ behaviour) - to represent any knowlege

Многие имплементации, в том числе коммерческий ИБМовский фреймвок (названия нет под рукой - могу найти - они его используют для представления знаний) - имеют просто иерархический хеш-хешей как главная несущая структура.
В одном из слотов - кусочек поведения, соответствующего данному фрейму (это поведение обычо работает над локальными данными, зная только свою дату).
ОО языки - тоже фреймовые языки.

Но я привёл пример фреймов - как иллюстрацию что хеш-хешей - достаточная структура - для любой структурированной даты.

> Опять же што такое Крауфорд?

сорри: Douglas Crockford
кстати много интересных лекций по жава-скрипту в интернете

anonymous
()
Ответ на: комментарий от anonymous

>што такое ИИ

я дал ссылки на "што такое ИИ фреймы". А ИИ - искусственный интеллект, конечно же

anonymous
()
Ответ на: комментарий от r

> 229 байт XML против 273 байт JSON.

П_О_Л_Н_О_С_Т_Ь_Ю нечестно.

В JSON видимо считались специально добавленные ведущие пробелы в начале строк, так как закопипастив твои примеры я получил:

209 XML против 207 JSON

Еще в JSON надо убрать 2 лишние кавычки у цифры 100 -- тогда будет 205. Или вот вариант с табуляцией (см. следующий пост):

214 XML против 221 JSON

____________________________

По сути: то, что XML нерекурсивен в области атрибутов, т.е. мы не можем атрибуту сделать свои атрибуты или, как минимум, заменить 1 атрибут на несколько однотипных (массив из) атрибутов, ставит на XML жирный крест.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru 

XML=213 JSON=216 (tab=8*char)

<image width="800" height="600" title="View from 15th Floor">
        <thumbnail url="http://www.example.com/image/481989943" width="100" height="125"/>
        <id>116</id>
        <id>943</id>
        <id>234</id>
        <id>38793</id>
</image>
{
"Image":{
        "Width":800,
        "Height":600,
        "Title":"View from 15th Floor",
        "Thumbnail":{
                "Url":"http://www.example.com/image/481989943",
                "Height":125,
                "Width":100
                },
        "IDs":[116, 943, 234, 38793]
        }
}

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Разница с "214 XML против 221 JSON" образовалась из-за того, что в обоих случаях убрана ; нарушающая структуру и JSON первый раз был избыточно отформатирован.

XML=213 JSON=216

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

А еще предположим, что мы хотим сделать неограниченное число Title-ов на один имидж. Тогда:

XML потребует выноса Title-а из атрибута в отдельный тэг

JSON не потребует -- вместо 1-го Title-а будет стоять массив из них *на том же месте*.

Это обычно называют гибкость.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от r

>От верблюда:

><skipped/>

>gecko:

>object lookup:1063
>array lookup:146

>Разница на порядок.


Палишсо. Выбрось свой инструмент, возьми мой.

<html>
<body>
<script language=\"javascript1.5\" type=\"text/javascript\">
var a = {a: \"bbb\", k:1, x:\"xxx\"};
var d1 = new Date();
for (i=0; i < 1000000; i++) a.k = a.k + 1;
var d2 = new Date();
document.write(\"object lookup:\" + (d2 - d1) + \"<br>\");

var r = [];
r[\"a\"] = \"bbb\";
r[\"k\"] = 1;
r[\"x\"] = \"xxx\";
d1 = new Date();
for (i=0; i < 1000000; i++) r[\"k\"] = r[\"k\"] + 1;
d2 = new Date();
document.write(\"array lookup:\" + (d2 - d1));

</script>
</body>
</html>

firefox 3.0.4: object lookup:151 array lookup:161
opera 9: object lookup:172 array lookup:234
IE 7: object lookup:422 array lookup:422

Array lookup всегда дольше

anonymous
()
Ответ на: комментарий от stellar

>Никто не говорит, что DTD - это верх инженерной мысли.

Кроме DTD есть Relax NG

anonymous
()
Ответ на: комментарий от www_linux_org_ru

>Это обычно называют гибкость.

А воттеперь гибкий ты нашь закодируй в JSON строку в JS собственног говоря строку с произвольным количеством ' " \ И так далее. Ласково просимо.... Я часа 4 потраил на эту хрень. Больше не хочу там и \\ бывали и \"' и так далее

r не споль ты с этими идиотами, они обречены всю жизнь искать данные по смещению такому-то в их суперидеально сжатом формате...

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

anonymous
()
Ответ на: комментарий от anonymous

> Я погляжу когда в их хеше хешей в качестве клюа и значения будет использоваться JSON который в свою очередь будет хранить историю JSON запросов и ответов

какова проблема? можно иметь любую вложенность.

anonymous
()
Ответ на: комментарий от anonymous

>какова проблема? можно иметь любую вложенность.

Фигня, надо тоько \ } и прочую ерунду экранировать. Звуит легко, но вот только реализаций под туеву хучу ЯП мы никогда не увидим

anonymous
()
Ответ на: комментарий от GuttaLinux

>Ну и самое главное - нахрена вся эта лабуда 99% неэнтерпрайзнутого софта. Кстати, где шкала \\\"энтерпрайз / не энтерпрайз\\\"?

Ты пишешь на сайт, использующий на 99% технологии энтерпрайза. Resin, Java, JSP, html, http, PostgreSQL, memcached. Если бы мы ждали твою поделку 19 лет на бэйсике у нас до сих пор не было бы нашего ЛОРа. А если бы ты все таки допилил свое решение, то скорее всего сайт бы простаивал 6 дней из 7 из-за дыр в твоем движке, через которые резвились бы хакеры

Ты еще за 19 лет не понял, почему мир выбрал не бэйсик и паскаль, а энтерпрайз xml&java? Приходи сюда через 3 года, поймешь это. ЛОР все еще будет работать на jsp, я тебе гарантирую

anonymous
()
Ответ на: комментарий от anonymous

> Вы с какой Луны к нам прилетели?

с той, где возраст программиста в 34 года - считается слишком молодым - чтобы поручать проекты (не дадут разрешения наверху ввиду отсутствия должного опыта): слишком поздно пришёл в индустрию. Где работают деды-менфреймщики, которые работают с большими данными по 30 лет. Где базы многократно переживают аппликации, смены технологий. Но всё остаётся работать и работать надёжно с минимальными окнами. Где нет места хмлю (это - имхо) и люди знают униксы, пишут на борне и ksh/сsh а не баше, работая в vi а не vim'е (и помнят ед) и не используют фичи оракла позже 7.3. Где люди не разучились писать многоэтажные запросы прямо в sqlplus (или db2) и тут-же получать репорты из комманд-лайн. Где пишут на C под солярой, а теперь - всё больше в линуксе. И горюю когда попадаю в иную обстановку, что в последнее время чаще и чаще. А жаль.

anonymous
()
Ответ на: комментарий от r

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

Да нет, не насрать. =>Nehalem поддерживает SSE 4.2, то есть все инструкции, которые присутствовали у Penryn (SSE4.1) плюс ещё семь. Большинство инструкций связаны с обработкой строк символов, и одно из предназначений, по словам Intel, заключается в ускорении обработки XML-файлов http://www.thg.ru/cpu/intel_nehalem_theory/onepage.html

Последний компилятор Intel имеет оптимизации для работы с XML

anonymous
()
Ответ на: комментарий от GuttaLinux

>Потому что индустрия ещё дикая, и решают совершенно не те люди.

Везде решают некомпетентные нете люди. Какбэ почему? Даже в авиаперевозках. Поэтому самолеты и падают. Просто ошибки программистов не показывают в прайм-тайм в новостях, поэтому они не так заметны как ошибки пилотов и диспетчеров.

Karapuz ★★★★★
()
Ответ на: комментарий от GuttaLinux

А вот эта хератень у тебя

>�������������

это что?

Может твои нецензурные мысли?

> насколько бы плохо я не сделал - я всё равно изобрету НОВОЕ. И насколько хорошо бы ты не зазубрил - ты всегда будешь нести ЧТО-ТО СТАРОЕ

Родной, я не хочу ходить в сделанных тобой плохих сапогах, и не хочу пользоваться твоей плохой и кривой программой на бэйсике. Я лучше куплю сапоги старых ремесленников salamander и напишу свою хорошую прогу на xml

anonymous
()
Ответ на: комментарий от r

>Что бы не ляпнул - все для тебя новое, и сам себя чувствуешь на волне думая что новое в каждом твоем действии. Коллоссальный психологический самообман.

Что характерно, таких программистов - тучи. Я с одним таким рядом работаю, изобретает каждый день. Поколение было такое

anonymous
()
Ответ на: комментарий от stellar 

> Очевидно, что при большом количестве передаваемых параметров
процент оверхеда у XML будет снижаться.

Не снижаться, а повышаться! Сравним посимвольно:

<mytagname>12345</mytagname>
{"mytagname":12345}

myattribute="12345"
"myattribute"=12345,

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru 

причем в последнем случае, если после запятой не ставить пробел, то будет поровну (а XML пробел требует):

myattribute="12345"_
"myattribute"=12345,

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от anonymous

> Фигня, надо тоько \ } и прочую ерунду экранировать. Звуит легко, но вот только реализаций под туеву хучу ЯП мы никогда не увидим

Предлагается 10-й раз - не использовать JSON Крокфорда с его скобками, а использовать формат Васи, который гораздо более православен:

<html>
<body>
<script language="javascript"
type="text/javascript">
var vasya = {
panel1_label1:"xml_is_bad",
panel1_label2:"xml is slow",
panel1_label3:"xml is a danger for your eyes",
panel1_panel2_panel3:"I can do hierachies without problems too. My file is smaller and even redundant",
panel1_label4: "conserve energy - do not overload processor by unnecessary xml!",
//another set of properties:
prop1:"value1",
prop2:"value2",
frame:"1,2,3,4,5,6,7,8",
namespace_also_frame:"blah-blah-blah"
};

document.write(vasya.panel1_label1); document.write("<br>");
document.write(vasya.panel1_label3); document.write("<br>");
document.write(vasya.panel1_label2); document.write("<br>");
document.write(vasya.panel1_label4); document.write("<br>");
document.write(vasya.prop1); document.write("<br>");
document.write(vasya.prop2); document.write("<br>");
document.write(vasya.frame); document.write("<br>");
document.write(vasya.namespace_also_frame); document.write("<br>");
document.write(vasya.not_existing);

</script>
</body>
</html>

output:
------8<------
xml_is_bad
xml is a danger for your eyes
xml is slow
conserve energy - do not overload processor by unnecessary xml!
value1
value2
1,2,3,4,5,6,7,8
blah-blah-blah
undefined
------8<------

где та-же вложенность, но не скобками, а в ключах.
А данные из дерева вытаскиваются не хуже.
Смотри примеры с конфигами выше по треду

anonymous
()
Ответ на: комментарий от anonymous

ХМЛьщики, уловили связь с вашим XPath? Только абсолютно бесплатно.

А также не улавливаете связь с иерархическими базами данных, файловыми системами, семанитическими сетями и пр?

клади справа ID, ссылки на соседние фреймы, код в кавычках - "the sky is the limit" Это громадный шаг вперёд имхо (JSON - только пол-шага от ХМЛя)

anonymous
()
Ответ на: комментарий от anonymous

добавление если не заметно: ключи они не простые, "_" разделяет уровни.

Народ, Может кто-нить возьмётся написать описание (RFC или лучше - сайт, как у крокфорда)? чтобы народ не мучался с JSON. И тем-более - с ХМЛем.

Бросить туда линки на конфиги, примеров кучу, в разных языках, как использовать для передачи данных и пр.

anonymous
()
Ответ на: комментарий от anonymous

только просьба - ничего лишнего.

Если работает JSON - вышеприведённое должно работать лучше.

(я на C руле-енджин делал, - работал как часики с неимоверной скоростью. в ключи и правую часть вкладывали логику куча народа, а я знал логику-правила - как манипулировать ключами. Простые однообразные действия (правда много) - дало паразительные результаты, для меня неожиданные. По-мне это была настоящая семантическая сеть. Подход не должен умереть!)

У меня со временем не важно.

anonymous
()
Ответ на: комментарий от www_linux_org_ru

>Не снижаться, а повышаться! Сравним посимвольно:

Ну, давай, потролль дальше. Расскажи, что имя ключа у тебя минимум 80 символов, а длина значения - 2 - 3.

Как надоест троллить, возьми Google XML или RSS / Atom feed и посчитай процент верхеда в реальных условиях. Сравни с JSON, удивись результату.

После этого расскажи каким образом в случае с JSON ты будешь валидировать структуру переданых данных.

stellar ★
()
Ответ на: комментарий от Karapuz

>Везде решают некомпетентные нете люди. Какбэ почему?

Не догадываешься? Даю хинт: экономическая эффективность и скорость разработки важнее идеологической правильности.

stellar ★
()
Ответ на: комментарий от r

>Ай-ай-ай - и все XML. Ай-ай-ай как же это!

Я же писал, что XML - неизбежное зло, вот только лучше до сих пор ничего не придумали. А вот что такое SOAP - это сааафсем отдельный разговор.

stellar ★
()
Ответ на: комментарий от anonymous

>где та-же вложенность, но не скобками, а в ключах.

Отлично.

1) теперь посчитай процент оверхеда для большого документа.

2) и приведи экстракцию всего поддерева сразу

stellar ★
()
Ответ на: комментарий от anonymous

> Приходи сюда через 3 года, поймешь это. ЛОР все еще будет работать на jsp, я тебе гарантирую

Таки ЛОР сначала на пыхпыхе был написан. Так что примите незвиздин, батенька.

gaa ★★
()
Ответ на: комментарий от www_linux_org_ru

>В JSON видимо считались специально добавленные ведущие пробелы в начале строк, так как закопипастив твои примеры я получил:

Табы. Просто лор их схавал. Сравнивался pretty printed JSON vs pretty printed XML.

>Еще в JSON надо убрать 2 лишние кавычки у цифры 100 -- тогда будет 205.

Я его не рожал - это кусок из спеки - я только удостоверился в табуляциях.

>По сути: то, что XML нерекурсивен в области атрибутов, т.е. мы не можем атрибуту сделать свои атрибуты или, как минимум, заменить 1 атрибут на несколько однотипных (массив из) атрибутов, ставит на XML жирный крест.

Извини но в JSON атрибутов нет вообще, так что не смешите мои тапки. Все что может быть представлено JSON может быть представленно в XML меньшим или равным размером. Обратное не верно.

r ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>JSON ИМХО нагляднее.

Очень смешно. Особенно там где в ковычки все берется.

r ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> JSON не потребует -- вместо 1-го Title-а будет стоять массив из них *на том же месте*.

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

r ★★★★★
()
Ответ на: комментарий от anonymous

> Палишсо.

Это ты палишсо - какого хрена у тебя экраны на всех стрингах? Оно даже не заработает.

Ну значит в третьем фоксе оптимизировали.

r ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>Не снижаться, а повышаться! Сравним посимвольно:

Ох ну ты что тоже к этим смешным добавиться захотел?

Сравни посимвольно:

<image width="100"/>

и

{"image":{"width":100}}

Количество служебных символов в JSON больше. Каждый атрибут XML экономит 1 символ на числовом значении и 3 на строковом.

> myattribute="12345"
> "myattribute"=12345,


Правильно - а теперь сделай еще строковый атрибут - и ты все поймешь.

r ★★★★★
()
Ответ на: комментарий от anonymous

> где та-же вложенность, но не скобками, а в ключах.
> А данные из дерева вытаскиваются не хуже.

Мне с вас очень смешно знаете ли. Давайте вообще деревья отменим как структуру данных - все будем делать линейными ключами на хэшах.

r ★★★★★
()
Ответ на: комментарий от anonymous

>ХМЛьщики, уловили связь с вашим XPath? Только абсолютно бесплатно.

Я прямо наблюдаю гениальные возможности по поиску и ссылкам.

>А также не улавливаете связь с иерархическими базами данных, файловыми системами, семанитическими сетями и пр?

Улавливаем:

<x>
<y>
<z/>
</y>
</x>

плавным движенрием руки превращается в

x
x.y
x.y.z

ДУблирование информации просто потрясающеее. При больших значениях и глубоких иерарххиях - тебе надо нобелевскую премию дать за изобретение столь неэффективного решения.

r ★★★★★
()
Ответ на: комментарий от r

> Давайте вообще деревья отменим как структуру данных - все будем делать линейными ключами на хэшах.

Ага. И грепать по маске чтобы выцепить поддерево. Настоящий энтенпрайзъ.

stellar ★
()
Ответ на: комментарий от r

>Все что может быть представлено JSON может быть представленно в XML меньшим или равным размером. Обратное не верно.

Кроме набора вырожденных случаев вроде списка цифр. Но мы же о сложных структурах говорим?

r ★★★★★
()
Ответ на: комментарий от anonymous

> Resin, Java, JSP, html, http, PostgreSQL, memcached

именно поэтому в Links2 при попытке добавить - Java Exception, а в Dillo - шрифты?

> ждали твою поделку 19 лет на бэйсике у нас до сих пор не было бы нашего ЛОРа.

да, ��на два дня больше���������, зато без бд и прочих изорщённостей, и не падало бы по 5 раз на дню, и было бы прозрачное и совместимое

кто сломал мой аккаунт?����������������

anonymous
()
Ответ на: комментарий от stellar

> Не догадываешься? Даю хинт: экономическая эффективность и скорость разработки важнее идеологической правильности.

и зачём всё это в моём линаксе? уж линакс то был задуман то, чтобы всё было сделано ПРАВИЛЬНО�����

anonymous
()
Ответ на: комментарий от Karapuz

> Везде решают некомпетентные нете люди. Какбэ почему? Даже в авиаперевозках. Поэтому самолеты и падают. Просто ошибки программистов не показывают в прайм-тайм в новостях, поэтому они не так заметны как ошибки пилотов и диспетчеров.

пересказывать мне то, что я говорил двумя страницами���� ранее - это очень ����интересный способ вести дискуссию :)

anonymous
()
Ответ на: комментарий от Karapuz

> HTML/SGML изобретали зря?

HTML сейчас, и HTML по задумке - это совсем разные вещи

> когда все можно было сделать просто, по-текстовому,

когда я был дитём неразумным������������ и у меня был НТ4�������������������, я делал свой заменитель браузера, чтобы мгновенно работал даже на 8/16 mb. на визуалбейсике, с использованием глобальных и надёжных технологий PictureBox и .Print. Там и был простой текстовый формат.

Обрабатывался он быстро (вообще, стандартный парсинг небольшого текста везде обрабатывается быстро, главное - это не обрабатывать его встроенными в vb функциями), но удобство написания и работы - ТАКОЕ УГРЁБИЩЕ

так вот - должна быть прослойка "программист - формат быстрой разработки - формат обмена" - тогда всё глобально, надёжно и энтерпразнуто. Только XML не надо никому показыать.�������������

Кстати, основная НЕНАВИСТЬ к VB/Delphi - это ТОННА ЗАГРОМАЖДАЮЩИХСЯ КОМПОНЕНТОВ. Так вот, для меня любой доп. компонент, стандартный ли, нестандартный - это табу. Всё было на велосипедах, работало быстро. а цена любого велосипеда - вечер посидеть.�������������������������������������� И оно никогда нигде не тормозило.���

anonymous
()
Ответ на: комментарий от r

> Мне с вас очень смешно знаете ли. Давайте вообще деревья отменим как структуру данных - все будем делать линейными ключами на хэшах.

тормозите, господа. иерархические базы существовали задолго до ХМЛя. Файл-системой не пользуетесь? Они что - не иерархические что-ли? А как вы доступаетесь? Всегда описывая текущую директорию? Или всё-же удобнее - абсолютный путь? (Ведь он растёт всего-лишь логарифмически). Короче, не врубились вы. К сведению: вы слышали что многие используют берклиДБ (а не RDMS) - как хранилище рекордов и делают джойны в ключах. Это то-же - что я вам предлагаю. Создать ключи на лету - очень легко (конкатенация пары-тройки стрингов). Ноу-хау - под какими ключами хранить данные. Упрощенный пример:

книги=1,4,8 (или книга_1=1, книга_2=4, книга_3=8) ц=1,8,10 жаба=4

потом при запросе "книги ц" - делается быстрый джойн и получаем интерсект: книги по ц: "1,8"

это то - что делают поисковые движки и базы данных внутрях. С ассоциативными массивами - это натурально как ни с чем. А какой, интересно процессинг делаете вы с ХМЛем? (я могу показать что у меня в иерархической базе - всё очень масштабируемо и джойны невозможно сделать быстрее)

anonymous
()
Ответ на: комментарий от anonymous

кстати, статья Рейзера была неплоха - по поводу.

В ХМЛе вы делаете сплошные личние движения - даже если имплементируете подобное. С гигантским процессингом.

anonymous
()
Ответ на: комментарий от gaa

>Таких людей называют мудаками. Остальное из той же серии.

Вы сразу под многими системами работали? (типа одновременно и OS/390, AIX, солярка, linux), чтобы скрипт писать один раз и мочь его подправить не используя разные редакторы? везде и быстро. и данные проанализировать и подправить. Остальное из той же серии.

anonymous
()
Ответ на: комментарий от anonymous

не та статья по которой он был осуждён, разумеется :) та - что о семантических сетях vs RDBMS

anonymous
()
Ответ на: комментарий от anonymous

>>Не догадываешься? Даю хинт: экономическая эффективность и скорость разработки важнее идеологической правильности.

>и зачём всё это в моём линаксе? уж линакс то был задуман то, чтобы всё было сделано ПРАВИЛЬНО

Дружок, Линукс был задуман чтобы работал здесь и сейчас. ПРАВИЛЬНО - это самый последний аргумент. Потому у Linux и нет стабильного ядерного API, и шедулеры регулярно переписывают и т.п. Почему? Да потому, что решаются АКТУАЛЬНЫЕ СЕЙЧАС ЗАДАЧИ максимльно эффективным на данный момент образом.

Идеологически ПРАВИЛЬНО - это к HURD, но только где этот самый HURD значет 3.5 его разработчика.

>линакс

P.S. К логопеду, быдло!

stellar ★
()
Ответ на: комментарий от anonymous

>Вы сразу под многими системами работали? (типа одновременно и OS/390, AIX, солярка, linux), чтобы скрипт писать один раз и мочь его подправить не используя разные редакторы? везде и быстро. и данные проанализировать и подправить. Остальное из той же серии.

Я работаю регулярно с HP/UX, Solaris, FreeBSD и Linux. У меня шелл-скрипты написаны на борншелле.

Все работает. ЧЯДНТ?

stellar ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 5 6 7 8 →
Open Source