Игорь Васильев, я не знаю на чем ты программируешь. Но я-бы начал с алгоритмов и структур данных.
У тебя - граф ссылок. И тебе нужна структура данных такая как граф. И твой алгоритм - это твой парсер вики.
Условие останова - это некое насыщение графа которое ты сам определишь. Это будет эвристика.
Может по глубине связей от корневой странице. Может по количеству дубликатов вставок
за период. Например полседние 100 попыток вставить edge привели к повторам. Тогда
условно считаем что граф насыстился и больше вставлять нечего.
Это не алгоритм а скорее размышление как делать.
graph = new Graph();
while(parser.iterateLinks()) {
// Здесь from и to я предполагаю будут сами линки например
// https://en.wikipedia.org/wiki/Internet_Archive
// https://en.wikipedia.org/wiki/Brewster_Kahle
graph.addEdge(parser.from, parser.to);
// Вот. Внутри графа конечно желательно их хранить как-то сжато. И если
// Есть дополнительная информация типа Title то ее нужно положить в атрибуты графа.
// И здесь должна работать дедубликация Edges. Тоесть если такой Edge уже
// существовал то тогда мы его игнорируем
}
graph.exportToD3("output.json") // И тут мы граф сохраняем во внешнюю систему для красивого отображения
И чтобы отсечь всякие ненужные линки нужно ограничить набор доменов. Пускай граф например
коллектит только один сайт например en.wikipedia.org
С SOAP никто таким образом не работает. SOAP - это умный и сложный протокол. Надо найти
WSDL-файл. Потом сгенерировать API для клиента или для сервера. И потом его использовать.
Генераторов много. Под .net я могу не знать названий но SOAP-UI нормально справляется
с генерацией под разные языки разработки.
Alexzatey, я запутался. Мне нечего тебе сказать потому что в этой проблеме у нас по прежнему нет информации. Может кто из коллег в хабре понимает что происходит но я не понимаю.
Можно попробовать скачать apk одного из работающих шагомеров, дизассемблировать его и посмотреть
какие настройки он себе делает. Скорее всего есть какое-то свойство устанавливается.
Mokey, в науке и технике ... в частности в ООП есть всего два способа правильного
расширения функционала ООП.
Первое - это наследование. Второе - это композиция.
Готов спорить что 99% ты попадаешь в один из этих кейсов. Третий вариант когда ты просто
написал какую-то частную библиотеку которая работает похожим образом но в этом
случае ты просто выпадаешь из парадигмы ООП.
Что там про враппер говорил? Давай исходник своего враппера сюда.
RimMirK, вложенный запрос или join - это просто синтаксический сахар. В реальности надо смотреть какой execution plan выбирает оптимизатор для SQL машины. Может так быть что план будет одинаков (по топологии) для обоих видов синтаксиса.
Обязательно нужно согласовать твою активность с теми людьми которые платят деньги. В большинстве случаев они не против самообразования. И даже выделяют деньги на курсы и сертификации.
Но если ты будешь тихушничать и заниматься чем-то непонятным - тебе придется объясняться.
Здесь мы конкретно запрашиваем сервисы imap. А если допустим я хочу обратиться к домену netflix.com и спросить у него какие сервисы онлайн трансляции видео он имеет? Я наперед еще не знаю эту спецификацию? Может rtsp? Может еще что-то.
У тебя - граф ссылок. И тебе нужна структура данных такая как граф. И твой алгоритм - это твой парсер вики.
Условие останова - это некое насыщение графа которое ты сам определишь. Это будет эвристика.
Может по глубине связей от корневой странице. Может по количеству дубликатов вставок
за период. Например полседние 100 попыток вставить edge привели к повторам. Тогда
условно считаем что граф насыстился и больше вставлять нечего.
Это не алгоритм а скорее размышление как делать.
И чтобы отсечь всякие ненужные линки нужно ограничить набор доменов. Пускай граф например
коллектит только один сайт например en.wikipedia.org