Хочу подтолкнуть спонсоров на создание нового формата XML ек

Параметры к интерфейсу передаются через GET или POST.

categories:
- Нет параметров, тупо список категорий. Сортировка по титлу ASC.

products:
- Дефолтная сортировка - по дате добавления. Самые новые наверху. А-ля РСС.
- При отсутствии параметров, генерируется ошибка.
- "limit" - обязательный целый параметр, означающий лимит одаваемого количества продуктов. Сервер вправе установить свой хард-лимит, выше которого это число быть не может.
- "category_id" - необязательный параметр, означающий взять продукты только определенной праймари категории. Здесь идентификатор категории.
- "product_id" - выдать только информацию по конкретному продукту с указанным идентификатором.
- "shuffle" - true. При наличии этого параметра, продукты выдаются в случайном порядке.

fhm:
- Дефолтная сортировка - по дате добавления. Самые новые наверху. А-ля РСС.
- При отсутствии параметров, генерируется ошибка.
- "limit" - обязательный целый параметр, означающий лимит одаваемого количества FHM. Сервер вправе установить свой хард-лимит, выше которого это число быть не может.
- "package_id" - обязательный параметр с идентификатором тарифного плана (package) для которого использовать ссылки
- "link_type" - [main|join|tour|any] - необязательный параметр, означающий куда будут вести ссылки. При его отсуствии решение принимается произвольно сервером. При отсутствии такого типа ссылок, ссылка выбирается произвольно сервером из заданного package_id.
- "nocons" - true. При наличии этого поля сервер обязан предоставить console-free ссылки. Иначе произвольно по выбору сервера.
- "category_id" - необязательный параметр, означающий взять FHM продуктов только определенной праймари категории. Здесь идентификатор категории.
- "fhm_type" - необязательный параметр. жестко ограничить тип отдаваемых FHM. Значения: [picture|movie|text|mixed]
- "product_id" - выдать только FHM по конкретному продукту с указанным идентификатором.
- "unique_content" - true. При указании этого параметра, FHM с дублированным контентом не будут выдаваться. По умолчанию этот ньюанс не регламентируется.
- "shuffle" - true. При наличии этого параметра, FHM выдаются в случайном порядке.
- "notitles" - true. При наличии параметра сервер не будет отдавать <titles> даже если они есть
- "nothumbs" - true. При наличии параметра сервер не будет отдавать <thumbnails> даже если они есть.

Последний раз редактировалось: Pentarh (27/06/07 в 12:18), всего редактировалось 1 раз

Формат выдачи ошибки

http://pentarh.com/misc/error.xml

Но в принципе ошибку можно отдавать и по хттп ответу.

Stek писал:

Pentarh: все что ты написал - заябись для крупняка, мелким адверам от этого ничего не светит, у них нет ресурсов начать использовать такое в полную мощь.

Мелкие адверты пользуются "крупным софтом", в смысле не своим, как правило. А тема как раз для разработчиков такого софта ...

P.S. Ух ты, как тема разрослась Я не читал форум несколько дней. Сейчас буду читать и тоже отвечать. Я очень рад, что дискуссия началась

Pentarh писал:

Параметры к интерфейсу передаются через GET или POST...

и тут остапа понесло (С). Если у нас элементарный доступ к данным с аутентификацией, то зачем наворачивать лишнюю логику?

ghood писал:

и тут остапа понесло (С). Если у нас элементарный доступ к данным с аутентификацией, то зачем наворачивать лишнюю логику?

Блять, предложи другой вариант да?

http://domain.com/get_fhg.php?limit=20&category_id=anal

Чем тебе не нравится?

Может тебе SOAP захуячить? Или может ты предложишь более простой метод передачи параметров чем HTTP GET?

Pentarh писал:

Блять, предложи другой вариант да?

неадекват моде он?

Pentarh писал:

http://domain.com/get_fhg.php?limit=20&category_id=anal Чем тебе не нравится? Может тебе SOAP захуячить? Или может ты предложишь более простой метод передачи параметров чем HTTP GET?

