2007年06月10日

エンプレシアライブラリ更新 2007/06/10 Revision 10

昨日、utilにBase64Utilities追加した。
いろんなところにあるけどね(笑)
ioの動作確認して修正した。
あわせてnetも修正〜。
あとsecurityを書き換えた。
でもsecurityはもっと書き換えないとなぁ。
posted by すふぃあ at 23:50| Comment(0) | TrackBack(0) | 雁字

2007年06月03日

エンプレシアライブラリ更新 2007/06/03 Revision 9

スプラッシュスクリーン使ったときに
ダイアログモードでも正しく消えるようにしたりした。
最近、SSHとかタメしてみてるけどむずかしいねぃ。
ftpレベルが限界(笑)
posted by すふぃあ at 23:29| Comment(1) | TrackBack(0) | 雁字

2007年03月28日

エンプレシアライブラリ更新 2007/03/28 Revision 8

ライブラリ更新〜☆
EWindowのコンバートの不具合を修正。
一歩一歩(゜▽、゜
posted by すふぃあ at 22:31| Comment(0) | TrackBack(0) | 雁字

2007年03月25日

エンプレシアライブラリ更新 2007/03/25

エンプレシアライブラリ更新〜(゜▽、゜
ioパッケージと、それにつられてnetパッケージ。
IOTransmitterをちょいと改良したよ。

ふぃりあもお兄ちゃんの絵をバージョンアップとかしました。
まだ途中らしいけど。できあがったらアイコンもキレイなのにしよう!
(゚ー゚)(。_。)(゚-゚)(。_。)ウンウン
posted by すふぃあ at 23:20| Comment(0) | TrackBack(0) | 雁字

2007年03月21日

エンプレシアライブラリ更新 2007/03/21

uiパッケージ中心に更新。
http://doc.empressia.jp/
https://src.empressia.jp/release/
何かといろんなパッケージがutilに依存してます。

EDesktopManagerとか、EWindowとかつくってみた(゜▽、゜
posted by すふぃあ at 15:35| Comment(0) | TrackBack(0) | 雁字

2007年03月18日

ふぃりあ更新

ふぃりあ更新した。
関連付けしたの消すと変な情報が残ってた。
というわけで修正したのだ。
スプラッシュイメージももらったのを入れてみる。
正式じゃないけど。

まだまだ更新したい(゜▽、゜
posted by すふぃあ at 22:36| Comment(0) | TrackBack(0) | 雁字

2007年03月11日

ふぃりあ公開

水面下で動いてました(゜▽、゜
というわけで、「ふぃりあ」を公開しました。
アイコンとかはお兄ちゃんにお願い中です。
やっぱ階層型管理より集合管理が良いやというわけで創ってみた。

まぁ、将来的にはハイブリッドだったり、
管理対象が範囲広がったりとか考えてみてるの。

別にファイルを直にコピーしたりする訳じゃないので、
気楽に試してみてね。

http://www.empressia.jp/
http://www.empressia.jp/proj/filia/filia.html

感想とかこないかなぁ。
posted by すふぃあ at 18:46| Comment(0) | TrackBack(0) | 雁字

2007年01月27日

エンプレシアライブラリ更新 2007/01/27

新しくuiパッケージとかも創った。
http://doc.empressia.jp/
https://src.empressia.jp/release/
jarも新しく増やしました。
XMLAnalyzer、NetManagerは使い方が微妙に変わってるので注意。
xmlとnetはutilに依存。
(゜▽、゜
posted by すふぃあ at 17:28| Comment(0) | TrackBack(0) | 雁字

2007年01月02日

エンプレシアライブラリ更新

netパッケージ中心に更新〜(゜▽、゜
http://doc.empressia.jp/
https://src.empressia.jp/release/
一応、げすとではいれゆ。
あ、あと、netパッケージはutilパッケージに依存してる。
posted by すふぃあ at 22:46| Comment(0) | TrackBack(0) | 雁字

2006年10月24日

次世代なファイルシステム・プログラム言語・名前空間への期待

最近、一週間、たいとるの件の現状について、
なんか納得いかなくて色々思ったこと。

まず、ファイルシステムの話から入っていくよ。

・HDDとかの記憶領域に保存されいているファイル=要素(元)
・要素をある概念(名前)で仕分けしたグループ=集合
・集合も要素と見ることができる
ここまでは現行のツリー構造のファイルシステムと同じ。
ただ、集合って言うのは、実際には階層的な構造だけを持ってるわけじゃないでしょ。

つまり集合A⊇集合B∋要素xのような関係だけじゃないってこと。
集合A∋要素xで、集合B∋要素xという場合でも
集合A⊇集合Bでもなければ、集合A⊆集合Bでもないっていう状況がある。
現在のファイルシステムはこれが表現できてない。

Javaのパッケージなんかでもそれに従っている(?)せいで、
jp.empressia.http.client.ui.ProjectPanel
jp.empressia.ftp.client.ui.ProjectPanel
というような階層ができでしまう。
別の配置を考えると
jp.empressia.client.ui.http.ProjectPanel
jp.empressia.client.ui.ftp.ProjectPanel
となる。

ひとつのクラスなら気にならなくても、
これが複数になってくるとそうはいかない。
プロトコルが増えたら?uiだけじゃなくてmodelとかは?
clientだけじゃなくてserverは?
こうなると途端にどういう階層が良いのかわからなくなる。
しかし、そもそも「どういう階層が良いのか」ということ自体無意味だとおもう。
だって、プロトコルとドメインとuiとかは、
そもそも入れ子に存在する概念ではないから。
別々の独立した概念だよね。

この場合、
「jp.empressia∩clinet∩ui∩http」であるHttpProjectPanel
と、
「jp.empressia∩clinet∩ui∩ftp」であるFtpProjectPanel
と分ければいい(識別のためにProjectPanelの名前は変えた、別に同じままでも良いと思うけど)。
もちろん「jp.empressia∩clinet∩ui∩ftp」=「jp.empressia∩ftp∩clinet∩ui」ね、入れ替えても同じ。
ここで、「.」は従来どおりの関係にあるものを表記した(jp⊇empressia)。
「jp.empressia∩clinet∩ui」
こうするとにはHttpProjectPanelとFtpProjectPanelがあることになる。
もしかしたら、両方の基底クラスCommonProjectPanelもあるかもしれない(名前はてけとーです)。
つまり、パッケージとか、ディレクトリとかは実際のニーズとしては、
入れ子だけとは限らないはずなのだ。


もしかしたら、ディレクトリという名前のとおり、
住所という感覚が強すぎるのかもしれない。
例は良くないけど、「アメリカ表記の住所と、日本表記の住所は同じ場所でも別物」みたいなイメージが必要だと思う。
もっかい言うけど、ドメインと機能、表現っていうのは入れ子になるものじゃないんだよね。

もちろん、入れ子があり得ないわけじゃないから部分の制御はきっちり必要だけど。
たとえば、
「jp.empressia∩clinet∩ui∩protocol.http」とか。

さらにいえばHttpProjectModelっていうのがあるのなら
「jp.empressia∩clinet∩model∩protocol.http」とかにあるだろうし
「jp.empressia∩clinet∩protocol.http」をみれば、
HttpProjectModelとHttpProjectPanelがあることになる。
すごい自然だと思わない?
現在のシステムの拡張として実装できるはずだから、まずはそこからかな。

1.HDDとかの記憶領域に保存されいているファイル=要素
2.要素をある概念(名前)で仕分けしたグループ=集合
3.集合も要素と見ることができる
4.集合は別の集合と重なり合ってはならず、包含関係になければならない
4を撤廃する。
もしくは、4を「集合は別の集合に重なり合ってもよく、包含関係にあってよい」と書き換える。
それだけ。拡張ですむよね。

実装概念の目安としては、
ファイルに当たる要素と、集合を別のレイヤーとして捕らえるのがいいと思う。
問題は、制限をはずすのだから、処理は重くなり、資源をより必要とする事になるはず。
まぁ、同じグループに全部入れるとか変なことはないと思うけど。
検索のアルゴリズムとかは考えないとかもね。

あと、もしかしたらショートカットとかシンボリックリンクとか要らなくなるかな。
集合同士に優先度とか重みはないし、
ファイルは平坦に配置されてるイメージだから、
階層とかないし。

まぁ、昔は、資源が乏しかったから、そういう制限入れたのかな。
そろそろ新しくしようよ。
Javaとかのプログラムのパッケージも。
XMLとかの名前空間も。
OSのファイルシステムも。

それができたら、ネットでuiとか検索すると世界中のuiがヒットするのかなぁ。
その中から自分のほしいパッケージを探すのとかも楽しそう。
今のJavaって「最初に」ドメインで区切るし。

早く広まって実現するといいな。
JavaなLookingGlassとかに取り込まれないかしら。

以下、メモ

既存のディレクトリという概念から
包含関係制限をなくす。
階層的概念については問う必要はない。


ファイル:
ハードディスクやフロッピーディスク、CD-ROMなどの記憶装置に記録されたデータのまとまり
集合:
任意個数のファイル・集合の集まり

内包的記法=動的ファイル管理>条件を示すことで成立?

外延的記法=静的ファイル管理>マークすることで成立?
posted by すふぃあ at 19:19| Comment(0) | TrackBack(0) | 雁字