２ちゃんねる専用ブラウザ開発者の皆さまへ ★2

**monazilla ★** · 2014/07/13(日) 20:33:10.16

こんにちは。monazilla ★です。

2ch.netのdatの取得方法、及び利用規約が近日変更される予定です。

ご登録をいただきました既存開発者の皆さまには、事前に新仕様のご連絡を予定しております。

お手数をおかけしますが、ご登録にご協力お願いします。

また２ちゃんねる専用ブラウザのユーザーの皆さまには、ご利用アプリの開発者様に、開発スレッド等でこの告知のご連絡をしていただきますと幸いです。

monazilla ★

https://docs.google.com/forms/d/1YQn7dPEqdEWnPhRwoJwjBJHY9yenonxv7H3g9SNZV_o/viewform

■前スレ
【連絡】２ちゃんねる専用ブラウザ開発者の皆さまへ
http://anago.2ch.net/test/read.cgi/software/1405086867/l50

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 15:49:53.41

>>712
このくらいのパースもできないでデータ容量増やすこと提案する開発者のことなんて考える必要ないだろｗ

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 15:51:30.97

Ajax つうか read.js は JIM 体制下になってから
文字化けするようになったまま放置されてるな。
そしてこの仕様が実施されればとどめを刺される。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 15:53:18.89

広告表示するブラウザの開発者には広告収入一部還元とか

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 15:54:47.77

クロール対策にはならない
飽くまで新たな収入源の確保と、専ブラの囲い込みだね

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 15:55:59.10

scではajaxでdat取得出来るようになってread.jsも機能追加されてるんだよな
向こうの方が開放的で2chって気はするが壁打ちする気はないので、こっちも見習って欲しい

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 16:09:34.96

鯖容量気にしてるのにログutf8,unicode、ajax、XML化したらお笑い
html生成怠けるぐらいCPU逼迫してるのに都度ajax、XML生成して返したら本末転倒だな
現実的なのはBE、●みたいにログインしてログイン処理以外は今までと同じ
つかなんでsplit一発解析、vector参照できるものajax、XMLにすんだよ

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 16:21:02.75

>>717
鯖屋から解放されてcdn移行したらアクセス過多CPU逼迫とは違ってディスク容量に無頓着になるな
高くもないオプションぽちればいいんだもん
scの場合、ログ保存ディスクはビッグデータ扱ってる会社から提供したりその会社の鯖そのもの使ってたほうが都合いいし

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 16:21:15.86

>>718
鯖容量なんてJimは気にしてないし
ajax化とかajaxにするとかコイツ何言ってるの・・？

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 16:48:56.42

変更するついでにスレ一覧にBE情報付けて

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 19:02:16.31

bbsmenuもUTF-8のJSONで返してくれると助かる

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 19:14:54.01

まぁJSONは分からないでもないな
XMLはダメだろｗｗｗｗｗｗｗｗｗｗｗ

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 19:18:41.82

>>718
鯖容量がストレージを指すなら多分ぜんぜん気にしてない
自分だったら書き込み以外に参照の記録も全部残したいくらい

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 19:24:45.37

JSONとXMLどっちにも対応すればいいだけの話

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 19:25:22.50

今日は変な方向に誘導する人出て来ないねw

フィリピンは台風で長時間停電したりしてたらしいね

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 19:35:45.65

いやいやXMLなんてどんなことがあろうと対応すんなよ
通信コスト何だと思ってんだよ
てめーがちょっと苦労したくないだけのしわ寄せを全体の負荷に押し付けるなよ

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 19:36:33.55

>>90
これはほんとうにそうなの？CGIとかよう知らなくて何ができるのかしらんが、
まさか、datの取得とかレス書きこみのたびにディスク上のファイルにアクセスとか
そんなわけないよね？？

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 19:36:38.26

専ブラでパースしやすくなるように鯖側にエンコ処理を追加するってのは
サーバと帯域に余力がない限りは無駄にコストを増やすだけに思える

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 19:38:40.21

鯖は単純処理で専ブラ側で重い処理するのがベストですね。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 19:44:09.32

そもそも2chみたいな単純に新着レスが追記されてくだけの掲示板で
XMLなんて冗長なだけでパースが楽になんてならんだろ

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 19:46:45.92