Предложу вообще не передавать параметры, либо передавать их абсолютный минимум, поскольку тут прослеживается попытка заменить структурность данных логикой, что ИМХО может серьёзно усложнить жизнь.

И вообще релакс, я так просто попесдеть пришёл

Да, меня седня целый день неадекваты достают.

Цитата:

Предложу вообще не передавать параметры, либо передавать их абсолютный минимум, поскольку тут прослеживается попытка заменить структурность данных логикой, что ИМХО может серьёзно усложнить жизнь.

Не хочешь передавать параметры, на тебе минимум параметров:

Взять 20 последних ФХГ:
http://domain.com/get_fhg.php?limit=20

Кто хочет что то кастомное, передаст больше параметров:

Взять 20 ФХГ из ниши anal:
http://domain.com/get_fhg.php?limit=20&category_id=anal

Взять 20 ФХГ платника amandastory:
http://domain.com/get_fhg.php?limit=20&product_id=amandastory

Взять 20 мувисных галер из ниши анал:
http://domain.com/get_fhg.php?limit=20&category_id=anal&fhm_type=movie

Тоже самое, только безконсольные линки:
http://domain.com/get_fhg.php?limit=20&category_id=anal&fhm_type=movie&nocons=true

И так дальше в зависимости от фантазии.

Pentarh писал:

Параметры к интерфейсу передаются через GET или POST. categories: - Нет параметров, тупо список категорий. Сортировка по титлу ASC. ...

2 Pentarh
Извиняюсь, заранее, если буду где допускать неточности, так как топик тока сейчас начал читать после перерыва.
Я так понял, инициатива создания конкретного XML формата сейчас в твоих руках
Хотел бы предложить только не усложнять количество GET параметров для потенциального стандарта. Сложность и большая реализация могут оттолкнуть разработчиков партнерок от реализации этого вида стандарта. А именно - мне думается, не надо придумывать много параметров для фильтров выдачи фида. По идее, пусть фид сам имеет всю инфу, а проги адвертов пусть сами выколупывают УРЛы галлер с консолями и без, с titles и без и т.п.. В конце концов, можно даже создать модули фильтры для выколупывания и отджельно предлагать их как решение. Вот какие недостатки может повлечь за собой фильтрование на стороне партнерки

С фильтрами через предложенные тобой GET параметры:

1) Сервер вынужден будет делать разные очереди SQL или не SQL, если партнерка имеет другую базу, что увеличит время отработки запроса к фиду, и как следствие, может возникнуть "снежный" ком, когда сервак просто не будет успевать отрабатывать запросы и запросы просто завалят сервак

2) Усложнение программирования для партнерки

3) У некоторых могут быть просто FHG одного типа, а стандарт будет вынуждать их реализовывать обработку таких параметров

Без фильтрования и без опций для GET запросов плюсы такие

1) Партнерка может положить один единственный файл, например. Кстати, пришла в голову мысль, что для формата можно придумать указание где куда вставлять реф вебмастера. Тогда софт адвертский будет получать один единственный для всех файл FHG и сам генерить УРЛы галлер на основе выдачи. Если даже и не делать этого (одни УРЛы для всех с указанием где вставлять реф), то все равно, партнерке легче перед выдачей просто самой заменять ключевое слово на реф и выдавать готовый фид на основе одного файла

2) Можно придумать тогда стандарт с gzip-ным форматом. Это резко снизит нагрузку на сервак партнерки, так как выдача будет быстрее (зипованный вариант будет в 4-5 легче, это точно), лучше будет адвертам IMHO. Также, чтобы партнерке делать раз в сутки одни XML файлы для всех, можно подумать над форматом где бы в фиде были не конкретные УРЛы галлер для каждого адверта, а УРЛы с указанием, куда будет вставляться реф код. Тут есть вопросы с NATs-ом, но я точно знаю, что первые пять символов кодированного рефа как правило всегда везде одни, а остальные, я догадываюсь, просто random символы типа программы, консоль или нет и т.п.. То есть мои догадки есть в том, что для всех адвертов NATs-а кодированные рефы можно разбить на куски: кодированный реф адверта (для всех разный) + часть для всех единая типа программы + единая часть еще чего либо (тут надо знать NATs ...)

