[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[b-free: 792] Re: ハイパーテキスト




隆一です。

From: Kazuhiko Iwama <with@st.rim.or.jp>
Subject: [b-free: 789] Re: ハイパーテキスト
Date: Tue, 11 Nov 1997 20:39:19 +0900

> ■ [b-free: 784] Re: ハイパーテキスト
> □ Ryuichi Naitoh<naitoh_r@soft.hitachi.co.jp> さんへのお返事
> 
>      岩間です。
> 
> ■ Ryuichi Naitoh さんのメールからの引用です
> □# ひとつの実身を 2 つ以上のアプリケーションで開いている場合、バージョン
> □# 管理はどうなるんでしょうか?
> 
>      やっぱ、ユーザーへの通知が必要でしょうね。もっとも、それら
>     のアプリケーション間で同期をとるか、とらないかで、バージョン
>     の更新の方法も変わるでしょうしね。

えーと、何を通知するんでしょうか?
すでに実身をオープンしているアプリケーションがあると、警告したとしても
使っている人にとっては、対処のしようがないと思います。
特にネットワークワイドで実身を使うことを考えると、すでに実身をオープン
しているアプリケーションは、別のマシンで動いていることも考えられます。
(ネットワーク上で仮身/実身のモデルがそのまま使えるのかという問題も、も
ちろんあります)

2つ以上のアプリケーションからひとつの実身をオープンできない(あとからオー
プンしたアプリケーションは読み込みだけしかできない)、という仕様にする
手もありますが、制限としてはきついでしょうか?



> □単純に、ファイルを更新すると新しいファイル ID が割り当てられるという方
> □式だと、リンクしている側からは更新前の実身しか見えないことになります。
> □自然に考えると、常に最新版の実身が見えた方がいいですよね?
> □リンクを(バージョン番号を含まない)ファイル名で記録するようにすれば
> □いいのでしょうけど。。。
> 
>      ファイルID自体にバージョン情報を含めてはどうでしょうか? 
>     ファイルIDを数値にこだわらなければ、
> 
>         base.x.y.z
> 
>     という感じで最新版は base のみで指定、base.x  だとその枝での
>     最新版、base.x.y.z だと固定という感じです(.x.y.z...  の階層
>     は理論的には無制限)。
> 
>      あるいは、API ではこのような形式でIDを指定して、内部で実
>     際のファイルIDに展開していてもいいですね。

リンクの指定方法として、2 種類あるということですよね。

[前提]
    バージョンは、x.y.z... の形式で指定する。
    バージョン番号は、一番右側の番号からインクリメントする。
    (1.0.1 -> 1.0.2 のように)
    最初実身を作成した時のバージョンは、1 となっている。
    この時に枝わかれを作成すると、1.1 のようにバージョン番号
    の階層が増えていく。枝わかれ後の実身は、一番右端のバージ
    ョン番号だけが変わっていく。

(1) バージョンを指定しない
    常に最新のバージョンの実身へのリンクを維持する。
    最新のバージョンの実身とは、一番バージョンの値が大きい実身を指す。
    (1.0.1 と 2.0.1 だったら 2.0.1 の方が最新)
    # この法則だと、最新のバージョンが最後に作られた実身とは限らない
    # ですね。

(2) バージョンを指定
    指定したバージョンの実身へのリンクを維持する。実身が更新されても、
    更新後の内容は参照しない(できない)。
    バージョンを指定後、そのバージョンの枝を作った場合には、その枝の最
    新のバージョンを指定する方法はない。
    (つまり、バージョン 1.0.2 という実身があった場合、1.0.x の最新とい
    うの方法で指定する方法はないということです。明示的に 1.0.2 という指
    定する必要がある)


API としては、どういうのが適当なんでしょう。
やっぱりリンクを作るときにバージョン番号を指定する引数を追加するのが
適当でしょうか。そうすると階層を無制限にした場合の指定方法が面倒のよ
うな。。。


> □うーん、時間等で古いバージョンを指定するとした場合、アクセスしたいバー
> □ジョンはいつの時間のものかを知っている必要があります。これって、あまり
> □期待できないような気がします。
> □間違って削除したファイルを回復したい時などはいいでしょうけど。。。
> 
>      そもそも、古いバージョンを参照したい時って、
> 
>         ・間違って削除した
>         ・リンク・マークされていないかどうか
> 
>     時くらいだと思うんですが……。逆に、どういう時に参照したいか
>     というのを考えた方がいいと思います。
> 
>      ぼくの立場としては、「古いバージョンをリンクする」のではな
>     く、「固定した結果古いバージョンがリンクされている」というの
>     を考えていますから。

もし、誤って実身を削除することを防止するだけだったら、最新のバージョン
だけを変更できて、それ以前のものは参照のみ許すだけにしてもいいですね。
で、削除すると一つ前のバージョンの実身が見えるようになると。
(本当に削除する時には、専用のプログラムを使うとか。。。)

あるいは、いっそのこと Macintosh/Windows95 のように削除した実身を別の
場所に移すようにするだけでもいいかも。。。

やはり、バージョン毎に実身を作るからには、削除防止だけでは動機として弱い
ですね。参照内容を固定するという岩間さんの考えは、バージョン機能を入れる
有力な動機のひとつだと思います。


p----------------------------------------------------------------------q
| FROM R.Night                                                         |
| E-mail:                                                              |
|         rnaitoh@st.rim.or.jp                                         |
b----------------------------------------------------------------------d