とりあえず、IMAPの2G/4Gフォルダ制限はなくなることで動いている。ローカルフォルダの制限については、全プラットフォーム4GBになるはず (今まではWindowsだけ4GBでそれ以外は2GB)。パッチはすべて作成済みなんだけど、自動テストで6GBのIMAPフォルダをダミーで作るとか2GB越えのローカルフォルダを作成するとかやることになるけど。
あと、asuthと僕がどこまでやるかにはよるけど、Glodaの検索はちょっとは手を入れると思う。全角半角の区別なくすとか、ASCII以外の大文字・小文字の制限無くすとか。
RSSは今回も手を入れないとは思うけど、RSSのデータだけsqliteデータベースに移行できるかどうかは考えてみます。今まではmorkベースだから問題ありありだし。
3 件のコメント:
Glodaのインデックスファイルはどうなんでしょうか？すでに4GBを超えたという人をみかかていますが。
sqlite3的には4GBを超えられるはずなんだけど、なんで超えられないかちょっとわからないです、現状では。FAT32とか使ってるんだったら、どうしようもないけど。
ちょっとテスト環境作ってみないと何とも言えないですね。sqlite3側を直さないといけないんだったら、3.1のタイムフレームでは無理になりますが (コア側を直さないといけないので)
Katoさん。前回のコメント掲載ありがとうございました。
>RSSは今回も手を入れないとは思うけど、
最近のBugzillaを見ましてもRss関連のbugは一向に手つかずなのは前回申し上げましたとおりですが、3.1でも期待できそうにないのはちょっと悲しいです。
>RSSのデータだけsqliteデータベースに移行できるかどうかは考えてみます。
ぜひともお願いします。
また、この機会に是非ともご一考いただきたいのですが、そろそろmsfで管理する方式から転換していただけないでしょうか。
Msfが壊れるたびに重要な情報が毎回リセットされてしまうのはたまりません。
また、Thunderbirdの間口を広げる上でも、ストロングなmailbox、RSSフィード管理ができないのは非常にマイナスだと思います。いったい誰がこんなシステムを採用したのか分かりませんが、毎回MSFに汚い言葉を投げかけなければ気が済まないほど悩ませられております。本当にSuck msfです。
前回申し上げた、Rss feedのURLが突如
消失するNastyなbugもMsfの拙い扱いが元凶です。
なお、参考に成れば幸いなのですが
本当にThunderbirdのRSSの使い勝手が良くなって欲しいという願いを込めて、RSSのヘビーユーザーとして僭越ながら
現状の3.0.1でのRSSの未解決の問題点を今一度整理しておきます。
１．.msfファイルが壊れRSSフィードがいきなり消失する。
２．RSSフィードがいきなり消失したことに気づきにくいシステムとなっている。
これは、現状ですとフィードの購読画面から確認するよりほかないわけですが、複数階層になっている場合と、フィードURLが存在する場合との見分けがつかないこと（つまり、純粋なフォルダではなく、フィードアイテムフォルダが作成されるため）、またそもそも目視により確認するほか無く、イベントログにも全く残らないことなど各種の不便さが合わさってこのようになっているのだと考えます。したがいまして、各パートを１つずつ改善することでも大きな意味を持ちます。
３．RSSフィードのインポート及びエクスポートに於いてOPMLの階層表示が反映されない。また、XMLのインポートエクスポートが動作しない。インポートエクスポートの一括取り込みしかできない。Msfが壊れている場合にはRssフィードを認識しないため、エクスポートに抜け落ちが出やすい。
４ 3の不具合により、feeditems.rdfやfeeds.rdfを削除するという方法は現実的に取り得ない。また、msf自体がrssフィードの消失と密接に関わるため、メールボックスが壊れた際に推奨されるmsfの削除及び再生成という方法も取り得ないので八方ふさがりなのにっちもさっちもいかない状態である。?
５．feeditems.rdfのサイズ制限がおそらくされているため、重複取得の可能性が残る。推測ですがこのサイズ制限がfeeds.rdfの消失に関わっている気がしないでもありません。
６．RSSの取得時間のカスタマイズが全くできない。現状では、News & Blog を時間別に複数作成しなければいけない。
７．６に関連して、全く時間のカスタマイズができないため
取得時間帯になるとCPU,Memory,HDDの全てのリソースを五月雨式に貪るので、事前にシステムをチューニングしておかないと一定時間機能不全になる可能性がある。耐久性のあるHDDと異なり、したがって、書き換え制限数に留意すべきSSDやUSBでRSSを利用するのは現状では非常に危険である。
８．フィードURLの削除自体がフィードの購読ウィンドウのみで完結しないことが多い。
feeds.rdfを開いて該当箇所を適宜削除する必要があり、使い始めのユーザーはこの作業ができず再度登録しようとすると、既に購読されているというメッセージが出て戸惑うことになり、推奨できないfeeds.rdfの削除をするしかなくなる。
また、１で上げましたようにフィードURL自体は消失しても
feeds.rdfには該当のURLが存在することが殆どの場合であるため、消失するたびに非常に上記の面倒なステップを踏むか、
Feeds.rdfの削除というリセット手段のいずれかの選択肢を強いられる。
９．フィードの登録自体でも非常に面倒なステップを踏む必要がある。
以上です。
コメントを投稿