Я пока не читал всех предложений по формату, что предложил Pentarh. Чуть позже еще отвечу.

Сорри за опечатки, писал быстро и не проверял что написал

Perlover писал:

2 Pentarh Извиняюсь, заранее, если буду где допускать неточности, так как топик тока сейчас начал читать после перерыва. Я так понял, инициатива создания конкретного XML формата сейчас в твоих руках

Так уж получилось, сам теперь не рад )

Perlover писал:

По идее, пусть фид сам имеет всю инфу, а проги адвертов пусть сами выколупывают УРЛы галлер с консолями и без, с titles и без и т.п..

Нет, ребята. Чувствуется что не писали вы такие вещи.
Ты и ghood понимаете вообще что галер у спонсора может быть тысячи и десятки тысяч? Ты предлагаешь отдавать это в многомегабайтном фиде?
Чего будет стоить только поменять везде рефы в этом фиде для одного человека? Это будет намного более ресурсоемко.
А ты представляешь сколько ресурсов нужно чтобы распарсить это на клиентской стороне? В результате страдают и сервер и клиент.

Я же предлагаю классическое решение "Толстый сервер - тонкий клиент". Делаешь запрос - отдается инфа немного и по теме.

GZIP вообще отпадает. В твоем варианте это будет так:
- Заменить рефы в многомегабайтном XML
- Зазиповать
- Отдать клиенту

Клиент:
- Раззиповать
- Распарсить (тут дефолтного memory_limit 8 Mb в ПХП аж никак не хватит, я уже не говорю про max_execution_time)

Не, в морг.

Perlover писал:

1) Сервер вынужден будет делать разные очереди SQL или не SQL, если партнерка имеет другую базу, что увеличит время отработки запроса к фиду, и как следствие, может возникнуть "снежный" ком, когда сервак просто не будет успевать отрабатывать запросы и запросы просто завалят сервак

Да будет тебе известно что SQL обработка (грамотная) куда более проще для сервера чем то, что предлагаешь ты.
В связке с кешированием запросов, это не должно дать ощутимую нагрузку.
Если партнерка не имеет SQL базы под это дело, мои искренние соболезнования. Мы живем в 21 веке по моему, где даже Personal Home Page имеет базу свою.
Насчет завалят сервак - ты точно не знаешь о чем говоришь. Если все стоит правильно и у программеров прямые руки, сервак не завалится.

Perlover писал:

2) Усложнение программирования для партнерки

Я бы вообще послушал бы на этот счет мнение товарища dm
Он разработчик софта партнерок. Как на меня так это не более двух-семи дней ебатни.

Perlover писал:

3) У некоторых могут быть просто FHG одного типа, а стандарт будет вынуждать их реализовывать обработку таких параметров

Ну вот началось. А зачем мы тогда вообще это замутили? Давай пусть все выдают как могут и закроем этот топег.

Perlover писал:

Без фильтрования и без опций для GET запросов плюсы такие ....

Не вижу ни одного плюса. Да, програмать такое это вечер посидеть. Но для сервера и клиента это неописуемый гимор и ресурсоемкость.

Вообще у меня складывается впечатление что все это медвежий труд.

Здесь можно услышать хоть одно компетентное мнение?

dm ты где вообще? Поспрашивал и ушел в сумрак

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

Цитата:

Нет, ребята. Чувствуется что не писали вы такие вещи. Ты и ghood понимаете вообще что галер у спонсора может быть тысячи и десятки тысяч? Ты предлагаешь отдавать это в многомегабайтном фиде?