dat 書き込み時はファイルに追記するだけ、
dat 読み込み時は静的ファイルの conditional/partial GET、
というのが現行方式。
JSON にしろ XML にしろこういうやり方ができなくなるから、
サーバ側の負担は重くなる。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 19:48:55.03

JSONのチェーンソーでデータを切り刻んで一回のデータ送信を軽くしようって事ですね！（適当

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 19:52:00.05

ゴミみたいなブラウザ量産されちゃ困るから今のままでいいです

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 19:53:40.18

>>728にも疑問書きましたが、
>>732
ということはやっぱ、現状、毎回、ディスクアクセスしてるんですかね？？
ディスクアクセス激しそうだな。
そんだったら、インメモリデータベースにしろ、もうちょっと構造的にデータをもって、
on the flyでJSONなりで返した方が返ってトータルな負荷低いってこともあり得そう。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 19:55:44.63

2chサーバーってディスクにSSD使ってるぽいのか

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 19:59:00.53

ファイルキャッシュはアクセスされる方がやるべきで、CGIがやるもんじゃないだろう

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 20:02:21.41

>>735
昔は HDD 使ってたが、
ある時期から SSD に切り替えたら劇的に軽くなった。
今はディスクアクセス云々の問題は
あまり考えなくてもいいだろう。

>インメモリデータベース

昔はメモリディスクに dat を入れるジンギスカン2というのを
一部のサーバで実施していたこともある。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 20:26:45.52

>>昔は HDD 使ってたが、
>>ある時期から SSD に切り替えたら劇的に軽くなった。
なるほど。
でも、やっぱ、SSDとDRAMじゃ速度が全然違うし、書き込みあったら排他書き込みロックなり取得とか
ファイルレベルの排他制御しといて、負荷がぁあとか言うなよとは思う。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 20:35:33.92

世の中にはNCQというものがあるんだぜ
当然、FreeBSDのファイルシステムでも対応してる

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 20:35:59.25

APIキーを導入するってことは余裕があるってことだろうけど。
一般ブラウザーは忍法帳でクロール的取得を取り締まってJAVASCRIPTでDATをスタイリングさせるようにすればいい

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 20:42:40.98

>>739
排他制御はしてないはず。なぜなら dat の追記に関しては

http://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html
>If the O_APPEND flag of the file status flags is set, the file
>offset shall be set to the end of the file prior to each write and
>no intervening file modification operation shall occur between
>changing the file offset and the write operation.

ということになってるから。subject.txt の更新については、
いったん別ファイル名で生成してから rename() している。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 21:03:28.60

>>742
なるほどです。ありがとうございます。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 22:05:54.66

へー append ってスケールするんだ
まあそうじゃなきゃ syslogd ない頃の/var/log とか大変か

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 22:17:02.61

>>727
まぁ、どうしてもカツカツでconditional GETじゃないと無理なんですぅ><ってならしょうがないけど
いまどきTwitterもGoogleもJSONが当たり前だし、多少はね？親切なAPI提供してくれてもいいんじゃないかと

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 22:46:49.85

それに、dat取得で専ブラが差分取得するために、partial GETしてるけどさ、
RFCのHTTPの仕様的に違反した使い方してるんだよね。
クソ笑える。専ブラの実装もめちゃくちゃだわ。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 22:49:07.52

RFCのHTTPの仕様に違反したやり方なんて実装したくねぇ。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 22:54:31.45

>>746,747
へー、あれRFC違反なんだｗ
ソースも教えてほしいものだ

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 22:58:47.70

>>748
ソースってRFC 2616読めばわかるよ。
今、簡単に説明するからまって。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:06:39.85

まず、partial GETしないでdat全件取得してるでしょ。
で、それとともにETagもしくはLast-Modifiedヘッダが返ってくるでしょ。
専ブラは差分っぽいの取得するために次はバイトレンジ指定してpartial GETするでしょ。
新規書き込みがあれば、差分っぽいのが返ってくるよね。
でもね、datとが変更されて返されるレスポンスのETagもしくはLast-Modifiedの値が前と変わってるんだよ。

ETagもしくはLast-Modifiedが違えば、別物なのでRFC的には最初に取得した全件と
次に返ってきた差分っぽいものはマージしちゃいけないんだよ。

partial GETで取得した部分は同じETag、Last-Modifiedのものとしかマージできない。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:11:08.44

