Sekai Camera という iPhone アプリでは，AR (Augumented Reality) 的な技術をつかって，カメラにうつされたものの情報をかさねて表示するらしい (iPhoneアプリの未来を見せてくれた 「Sekai Camera」)． しかし，カメラの映像と付加情報から，そこにうつされているものをきちんと識別するのはむずかしい． Sekai Camera がすぐ実用になることはないだろう． それよりも，カメラの映像をもっと loose な検索にむすびつけていくほうが，すぐに実現できて，おもしろいのではないだろうか?
E-mail による写真投稿は携帯の機種をとわず，可能である． つまり，だれでも投稿することができる． 一方，iPhone の柔軟性をいかして，Web や，もっとつかい勝手のよいアプリケーションによって投稿することもかんがえられる． しかし，とくに Web に関しては iPhone にファイル・システムが確立されていないことが障害になる．
フィールドでとった写真をすぐにアップロードするには，携帯電話で写真をとり，メイルまたは Web で送信するのがかんたんである． しかし，携帯電話についたカメラの弱点はズームできないことである． 単なるおまけの写真ならばそれでもよいが，建築をうつすときなど，距離や角度が重要な写真をとるのに携帯電話が適切かどうかという問題がある．
Amazon にはリストマニアという機能がある． それと同様な建築などのリストをつくる機能をいれるとよい． カテゴリーにわけることはできても，それだけでは建築をたばねる機能は十分でないからである．
TownWiki の各項目がふくむべき項目つまり名称，設計者，施工者，所在地，建設年，構造，建築面積，建物の写真・動画，説明等，掲示板，リンクのなかで，最後の 3 つ以外は自動翻訳が比較的容易であり，自然だとかんがえられる． したがって，TownWiki を多言語化し，これらの項目は各言語 / 各地域に共通にする，つまりいずれかひとつの言語で入力されたら他の言語に自動的に翻訳するようにすることがかんがえられる．
女性には地図が不得意なひとがおおいという． そのため，とくにナビゲーションの際にはつぎのような選択肢がかんがえられる．
建築や店舗にかぎらず，動物やヒトもふくめたモノにはある期間のあいだ存在する． したがって，モノには通常，存在を開始した年と存在が終了する年とがある． ヒトであれば生年と没年である．
TownWiki は
また，携帯に対応するのはモバイル対応という意味もある． 実在のまちの情報をとりこんだ TownWiki はフィールド・アクセスによって，さらにいきる．
建築だけがもつ属性をデータ・スキーマにとりいれると，建築以外のものを表現するのが困難になって汎用性がうしなわれる． しかし，もともとの Wiki のようにいっさいの属性をとりいれないと，特徴がうしなわれる． 特定の属性に依存する検索機能は実現できなくなる． したがって，データ・スキーマの設計が TownWiki / Wikitecture のおおわくをきめる． しかも，いったんスキーマをきめてシステムを構築すると，あとからそれを変更するのは容易でない．
TownWiki (Wikitecture) は，おおきくわければモノとコトとで構成される．
モノとコトに対してはことなる表現や属性 (スキーマ) があたえられるべきである．
Wikitecture の項目からは広告や商品へのリンクをたどることができ，またそれらに関する画像がみられるようにするべきである． ただし，露骨な商業主義は wiki への悪影響があるとかんがえられるので，Wikitecture サイトじたいが商業サイトになるのはさけるべきであろう．
Wikitecture の各項目はつぎの要素をふくんでいるべきである: 名称，設計者，施工者，所在地，建設年，構造，建築面積，建物の写真・動画，説明等，掲示板． これらのうち説明等，掲示板，リンクをのぞくと言語によらず共通の項目にする (つまり，ひとつの言語で入力すれば他の言語に自動的に翻訳されるようにする) ことができるとかんがえられる．
メイル・ワークフローにおいては宛先アドレスによって機能が指定される． このアドレスは機能だけでなく，その機能が存在する (仮想的な) 場所もあわせて指定しているとかんがえられる． すなわち，そのアドレスのドメイン部において指定された場所において，その機能が実現されるべきである． この原則を無視すると，アドレスと機能との対応がくずれて混乱がおこる可能性がある．
ひとつのメイル・ワークフローにかかわるメンバー (ひと) のメイル環境は完全にはあわせられないとかんがえるべきである． これは，メイル・クライアントについても，サーバやプロキシについても，いえることである． メイル・ワークフローはこうしたヘテロジニアスな環境のもとでも，ただしく動作しなければならない．
ワークフロー・システムは集中型の構成のほうが容易に実現することができる． しかし，メイル・ワークフローはメイル・サーバとメイル・クライアントとのあいだにはいるプロキシによって実現されるため，分散型の構成をとることが必須である． データベースだけはプロキシから分離して集中型の構成にすることも可能だが，プロキシが分散型である以上はその利点がいかせる構成にすることが適当だとかんがえられる．
ひとりのひとが，すくなくともひとつの組織のメイルと個人のメイルとを管理する． 複数の組織に同時に属しているひともいて，そういうひとの数は今後さらに増加するとかんがえられる． 個人のメイルも 1 人だけの組織あるいは家族という組織へのメイルとかんがえれば，いずれも組織への多重帰属の問題だととらえることができる． こういう多重帰属がある状況のもとでメイル・システムやメイル・ワークフローがどうあるべきか，検討しておく必要がある．
メイルがスケジュール管理のためにつかわれていることは，よく知られている． Outlook などにはそれを支援するための機能がくみこまれている． しかし，このような機能は十分ではないし，標準化されていないのでメイラーをかえるとつかいつづけることができなくなる． メイル・ワークフローにおいては，より強固な基盤を確立する必要がある．
宛先によって機能を指定する際に，パラメタをわたしたいことがある． たとえば添付ファイル名のチェックにおいてはファイル名やプレフィクス，ポストフィクスなどをパラメタとしてわたしたい． こういうときのために，メイルアドレスを機能とパラメタとに分解するしくみをそなえておくのがよいとかんがえられる．
ワークフローにおいては個々のトランザクションを識別する必要があるが，メイル・ワークフローにおいてその識別子としてなにを使用するかをきめる必要がある．
添付ファイルの自動チェックに関しては 「宛先指定による添付ファイル自動チェック機能の仕様」 に書いたが，ここでは手動チェックもふくめた，よりひろいチェック機能の仕様について検討する．
QuickML の方法を改良したメイリング・リストの実現に関しては 「QuickML 方式の簡易 “会議室” 管理の応用」 において仕様を検討したが，ここではそこでの選択肢をしぼって，ひとつの仕様にまとめる．
SMTP の使用を前提とするかぎり，メイルサーバまたはメイルプロキシを使用した機能拡張の範囲は比較的かぎられている． Reasonable な方法はメイルの宛先 (RCPT コマンドの指定内容) や送信元 (MAIL コマンドの指定内容) によって動作をきりかえることである． QuickML [Tak 03] [Mas 03] はそういう機能拡張によってメイリング・リストを実現している．
「QuickML におけるメイル・アドレスの用法 — 機能実現の手段」 に書いたように，QuickML においてはメイリング・リストをかんたんな方法によって管理することができる． ここではメイリング・リストだけでなく，ひとびとがメッセージをやりとりする場としての “会議室” の管理に対象をひろげて，その応用についてかんがえる．
QuickML [Tak 03] [Mas 03] は，メンバーの登録・削除や他のメイリング・リスト管理機能がかんたんなメイルをおくるだけで実現できるプログラムである． QuickML は SMTP サーバとして実現されているため，どんなメイル・クライアントからも使用することができる． SMTP は機能がかぎられているため，単純なメイルの送受信以上の機能を実現しようとすると，“to”, “cc” のような宛先指定をうまくつかう以外に方法はない． QuickML はそれをうまくつかって実現されている．
Perl によって記述された SMTP デーモンとして Qsmtpd がある． Sendmail Mailstream Manager と同様に，プラグイン・アーキテクチャをとっていて，容易に機能を拡張することができる． プラグインも Perl によって記述する． スパム対策のためのプラグインが多数，提供されている．
CPAN に登録された Perl モジュールのなかには，インターネット・メイルに関するものが多数ある． そのすべてをここであつかうことはできないが，主要なものをサーベイする．
テンプレートの数がすくなければ，Thunderbird の 「テンプレート」 フォルダーのような，メイラーのフォルダにいれておくのがよい． しかし，テンプレートの数がおおいとき，あるいは組織ごとにテンプレートがわかれているようなときは，メイラーには必要最小限のものだけをいれて，他は Web ブラウザなどで検索 (ブラウズ) するようにするのがよい．
メイル・テンプレートは Thunderbird のそれのように，メイルを書くまえにアクセスして，メイルの記述をガイドすることもできる． また，メイルを書いたあと送信前にアクセスして，メイルの形式や内容をチェックすることもできる． 目的によってテンプレートの形式もかわってくる．
Thunderbird などにおけるテンプレートは個人ごとに管理しなければならない． しかし，コラボレーションのためにテンプレートを使用するばあいは，テンプレートを共有する必要がある． そのためのかんたんな方法はテンプレートに URL をあたえて，HTTP などによってアクセスする方法である．
SMTP は SMTP サーバが直接メイルボックスにアクセスできるときは送信者にメイルがおくれないという返事をかえすことができるが，メイルをリレーするときには単純に OK という返事をかえす以外のことはほとんどできない． 現在ではメイルに関してウィルス，スパム，誤送信，情報漏洩など，さまざまな課題があるが，これらに関して現在の SMTP の応答によって対処できることはほとんどない．
Sendmail Mailstream Manager は着信メイルのウィルス，スパムなどに関する対策と送信メイルによる情報漏洩などに関する対策をあわせてとることができる，サーバ上で動作するメイル・プロキシである． 拡張性が最大のウリである．
NTT ソフトウェアの CipherCraft/Mail Ver. 4 という製品はクライアント PC 上で動作するメイル・プロキシであり，メイルの暗号化機能とともに誤送信防止機能がウリになっている． 前者を省略した廉価版もある (前者が 100 ユーザあたり 98 万円，後者が 49 万円)． メイル送信時に送信者がメイルの内容を再確認するのがおもな機能であり，メイルの内容を自動チェックする高級な機能はない (キーワードをチェックしてスコアを計算する機能はある)． この機能に関しては特許出願中だという． 2007 年 11 月に誤送信機能を搭載した最初のリリース (?) が出荷されている．
「Thunderbird でどうやってテンプレートをつくる?」 では Thunderbird のテンプレート機能を調査して，うまく動作しないと結論づけた． その後 Thunderbird も改訂されているので，再度，調査をおこなった． バグは減少しているようだが，期待される機能ではないようにみえる．
2007 年 5 月にメイルやワークフローに関する調査研究をおこなって，この研究ノートにメモを書いてきた． その後は休止してきたが，他のテーマの調査研究が一段落したため，再開する．
Firefox もそうだが，Thunderbird でもあまりつかわれていない機能はデバッグがすすんでいない． メイルのテンプレート機能はワークフロー機能の基礎になる重要かつ便利な機能だが，Thunderbird のそれはうまく動作しない．
David Mann による題記の本 (Apress 刊) を読んでいる． 最近の Windows (Vista/XP) におけるもっともおおきな変化 (進歩?) のひとつは Windows Workflow Foundation (WF) がとりいれられたことだとおもうが，この本はそれが Office 2007 においてどういかされるかを書いている．
メイルのひながたの用法にテンプレートの利点をのべたが，そこには添付ファイルについては書かなかった． もしテンプレートにおいて添付ファイルをつけることを条件とすることができれば，テンプレートをつかうことが添付わすれ防止にもやくだつ．
論文，仕様書などのドキュメント，あるいはメモを定義する． 送信者と受信者とがことなるばあいと，同一のばあいとがある． 同一のときは単純なファイリング，ことなるときは FTP とみなすことができる． ただし，ドキュメントは更新されることがある． つまり，版管理が必要になる．