Ты не кипятись
Я писал другие вещи правда. У меня в базе своей более 430 спонсов забито и галлер за 700k. Про получение галлер от спонсов я слышал не по наслышке.
Я объясню почему я хочу именно разгрузить сервер
Ну во первых, инициатива идут с низу, то есть от адвертов, от нас как бы. И чтобы спонсы пошли на это, им надо предложить такой вариант, чтобы они хоть как то стартанули для нового формата. Это раз. Во вторых, много спонсов, которые не имеют баз, к примеру, но хотелось бы чтобы они тоже имели такой экспорт. Например, полно спонсов под CCBill, которые имеют на одной странице все галлеры. Ну уж точно не будут писать PHP скрипт, который должен адекватно работать на 10 разных запросов. Но они смогут (им можно помочь даже простым JavaScript расширением) создать фид простейший, по "стандарту", пусть без десков, но это будет один файлик. Про мегабайтные файлики я напишу ниже. Например, что мешает таким спонсам дать УРЛ настраничку, которая через JavaScript конвертнет их список УРЛов в XML и выдаст в textarea области и они просто скопируют и обновят у себя файлик экспорта на новый?

Про тысячи галлер. А что мешает в стандарте сделать так: вот вам файлик наших сайтов (ты пример уже давал), а там, прямо в файле пейсайтов, предусмотреть либо 1) XML элементы содержащие УРЛы откуда брать галлеры для каждого сайта; 2) либо прямо там в файле пейсайтов предусмотреть другие XML элементы для описания галлер прямо внутри того файла

Я это предлагаю потому, что спонсоров с 10k галлерами так же много, но еще больше спонсов, у которых 100-400 галлерей, и по любому, надо в формате предусмотреть однофайловую выдачу и многофайловую. Но чтобы выбор был. Ну не будет спонс со 400 галлерами и двумя пейсатами наверное делать вариант, где есть 10 параметров GET запросов. У такого спонса обычно один тип программы и даже нет выбора - есть конcоли или нет.

Цитата:

Чего будет стоить только поменять везде рефы в этом фиде для одного человека? Это будет намного более ресурсоемко. А ты представляешь сколько ресурсов нужно чтобы распарсить это на клиентской стороне? В результате страдают и сервер и клиент.

А чего ресурсоемкого? Например атрибут в элементе XML выдачи referer_replace_what="YOUR_CCBILL_HERE", а далее УРЛы типа http://foo.com/1/?id=YOUR_CCBILL_HERE и т.п.. То есть простая автозамена нужна на стороне клиента. Чего сложного? Зато спонс с 400-тами галлерами положит файлик статический и все! И нам и ему хорошо! Но можно ведь предусмотреть, что если нет аттрибута в таге XML referer_replace_what, то софт адверта считает что заменять не надо - там есть реф. И ресурсов вовсе не много...

Цитата:

Я же предлагаю классическое решение "Толстый сервер - тонкий клиент". Делаешь запрос - отдается инфа немного и по теме.

Я понимаю, но надо учитывать что 70% спонсов с галлерами может быть меньше 1000. См. мои аргументы выше

Про GZip - я предлагал просто как вариант. Не против и без него.

Цитата:

- Заменить рефы в многомегабайтном XML - Зазиповать - Отдать клиенту

Когда я писал про gzip, я подразумевал статичный вариант, а не динамический. Вообщем возникло недоразумение. Предлагаю пока о GZip вообще не говорить. Забудем о нем

И повторюсь - я предлагаю сделать такой стандарт, который бы подразумевал как один файл экспорта, так и файл, где с помощью тагов даются указания брать для каждого платника по такому то УРЛу файлик XML с галлерами. А парсере это сделать не сложно - встретился нам таг-указание взять галлеры по УРЛу - просто берем, а потом парсим те ми же методами, так как таги будут теже что встроенные галлеры, что внешний файл. Я бы кинул пример, но в данный момент не могу, позже, завтра может быть.

Цитата:

Если партнерка не имеет SQL базы под это дело, мои искренние соболезнования. Мы живем в 21 веке по моему, где даже Personal Home Page имеет базу свою.

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

Цитата:

Насчет завалят сервак - ты точно не знаешь о чем говоришь. Если все стоит правильно и у программеров прямые руки, сервак не завалится.

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

Цитата:

Ну вот началось. А зачем мы тогда вообще это замутили? Давай пусть все выдают как могут и закроем этот топег.

Зачем сразу такие крайности?

Цитата:

Не вижу ни одного плюса. Да, програмать такое это вечер посидеть. Но для сервера и клиента это неописуемый гимор и ресурсоемкость.