>>750
つまり差分DLはしない方がRFC的には正しいと？

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:11:41.59

だから、新規書き込みの部分だけを取得するためのpartial GETの使い方は間違い。
無理やり使ってる。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:14:14.07

>>750-752
ﾜﾛﾀｗｗｗ

だけど、そうでもしないと負荷軽減がまともに出来ないよな…

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:19:12.07

>>だけど、そうでもしないと負荷軽減がまともに出来ないよな…
まぁ、そうなんだけどさ・・
サーバーが負荷・負荷いうわりに、クライアント側で、RFCに違反したこととか
めちゃくちゃなことさせやがってって感じ。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:23:11.90

2chブラウザはRFC的にマージしてるわけじゃないでしょ。
2chのDATが追記されるものであることを一応保証しているから（例外はあるものの）、
2chのシステムの特性に合わせて差分取得してマージしているだけ。
それをRFC違反とか言うのは的外れ。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:26:07.22

>>723 >>727
元がHTMLやHTML系のdatなんだからXMLの方がJSONよりかは相性が良い。
エンコード変換が発生しないならJSONの方が余分なエスケープが必要だしな。
大抵はXMLの方が冗長ではるが…フォーマットしなければJSONより極端に大きい訳でもなくね？
ていうか>>732だ。効率云々言うならdatが一番安定。精々レス番フィールド足すくらいでいい。
>>735
オンメモリで扱うにしても高効率ベタデータのdatの方が明らかに効率が高い。
JSONやXMLで全体を括ったりエスケープするような操作する時点で効率は落ちる。
>>748
RFC云々言うまでもなく、更新日時の変動を追記前提でちょこっと前から読みなおして、
あぼーん時は再読み込みするなんて挙動はどう考えても一般的な挙動ではないだろ。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:26:09.89

だから、RFCに違反してる使い方をしてること。

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:28:16.07

>>755
RFCになんでstatusが設定されてるのかちったぁ考えろ

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:31:38.60

専用ブラウザのアクセスに違反もなにもない

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:32:55.05

>>757
RFCのルールの外でやってるから、違反も何もない。わかるかな？

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:35:27.97

専用ブラウザ向けの限られた運用での仕様なんだから関係ないでしょ
マージしてるのはクライアント側の勝手だし

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:38:07.62

>>756
だからなんでHTMLとして扱うっていう前提なんだよ
HTMLレンダリングエンジンじゃなくてプラットフォーム標準のUIコンポーネントを使って表示しているブラウザもあるんだよ
昔の2chブラウザは知らないが、最近のスマートフォンアプリなんかはほとんどそうだろ？

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:38:54.84

つってもhttpのライブラリ使うことを考えると2chの妙な仕様は相当ウザい

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:40:03.57

今日はここまで
中々順調だわ
http://upload.fam.cx/cgi-bin/img-box/91u140716233819.png

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:45:07.67

規制処理以外は流出したbbs.cgiのソースからそんなに変わってないと思うから読んどけよ
まだ斧に残ってるはず

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:56:40.06

まさかとは思うがdatのフォーマットまで変わるなんてことないよね？

**名無しさん＠お腹いっぱい。** · 2014/07/16(水) 23:57:03.17

>>762
JSONやXMLでBE等のリンクや名前欄の装飾や本文のアンカータグを表現する
データ構造なんぞを再発明してさあ使えとかやられたらそれこそブチ切れだろーが。

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 00:03:16.09

>>767
Beリンクや名前の装飾やアンカータグのデータ構造なんか要らないんだよ。プレーンテキストでいい。
本文内のアンカーやリンクはこっちでdetectしてリンク張り直すから。
HTMLのタグだの文字実体参照だの入ってるせいでアンエスケープだのしないといけない方が面倒。
本文内にBeのアイコンリンク入れるのもやめろ。ssspとかいうふざけたスキームまでつけやがって。

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 00:30:05.34

登録してないから事情わからんけど、新API使ってるの？
>>764

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 00:37:26.73

いやどう考えても今までのやつ
そもそも俺開発者登録したけどまだメール来てないし

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 00:40:46.67

もう１日半>>1は現れとらんな

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 00:51:41.89

>>768
そして２ちゃんだろうがしたらばだろうがどこから拾ってきたものでも
似たような表記だから～と同じルールで張り替えてしまって
違うところに飛ばすリンクを生成するとかいうポカミスをやらかすんですね
わかりますん

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 01:00:02.18

