Программирование

есть такая херня - xmldocument

и если считать и пересохранить файл xmldoc.save

он сам всё разобьет

всё это очень здорово, но на главные вопросы ты так и не ответил.

зачем читать документ построчно, а не считать его целиком в строку? что делать с прочитанными данными? как они превратятся в объекты?

Аттачи можно прикреплять в GET

по моему так

?media=photo25545_523232,video254562_566235,http://pd.com

прилепит картинку, видео и ссылку

А на жс json в приоритете потому что json имеет такую же структуру как запросы жс, т.е. сам жс это и есть json.

А скорость жс работы с xml и json я в свое время сверял.

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

для жаваскрипта то понятно правильнее использовать жсон

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

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

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

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

2пой соснул

Сэр, Вы ошиблись разделом

http://prodota.ru/fo....php?showuser=1

ну вы поняли да?

 

 

 

 

Сколько тебе заплатили за это?

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

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

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

Как описывается массив объектов в xml и json? А когда этих объектов будет сотня? А тысяча? Там нормальный оверхед накопится. На маленьких объёмах конечно не критично.

Поцоны укого есть бруд?

Тут такая тема есть: http://prodota.tv

Хотя даже сниффер подойдет

Поцоны укого есть бруд?

Тут такая тема есть: http://prodota.tv

Хотя даже сниффер подойдет

Пробоавл что-нибудь типа

admin 1234

juse juse

juse luchsevseh

juse 20.02.1994

?

Как описывается массив объектов в xml и json? А когда этих объектов будет сотня? А тысяча? Там нормальный оверхед накопится. На маленьких объёмах конечно не критично.

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

конечно если представить какой-то сферический случай в вакууме - то всё действительно критично для пользователя.

если ты разрабатываешь само апи, а не клиент для апи - то возможно тоже критично, а вот если ты разрабатываешь клиент - то все эти доводы полный бред. медиафайлы будут кушать в разы больше, чем самый раздутый xml

Поцоны укого есть бруд?

Тут такая тема есть: http://prodota.tv

Хотя даже сниффер подойдет

Пробоавл что-нибудь типа

admin 1234

juse juse

juse luchsevseh

juse 20.02.1994

?

первое пробывал

Как описывается массив объектов в xml и json? А когда этих объектов будет сотня? А тысяча? Там нормальный оверхед накопится. На маленьких объёмах конечно не критично.

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

конечно если представить какой-то сферический случай в вакууме - то всё действительно критично для пользователя.

если ты разрабатываешь само апи, а не клиент для апи - то возможно тоже критично, а вот если ты разрабатываешь клиент - то все эти доводы полный бред. медиафайлы будут кушать в разы больше, чем самый раздутый xml

Мне для альбома приходится парсить 200кб пикасовской json'ки и это только 150-200 фотографий. Боюсь представить что будет с xml.

 

Поцоны укого есть бруд?

Тут такая тема есть: http://prodota.tv

Хотя даже сниффер подойдет

Пробоавл что-нибудь типа

admin 1234

juse juse

juse luchsevseh

juse 20.02.1994

?

первое пробывал

а они умнее чем кажутся

Мне для альбома приходится парсить 200кб пикасовской json'ки и это только 150-200 фотографий. Боюсь представить что будет с xml.

 

будет примерно 300 кб. обрати внимание, что вслед за 200 кб текста тебе придется грузить медиафайлы гораздо большего размера

ты кстати можешь дать мне ссылку на этот альбом и мы проверим какой он дает ответ по размеру

А какой тип авторизации? HTTP простйо же?

Мой брут делает 178 слов в секунду

Мой брут делает 178 слов в секунду

Сейчас еще и этот сервак ляжет

есть такая херня - xmldocument

и если считать и пересохранить файл xmldoc.save

он сам всё разобьет

всё это очень здорово, но на главные вопросы ты так и не ответил.

зачем читать документ построчно, а не считать его целиком в строку? что делать с прочитанными данными? как они превратятся в объекты?

построчно считывать мне удобнее, так как если структура файла повторяющаяся, можно циклами всё збсь считать и всегда будет ясно, что где находится и что считывается + из строки теги удобнее выпиливать :D

что делать с данными - в цикле считывания заносить в классы

как превратятся в объекты - а никак. всё ручками

хз мне так удобнее с хмл работать

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

что-то на уровне нодов

Сколько тебе заплатили за это?

За разговор?

построчно считывать мне удобнее, так как если структура файла повторяющаяся, можно циклами всё збсь считать и всегда будет ясно, что где находится и что считывается + из строки теги удобнее выпиливать :D

что делать с данными - в цикле считывания заносить в классы

как превратятся в объекты - а никак. всё ручками

хз мне так удобнее с хмл работать

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

что-то на уровне нодов

кароче ты какой-то велосипед выдумал.

 

а вот по поводу жсона и хмл

специально проверил пикасу. нашел огромный альбом

https://picasaweb.google.com/data/feed/api/user/103205196789503859543/albumid/5381026199150379489?alt=json

https://picasaweb.google.com/data/feed/api/user/103205196789503859543/albumid/5381026199150379489

жсон 782 149 байт

хмл 810 361 байт

это по вашему охуенная экономия?

лично я так не думаю

Мой брут делает 178 слов в секунду

мало, делай через сервак

Мне для альбома приходится парсить 200кб пикасовской json'ки и это только 150-200 фотографий. Боюсь представить что будет с xml.

 

будет примерно 300 кб. обрати внимание, что вслед за 200 кб текста тебе придется грузить медиафайлы гораздо большего размера

ты кстати можешь дать мне ссылку на этот альбом и мы проверим какой он дает ответ по размеру

вот, например, http://picasaweb.google.com/data/feed/api/user/107154344434298840621/albumid/5498667236857861137?alt=json-in-script

 

построчно считывать мне удобнее, так как если структура файла повторяющаяся, можно циклами всё збсь считать и всегда будет ясно, что где находится и что считывается + из строки теги удобнее выпиливать :D

что делать с данными - в цикле считывания заносить в классы

как превратятся в объекты - а никак. всё ручками

хз мне так удобнее с хмл работать

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

что-то на уровне нодов

кароче ты какой-то велосипед выдумал.

 

а вот по поводу жсона и хмл

специально проверил пикасу. нашел огромный альбом

https://picasaweb.go...379489?alt=json

https://picasaweb.go...026199150379489

жсон 782 149 байт

хмл 810 361 байт

это по вашему охуенная экономия?

лично я так не думаю

я лично вижу только json и json

Сколько тебе заплатили за это?

За разговор?

За сайт