Ну может кто другой увидит. В понедельник послушаем еще dm-a Ну и хотелось бы услышать мнение других программеров

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

Короче делаю вывод.

Надо просто создать свойство "support_queries=[true|false]" тега amap. Если false, то это статический фид и параметры он не поддерживает.

Также свойство replace_affid=[true|false] и свойство affid_anchor="REPLACE_YOUR_ID" (если replace_affid=true)

Тебе нужен хот-старт?

dm, сколько партнерок пользуются твоим скриптом?

Немного своих предложений еще

Цитата:

http://pentarh.com/misc/products.xml

Предлагаю 'id' аттрибут переименовать, иначе возникнут конфликты с DOM1 или DOM2, гда такой аттрибут считается как id of nodes и должен быть уникальным для документа и несет совсем другую смысловую нагрузку. Особенно, может быть id повторятся /amap/membershipinfo/package и /amap/product, потому как у спонса id для платника может совпадать с id of membershipinfo (какие нибудь парсеры XML могут выдавать конфликт что id нескольких нодов совпадает, что не есть правильно для спецификации DOM и т.п..)

Также не понятно немного, надо ли этот id? Например, когда выдается платник, у него есть prime_category аттрибут с id и отдельно есть categories.xml. Предлагаю упростить - пусть у платника будут categories как список текстовых категорий, через запятую, которые по стандарту должны быть из стандартных имен (Пример: <product id="[unique_product_id]" categories="amateur,anal,butts,hardcore" url="[product_primary_url]" join_free="[true|false]" join_pay="[true|false]" join_trial="[true|false]">). Например anal есть анал, если кто-то зовет AssFucking - пусть юзают слово anal.
Если ксму то нужна primary, пусть она будет всегда считаться первой в списке. Хотя лично я, как адверт, предпочту вообще не смотреть в categories, а лично расставлять ниши для всех платников. Потому что: 1) много спонсов ставят не те ниши, лишь бы попасть в как можно большие категории и этим будут злоупотреблять, стопудово; 2) если я буду надеятся тока на указанные спонсом ниши, я не смогу промоутить грамотно, так как мои сайты забъются не правильно рассортированными галлерами и пипец продуктивности и т.п.. Я много видел спонсов, которые имеют натуральных милфов, а преподают это как тиновые сайты ... Вообщем категории скорее всего для ленивых и ленивого софта - то есть может будут ТГП скрипты, которые автоматом будут предлагать все раскидать на основе этой инфы. Но вот кто этим захочет воспользоваться - вопрос большой.

Возникли вопросы про http://pentarh.com/misc/fhg.xml
А именно не совсем понятен смысл аттрибутов product_id="[product id]" product_title="[product title" product_url="[product url]" product_aff_url="[default product affid url]" category_id="[primary category id]" content_id="[content ID]" тага <fhm>
Если это привязка галлеры в платнику, то логичнее и проще не дублировать инфу платника в каждой галлере, <fhm> заключить в таг например <parent_product>:
<parent_product><fhm>...</fhm><fhm>...</fhm></parent_product>
или второй вариант
<fhm_list product_id="ID_платника"><fhm>...</fhm><fhm>...</fhm></fhm_list> и убрать инфу о платнике из каждой галлеры.

Также предложение везде ID считать строчным названием, не цифрой, например, в качестве ID может выступать домен платника, например, или даже строка "Super Fucking Girls". Цель - чтобы было читабельно. Потому как если это будут цифры, просто будет плохочитабельно

Pentarh писал:

Надо просто создать свойство "support_queries=[true|false]" тега amap. Если false, то это статический фид и параметры он не поддерживает. Также свойство replace_affid=[true|false] и свойство affid_anchor="REPLACE_YOUR_ID" (если replace_affid=true)

Согласен

Еще предложения
Что еще пришло в голову

1) fhm: type="[picture|movie|text|mixed]" - добавить еще тип undef. Объясню. Будут стопудово спонсы, что не захотят прописывать тип, так как у них галлеры сейчас все в куче и для них это будет ручная работа. Результат - они пропишут там фуфло. Лучше уж пусть пишут undef тип, тогда адвертский софт будет знать, что надо самому ему определить тип. Хотя лично по себе скажу - у меня парсер галлеры сам определяет мувисная или пиксовая галлера или mixed. И скорее у большинства так же. Верить этой инфе выданной спонсором не очень хочется, так как если верить, а они если не правильно пропишут, то будет много мусора. А любому адверту этого не хочется.