>>770
一般開発者には連絡しないって言ってたけど
公開アプリ名と同じ名前で登録しないと連絡来ないみたいね

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 01:08:44.35

>>772
意味不明なんだけど

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 01:08:59.36

有能

475　koreawatcher ◆XenoM10nSg 　[sage]　2014/07/17(木) 00:49:16.82 ID:A7qnikI40　　
>>435,437
登録している人もたくさんいるようですし、とりあえず登録してみました。
仕様が変われば2chにアクセスできなくなるのは確実なわけで、
それならば仕様変更日の前に修正を済ませておいたほうがいいと
考えました。

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 01:13:49.65

xml推しはエスケープのことしか考えてないから
つーかどう見ても同一人物

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 01:13:54.41

>>773
連絡来た人いるの？

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 01:19:08.78

パソコン通信のプレーンテキストの解析
ログインメッセージが変わったためにログイン成功を
検出できなくて、巡回失敗とかあった
しかし会議室のコマンドは便利だったよ

2chの仕様は2年ぐらい追っかけたけど、
忍法帖導入頃にバカバカしくなってやめた

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 01:20:10.57

ほんとに30人も登録したとは限らないのに
見事に釣られてるな。

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 01:32:13.38

>>772
あぁ、わかった
つまり2chの特定レスのURLは
http://<;host>/test/read.cgi/<board_key>/<thread_key>/<post_index>
だけどしたらばは
http:// <host>/bbs/read.cgi/<category_key>/<board_key>/<thread_key>/<post_index>
と違っていて、
したらばを処理しているときでも2ｃｈのルールで特定レスのURLを生成しちゃうミスをするだろってことか？
そんなことしねーよアホ
というかアプリ内では内部URLを使うのが普通だろ
例えばスレッド画面内で特定のレスを指すURLは
<application-url-scheme>://thread/post/<post_index>
>>776
XMLじゃなくてJSON推しだけど、エスケープのことだけじゃなくて、JSONの方が何かと便利だろ？
{
　"index" : 774,
　"from" : "iPhone774G@転載禁止",
　"mail" : "sage",
　"post_date" : 1405251190,
　"text" : "うんたらかんたら",
　"be_icon" : "http://img.2ch.net/ico/kashiwamo-chi32.gif";,
　"id" : "XXXXXXXX0"
}
って取れたら相当楽じゃない？

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 01:33:22.75

>>777
知らんけど
>>421の通り
ただ登録するだけじゃ連絡してくれないみたい

他のアプリ名使ったなりすましが大量に出るだろこれ

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 01:36:46.15

単純に連絡開始してないだけだって

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 01:40:13.83

個人情報何たら言ってるから無いだろうけど
登録して頂いた開発者一覧とか勝手に晒されるの嫌だから
気安く自分のソフト名入れるの気持ち悪いんだよね

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 01:42:46.96

完全非公開じゃないのは確定したし
それでいいと思うよ
後は公開まで待っとけ

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 01:44:45.82

>>783
漏らしたり晒したりしたわけではありません
公開しただけです
ｺﾚﾀﾞﾅ

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 02:40:58.42

>>780
ちっとは楽だけど、ころころフォーマットが
変更されないってことの方が楽するためにはずっと効果的
なので今のままでok。

あと本文のとこは html (の一部)として記述されて
そう解釈してレンダリングないとホワイトスペースの
スキップのナニでAAが崩れるからちょっと特殊

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 03:10:52.58

>>786
既存の開発者にとってはそうかも知れないけど、
新規の開発者にとってはJSON使えたら開発のハードル下がってありがたいんじゃない？
本文はHTMLじゃなくてプレーンテキストでいいだろ。
スキップされる半角スペースについては、最初からトリムしてJSONに渡すか、
JSONに含める代わりに、HTMLにする際には にする、でいいだろう。
いずれにしろ、JSONは、そのまま表示できるような文字列で渡す。HTMLとか小細工は不要。

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 03:16:28.66

>>787
べつにハードル下がらないと思うけど
初心者にとってはただの文字列操作の方が簡単じゃん？
面倒いだけで
結局JSONパーサー作らないとなんだし

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 03:29:03.27