2) Когда ты придумывал fhm, предполагал ли ты там сделать не тока FHG тип, а FHS (free hosted site - фришник), баннер? Если тока fhg, то может и назвать fhg?

3) Что надо точно сделать - сдать аттрибут времени последнего обновления FHGs для платника. То есть смысл в том, чтобы обратившись к products.xml, мы бы знали, где следует запрашивать новые FHGs, а где нет. Дату и время можно делать например формата "2007-01-30 12:12:12 +04:00" или время в секундах от функции time() в Си или посмотреть, как в HTTP & RSS протоколах оно определяется. Сравниваем со своим временем, если не совпадаем, обновляем и заносим к себе в память и т.д..

4) Поскольку для каждого платника будет свой набор FHGs, и чтобы разбить на части FHG куски для каждого платника, предлагаю в products.xml сделать элемент (таг) типа <product>...<package ..> ...<tools><fhgs><list src="list1.xml" /><list src="list2.xml" /><list><fhg>...</fhg><fhg>...</fhg><fhg>...</fhg></list></fhgs></tools>...</package>...</product>

Здесь в примере:
а) все FHGs находятся под секцией <fhgs>;
б) <tools> & <fhgs> находятся в ветке <package>, то есть идеальная привязка к тому, что галлеры привязываются к тому, какой тип мемберки они рекламят (например триал есть или нет, тип тура и т.п.., как обычно и есть у спонсов в NATs, например)
в) В <tools> потом можно будет поместить секцию <fhs>, например
г) В примере два вида подкачки FHGs: либо пустой елемент list с аттрибутом src (относительный) - говорит софту пойти туда и там взять список (сам же формат файла list1.xml и т.п.. аналогичен тому что под элементом <list> не пустым с корневым элементом list); либо элемент <list> внутри себя имеет FHGs. Кол-во list элементов может быть один или более, сделано для универсальности

5) Как уже предлагал, предлагаю отказаться от categories.xml - я лично не вижу в нем смысла. Как ранее предлагал - разделять категории через запятую, тут я хочу поправиться - пусть будут в products.xml как <category name="anal"/><category id="hardcore"/><category id="amateur"/>, например. Список категорий надо по идее стандартизировать.

6) Ну и как предлагал, надо аттрибут id переименовать в другой, чтобы не было конфликтов со стандартом DOM, CSS...

Пока вот порция очередных предложений для Pentarh.
Pentarh, внесешь изменения в свои мастер-примеры?

Ага, стану трезвым, обязательно внесу

Еще дополнение к формату галлерей

1) Для элемента <fhg> внутри него надо сделать опционально один или несколько пустых элементов <model> с аттрибутами имени модели, например
<fhg> ... <model name="Alice"/><model name="Mia"/></fhg><fhg> ... <model name="Mia"/></fhg>
Так как есть спонсы которые выдают такую привязку, а для адвертов, работающих с Single girl будет очень полезна. (пример спонса - Nubiles - сайт один, а галлеры привязаны так же к именам девчонок)

1a) Такой же элемент <model name="Name_of_Model"/> нужен в секции <product>, ну вообщем для платника.

Потому как есть разделения по моделям на уровне отдельных галлер (могут быть в галлере несколько моделей, поэтому может быть несколько быть <model> для сайта или галлеры), так и на уровне сайта. По идее, если сайт имеет <model> и внутри галлеры имеют <model>, то <model> для галлеры переопределяет привязку модели от сайта. Например, сайт Жанны, а жанна типа поместила галлеру Леры. Если Лера с Жанной, то галлера имеет два <model> тага (элементы и таги - один смысл, просто в жаргоне XML говорю ).

2) Элемент <fhg> должен иметь опциональный аттрибут nude="[true|false]". Если true - значит есть обнаженка, и наоборот. Это часто встречается в сайтах где один сайт - одна модель.

3) Надо бы сделать привязки к шаблонам для галлерей. Мое предложение, чтобы не дублировать для каждой галлеры, из какого она шаблона, сделать так:
<fhgs><list><template name="t1"><fhg>...</fhg> ...</template><template name="t2"><fhg>...</fhg>...</template></list>
Если сайт не имеет шаблонов, то пусть <template> остается но не имеет скажем аттрибута name="" и имеет тока одну ветку <template>. Это для упрощения

Блин столько понаписано... делаем как раз фид для фхг. Как сделать то? Ткните носом в пример!

В понедельник все будет. А вообще программерам линку дай на этот топег.

- Поддерживаю идеологию "Толстый клиент - тонкий сервер"
Ориентироватся надо в первую очередь на партнерки которые пользуются готовым софтом - nats, dm, все равно реалтзовывать это будет не спонсор, им надо будет только включить поддержку фичи. А когда стандарт войдет в работу крупняк уж сам озаботится по поддержке.

- Передача реф-кода:
я предполагал что фид будет под паролем вебмастера, поэтому логично чтобы fhg отдавались с кодом, причем сразу с нужным (консоли, pps/revshare). Исключение составляют ccbil партнерки, тут уже в парсере должна быть настройка какой параметр (CCBILID) заменять на код вебмастера.

dm писал:

в понедельник обещаю выложить в этот топик урл для тестов и дальнейшей критики/обсуждения

http://demo.awm-scripts.com/partners/xmlexport.cgi
demo:demo
Просьба учитывать, что самая первая проба и пока только FHG

Какие параметры понимает и что добавил / изменил в процессе написания :

* http://pentarh.com/misc/categories.xml
Подумав, от экспорта категорий отказался вообще
Описание само себе категория, дополнительный ID вводить незачем, что есть на партнерке элементарно из списка платников (products) выдернуть

* http://pentarh.com/misc/products.xml
http://demo.awm-scripts.com/partners/xmlexport.cgi?req=products

Оставлены только основные атрибуты в product и package
currency и остальное должно описываться опциональными элементами - на этот счет есть вполне общепринятые умолчания, в обязательные атрибуты их вносить по моему не следует
Относительно link type="[main|join|tour|any]" и nocons="[true|false]"- тут сложнее; вроде любые скрипты партнерок дают этим управлять через параметры в урле, в моем тоже есть коды для отсылки на любую страницу тура или сразу джойн и для управления консолями - но если сгенерить все возможные варианты, будет паре десятков урлов для каждого сайта..
Пока ограничился main + join и добавил <tours> - это надо обсудить

* http://pentarh.com/misc/fhg.xml
http://demo.awm-scripts.com/partners/xmlexport.cgi?req=fhg

Так же много убрано из атрибутов в элементы
req= - тип запрашиваемых промо; скажем еще fhs, descs, banners
&type= - подтип, для FHG pics/video, для банеров - вертикальные, горизонтальные, размеры; etc
для получения списка - служебное list
http://demo.awm-scripts.com/partners/xmlexport.cgi?req=fhg&type=list
Дополнительные параметры :
&limit= - тут понятно, в сочетании с <added> можно проверять появление новых
&type= - ограничение по типу
&product= - по сайту
Пока все
Как этот экспорт соотносится с тем что в админках овнеру и вебмастерами видно - http://awm-scripts.com/tiki-index.php?page=demo

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

ммм.. критикуйте вообщем

Pentarh писал:

dm, сколько партнерок пользуются твоим скриптом?

Ну, если верить http://natssponsors.com - вполовину меньше чем NATS'ом
Полсотни плюс-минус 2-3, кто-то закрывается, одна-две почти всегда в настройке есть и пока не спамились

Сори ребята, я сливаюсь, работы пиздец просто.

а какой смысл выдавать к примеру баннеры по xml?

просто галеры понятно допустим приятно автоматом получать в свой ресурс ну там в тгп какую сидж
тексты в бля блог наконец

ну баннера то бля
цтр у них может разнится в 3 раза
вот выберет тебе автоматом говнобаннер и чего?
чего в этом хорошего?