出来合いのXMLパーサー使いたいですぅ

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 03:42:04.40

ハードル云々言い出したら
そこらに様々な言語でのサンプルがある
今のdat形式が一番楽で低いのでは

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 03:42:06.62

>>788
JSONシリアライザならいまどきどの言語にもあるだろ。
DATのオレオレフォーマットのパーサを各自で実装するよりずっと簡単で安心。
JSONにするデメリットって、2chのサーバー負荷が増える？ぐらいしかねーよ。

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 04:09:09.11

で、結局monazilla ★って誰なの？NTの人間ならJimという責任者がいるし
顔出す必要はないけど、外部の人間なら身元をはっきりさせるべきだと思うけどね。真っ当なビジネスやるつもりなら。

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 04:09:46.05

2chのサーバーに負荷増えるのが一番迷惑だけどな
たとえそれが1%程度だとしてもだ
パーサちゃんとできない専ブラはごみ箱→ごみ箱を空にするでOK

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 04:34:29.06

これから新規に作るってならJSONでもXMLでもいいんだろうけど・・・

既存のブラウザは今までの仕様を引きずらざるを得ない
ログをdat形式のまま保存してるものが大半だろうし
（今の）2chの仕様と互換性ある外部掲示板を読めるものも多い
そこに互換性を取りながら機能追加するのはそれなりに大変なはず

それを考慮するならデータの形式はなるべく現状に近い形にしたほうが
開発者の負担は少ないんじゃないかと思うんだけども

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 04:44:07.74

>>768
datはHTML吐くときのための内部データ形式でもあるんで、
これ廃止すると二重保持しない限りHTMLを吐く度に鯖がその処理の負荷を受け持つことになるし、
JSONを吐くときも尻は構造上単純追記では生成できない。
HTMLに完全依存したシステムがキモくても、システムとして定着してるのに今から全部廃止する？
<HR>とかも埋まるケースが有るし、文字参照に至っては最低でもUnicode必須になっちゃうぞ？
>>776
地味だが確実な利点だぞ？逆に、利点はそこしかないと言ってるも同然なんだが。
>>787
そもそも元がHTMLで、(AA等)レンダリングの目標もHTML。
簡略化したい気持ちはわかるが既に実装済みなのをどうする？
>>793
キャップ名なんかにLFが入っててログ破損とかたまに見るよね

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 05:17:11.18

勘違いしてる奴居るが専ブラの開発のしやすさとかどうでもいいわ
お前の作った専ブラの出来が悪いのはお前のせいだろ
２ちゃんのせいにして負荷大きい処理要求するっつーのは負荷分の金の用意があるってことかい？

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 05:29:51.06

策定されたプロトコルを守っているならそれは仕様通りの動作だろ？
プロトコルを破っているならそりゃ開発者が悪いが、ね

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 05:40:38.98

過去の莫大な遺産を捨てるような馬鹿なことはしないだろう。
が、スレタイとレス数の間にBEを挿入してくれ
12345678.dat<>スレタイ [BE:1234] (123)
こんな感じでよろしく

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 05:42:17.69

まぁJSONになったらなったでDat2JSONを作るだけなんだけどね

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 05:45:38.91

>>796
Twitter社「勘違いしてる奴居るがクライアントの開発のしやすさとかどうでもいいわ
お前の作ったクライアントの出来が悪いのはお前のせいだろ
Twitterのせいにして負荷大きい処理要求するっつーのは負荷分の金の用意があるってことかい？」
こんな態度だったらTwitterはここまで伸びなかったろうな
まともなAPIを用意すれば、開発者も参入しやすくなる。
使いにくい仕様のために開発リソースの大部分を割くことなく、
アプリの機能、UX、本質的な部分の開発に割くことができるようになり、
質の高いアプリも生まれやすくなる。
そうすれば最終的にユーザーも増え、2chの収益も増える。
成長するサービスってのは、そういうモンだろう？

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 05:57:30.19

>>800
Twitter社がサードパーティを切り捨ててる現状を知ってての皮肉か？

まあ2ちゃんも似てるけど、切り捨てようってわけではないみたいだし、収益を配分しようとする姿勢を見せてるだけ、ましといえばまし

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 06:07:43.38

subject.txtを更新するとき同じスレタイを何度も受信してるので無駄だと思う。

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 06:16:07.30

>>800
２ちゃんの中の人のトリップをさらっとつけるか預金通帳見せるなら説得力ある意見だな
まぁそのJSONになってこその新しいサービスをお前は今温めてるんだろうから楽しみに待ってるわ
まさか負荷増大して似たり寄ったりの専ブラが増えることが成長じゃないよなｗ

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 06:21:25.22

やろうとしてることは既得権益を守る前提での専ブラ開発者の選定っぽいけどね
そして中身は利益分配を餌にした怪しい新規ビジネスへの協力要請でしょ

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 06:30:11.80

つうか最近毎晩のようにサーバ重くなったりしてんのに、
余計な処理追加する余裕とかあるんかね。
ジブリアニメの実況、特に「バルス」とかも
サーバ側の処理はかなりシビアな状態のはず。

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 07:40:50.77

ここで俺流の改善提案議論やってても★が出てきにくくなるだろうから、
＞　【専ブラ】新アクセス方式を議論するスレ
みたいなのをたてて、そっちで深めていかないか。
公開のスレで議論すれば、★に飲むように迫ることも可能だと思うが(gdgdにもなりうるが)
どうやら★の視点論点重視点は、
・SCクロール対策
・帯域占有量に対する広告無表示よる一方的な負荷押しつけのロス補償
この2つのようだ。あとは後付けの屁理屈だろう。

それはさておき、議論スレでは
・提案内容の概要
・現行との変更点(変更対処の内容)
・変更により危惧される点
たぶん、鯖負荷抑制の手法とか通信帯域抑制の手法など、鯖屋が喜びそうなネタを書けば
きっと議論スレにも脚光が浴びるんだろう。マス(人混み)効果でアクセスの連鎖を導けていた
あの頃とは違うので、ジリ貧掲示板ビジネス復興策、とでも言いますかね。

提案内容は幾つかの方向性があるだろうな
・前向きなもの(いわゆる★の思ってる喜びそうな方向の話)
・おれならこういう風にクロールを隠蔽するから無理だっていう反証
・俺流の専ブラ構築アイデアや進捗状況の紹介
たまにはまとめて意見集約もしないといけないだろうけどそれは適宜。

否定するにしても、穏やかな口調でおながいしまつよ。
「何がどう推移するであろうことから、実質的な効果は期待できそうにない」って風に。
PS:俺は★じゃないよ、いろいろアンチネタ振って総スカンくってる方だし
こっちじゃなく、qb5ょぅι゛ょでやるべきか? あっちに立てなかった誰かへのアンチテーゼの意味も込めて

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 07:42:46.21

自前でdat2json作って鯖立てるかローカルプロキシ化したらいいやん
本当に需要あるならOSSプロジェクト立ち上げたらすぐ完成すんじゃね

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 08:26:50.62

json2datなら使いたいです|дﾟ)ﾁﾗｯ

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 08:28:49.12

この流れだと
・json等の新しい技術はしない
・広告の強制表示は何のガイドラインも示さずに、開発者が混乱する
・公開アプリ非公開個人用アプリの区別の基準が曖昧で開発者が混乱する
・と言うか非公開個人用アプリは「後でやります」を言い続けて結局やらない
・いくつかの専ブラでAPIキーを個人で入力するような実装になる
・それを口実にして「個人用APIキーは発行出来ません」と被害者ぶる

ここまでは確実だな。運営のセンス無さ過ぎ。技術者かよ本当にてめー

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 08:45:07.04

まだ詳細は発表になって無いし(笑)

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 09:02:10.41

こうすればokという公式の仕様が無い代わりに、
あんまり仕様変更されないから現物合わせで作ればなんとかなる、
ってのが2ちゃんだったんだよ。

やる気のある無能な管理者に変に仕様開示なんかされると
・仕様通りに作ると不具合でる
・アプリ作者がアプリ側でアドホックに対策
・サーバ側が的外れな対策、仕様変更
のスパイラル起きる気がする。

**名無しさん＠お腹いっぱい。** · 2014/07/17(木) 10:23:11.70

>>805
クソシステムなんだからしょうがないじゃん。特定のサーバーに負荷が集中して、他のサーバーは遊んでる状態なんじゃないの？
ロードバランサとか入れて負荷分散とかしてるの？そんな事もできてないなら、いい加減知ったこっちゃないわ。