# Original revision: 1.24
# $Id: ROADMAP.jp.html,v 1.4 2003/03/04 10:20:06 hanai Exp $
APACHE 2.x ROADMAP
==================
Last modified at [$Date: 2003/03/04 10:20:06 $]
イントロダクション
------------
Apache HTTP Serverプロジェクトは相容れない2つの目的:
サードパーティモジュールの作者や配布者そして最も重要なユーザーに対し
バグやセキュリティホールの修正を大した障害なく素早く取り入れられるように
安定したコードを維持すること。初期の誤りを修正したり新機能を追加したり
するために再設計を必要とするような開発を続けること。この2つの間でうまく
バランスを取る必要がある。
Apache HTTPサーバーは、バージョン2.0において、モジュール・マジック・ナンバー(MMN)
を用いてAPIの変更がわかるようにしていた。この方法には、今や互換性のないサードパーティの
バイナリモジュールをユーザーが置き換えてまわらねばならない、という短所があった。
また、モジュールの作者は、MMNの変更において何が起きそれが自分のモジュールにどういう
影響を与えるのかということを調べてまわらなければならなかった。
Apache 2.2-stableとApache 2.3-developmentを同時にリリースすることにより、
Apache HTTPサーバープロジェクトはもっとわかりやすい安定版のリリースサイクル
を取りつつ安定版のブランチを壊す心配をすることなく開発を進めることができる。
このドキュメントはこれら2つのバージョンとそれらの役割などについて解説する。
STABLE RELEASES, 2.{even}.{revision}
------------------------------------
全ての偶数番号のリリースは安定版と考えられる。
安定版はできるだけ互換性を保つ。マイナーリビジョン間で新機能を付け加えること
があるかもしれないし、ドキュメントに明示することによりある機能を下げることが
あるかもしれない。しかし、機能を削ることはしない。
ここで言いたいのは、マイナーリビジョン間のアップグレードは最小限のトラブルで
行なうことができるということだ。これには特に次の意味がある:
* モジュールAPIは互換性を保つ。安定版ツリーの新しいリビジョンで
動かすためにモジュールまでアップデートする必要はない。
* 実行時設定は互換性を保つ。安定版の新しいリビジョンを動かす場合、
設定ファイルの変更は必要ない。
* コンパイル時の設定は互換性を保つ。あるリリースでのconfigureの
コマンドラインオプションは次のリリースでもそのまま使うことができる。
いつものように、新しいリリースを行なう時にはテストを行ない特定の設定ファイルと特定の
モジュールのセットで正しく動くことを保証する。しかし、全ての努力はアップグレードが
できるだけスムーズにできるよう保証することに向けられるだろう。
さらに、次のような開発における制限により、安定版のツリーはできるだけ安全に保たれる:
* 「実験的」なモジュールを入れない。(あるモジュールをサポートするために必要なAPIの
変更を元にすれば)2.3-developmentのモジュールを2.2-stableのApacheにロードすること
は可能かもしれないが、その保証はない。実験的なモジュールは2.3-developmentに入り、
安定性と互換性が証明されたら2.2-stableにも加えられる。もしくは、現在の安定版リリー
スに入れるにはAPIの変更が必要だということになれば2.4-stableのリリースまで見送る。
* 安定版のCVSツリーは、いついかなる時に不安定になってはいけない。開発版から安定版へ
コードも持ってくる時にはアトミックなコミットを行なう。どんな時にでも他の貢献者に
気付かれずにセキュリティーリリースが準備される。常に、テスターはバグが修正された
ことを確認するためにCVSのHEADをチェックアウトするかもしれない。そして、全てのコー
ドは安定版ツリーに入れる前に開発版で十分にテストされるため、安定版ツリーが数分間
の長いコミット以上の間壊れているという理由はなにもない。
安定版のリリースにおいて「飛ばされた」リリース番号を避けるため、リリースマネージャーは
APACHE_#_#_#_RC#というタグを付けてリリース候補をロールする。リリース候補のtarballは
stable-testers@httpd.apache.orgにアナウンスされる。そして、参加者がその品質について
投票を行なう。
最終的なAPACHE_#_#_#というタグはAPACHE_#_#_#_RC#候補がリリースのためのテストをパス
するまで存在しない。そして、全ての-rc#という名称を削除しリリース番号でタグを付ける
ことによって最終的なtarballができあがる。
DEVELOPMENT RELEASES, 2.{odd}.{revision}
-----------------------------------------
全ての奇数番号のリリースは「次の」安定リリースの候補であり、したがって最新の
開発バージョンは常に最新の安定版リリースよりも1つだけ大きい。開発リリース上で
開発が行なわれ、不足している機能や欠点を修正するためにいつでもMMNの変更が許さ
れている。つまり、ある開発リリースでのモジュールは別の開発リリースとはバイナリ
互換性を持っていなかったりAPIの変更に合わせないとコンパイルもできなかったりす
る。
常に、唯一の「サポートされる」開発リリースは最も最近リリースされたバージョン
である。開発者は、一旦新しいリリースが出ればそれよりも古いものに対するバグ方向
には答えない。責任を持ってある問題が存在すると言うためには、報告者は最新の
開発版を用いることになる。
どんな新しいコードや新しいAPIの機能、もしくは新しい(実験的な)モジュールは、
プロジェクトの参加者の投票により次の安定版リリースに入れられる。この投票は
新しいコードの技術的な安定性やインターフェイスの安定性に基いて行なわれる。
一旦安定版へ移動したら、その機能はその安定版リリースのサイクル中では変更する
ことができない。そのため、投票ではその新機能の動きや名前について最終的な
決定がなされたことを反映していなければならない。
開発ブランチでの変更の質がリリースに値すると考えられる時にはいつでも、その
開発版は次の安定リリースの候補と考えられる。これには、いくつかもしくは全て
のAPIの変更や実験的なモジュールの安定版への取り込み、古いモジュールの廃止や
削除といったものを含む。これらの選択はグループとしてのプロジェクトによって
考慮され、ある変更はグループによって次の安定版にリリースに入れてリスクを増
やすよりも将来のリリースまで「遅らせ」られることもある。
サードパーティモジュールの作者は、最新の開発版でテストすることを強く奨励される。
これは、モジュールが次の安定リリースに備えられていることを保証し、さらに重要な
こととして、安定版がリリースされる前に欠点や不備がある場合にdev@httpd.apache.org
というコミュニティへ十分早く警鐘を鳴らすことができる。ある新しい安定版のリリース
が始まれば、そのAPIはその安定版が続く限り保たれるのだ。安定版における変更を
強く要求しても、それが取り入れられるのは次のリリースサイクルまで待たなければ
ならない。
開発ツリーを安定版へ移す決定を行なう時には、最後の安定版のリリース以来の
変更がメジャー番号の変更に値するものかどうかによって決定されるべきである。
つまり、2.2が現在の安定版であり2.3が安定版としての用意が整ったとした時、
グループは次の安定版が2.4なのか3.0なのかを決定する。経験則としては、モジュール
を2.2から2.4へ移すのにかなりの努力を必要とする場合、次の安定版は3.0となる
べきである。
開発版のリリースを簡単に作れるようにするために、開発版リリースのパッケージング
は安定版よりも簡略化したものになる。この考え方は、開発途中においてはバージョン
というものにあまり価値がないことを表わしている。開発版のリリースは、その安定性
を反映してアルファ、ベータ、GAと区別されるかもしれない。開発版のリリースはいつ
でも全てのコミッターによって作成される。
開発版のストラテジーについてさらに詳しいことは次のURLを読んでください:
http://httpd.apache.org/dev/release.html
WORKS IN PROGRESS
-----------------
* Source code should follow style guidelines.
OK, we all agree pretty code is good. Probably best to clean this
up by hand immediately upon branching a 2.1 tree.
Status: Justin volunteers to hand-edit the entire source tree ;)
Justin says:
Recall when the release plan for 2.0 was written:
Absolute Enforcement of an "Apache Style" for code.
Watch this slip into 3.0.
David says:
The style guide needs to be reviewed before this can be done.
http://httpd.apache.org/dev/styleguide.html
The current file is dated April 20th 1998!
OtherBill offers:
It's survived since '98 because it's welldone :-) Suggest we
simply follow whatever is documented in styleguide.html as we
branch the next tree. Really sort of straightforward, if you
dislike a bit within that doc, bring it up on the dev@httpd
list prior to the next branch.
So Bill sums up ... let's get the code cleaned up in CVS head.
Remember, it just takes cvs diff -b (that is, --ignore-space-change)
to see the code changes and ignore that cruft. Get editing Justin :)
* revamp the input filter syntax to provide for ordering of
filters created with the Set{Input|Output}Filter and the
Add{Input|Output}Filter directives. A 'relative to filterx'
syntax is definately preferable.
* Platforms that do not support fork (primarily Win32 and AS/400)
Architect start-up code that avoids initializing all the modules
in the parent process on platforms that do not support fork.
. Better yet - not only inform the startup of which phase it's in,
but allow the parent 'process' to initialize shared memory, etc,
and create a module-by-module stream to pass to the child, so the
parent can actually arbitrate the important stuff.
* Replace stat [deferred open] with open/fstat in directory_walk.
Justin, Ian, OtherBill all interested in this. Implies setting up
the apr_file_t member in request_rec, and having all modules use
that file, and allow the cleanup to close it [if it isn't a shared,
cached file handle.]
* The Async Apache Server implemented in terms of APR.
[Bill Stoddard's pet project.]
Message-ID: <008301c17d42$9b446970$01000100@sashimi> (dev@apr)
OtherBill notes that this can proceed in two parts...
Async accept, setup, and tear-down of the request
e.g. dealing with the incoming request headers, prior to
dispatching the request to a thread for processing.
This doesn't need to wait for a 2.x/3.0 bump.
Async delegation of the entire request processing chain
Too many handlers use stack storage and presume it is
available for the life of the request, so a complete
async implementation would need to happen 3.0 release.
* Add a string "class" that combines a char* with a length
and a reference count. This will help reduce the number
of strlen and strdup operations during request processing.
Including both the length and allocation will save us a ton
of reallocation we do today, in terms of string manipulation.
OtherBill asks if this is really an APR issue, not an HTTPD issue?
MAKING APACHE REPOSITORY-AGNOSTIC
(or: remove knowledge of the filesystem)
[ 2002/10/01: discussion in progress on items below; this isn't
planned yet ]
* dav_resource concept for an HTTP resource ("ap_resource")
* r->filename, r->canonical_filename, r->finfo need to
disappear. All users need to use new APIs on the ap_resource
object.
(backwards compat: today, when this occurs with mod_dav and a
custom backend, the above items refer to the topmost directory
mapped by a location; e.g. docroot)
Need to preserve a 'filename'-like string for mime-by-name
sorts of operations. But this only needs to be the name itself
and not a full path.
Justin: Can we leverage the path info, or do we not trust the
user?
gstein: well, it isn't the "path info", but the actual URI of
the resource. And of course we trust the user... that is
the resource they requested.
dav_resource->uri is the field you want. path_info might
still exist, but that portion might be related to the
CGI concept of "path translated" or some other further
resolution.
To continue, I would suggest that "path translated" and
having *any* path info is Badness. It means that you did
not fully resolve a resource for the given URI. The
"abs_path" in a URI identifies a resource, and that
should get fully resolved. None of this "resolve to
and then we have a magical second resolution
(inside the CGI script)" or somesuch.
Justin: Well, let's consider mod_mbox for a second. It is sort of
a virtual filesystem in its own right - as it introduces
it's own notion of a URI space, but it is intrinsically
tied to the filesystem to do the lookups. But, for the
portion that isn't resolved on the file system, it has
its own addressing scheme. Do we need the ability to
layer resolution?
* The translate_name hook goes away
Wrowe altogether disagrees. translate_name today even operates
on URIs ... this mechansim needs to be preserved.
* The doc for map_to_storage is totally opaque to me. It has
something to do with filesystems, but it also talks about
security and per_dir_config and other stuff. I presume something
needs to happen there -- at least better doc.
Wrowe agrees and will write it up.
* The directory_walk concept disappears. All configuration is
tagged to Locations. The "mod_filesystem" module might have some
internal concept of the same config appearing in multiple
places, but that is handled internally rather than by Apache
core.
Wrowe suggests this is wrong, instead it's private to filesystem
requests, and is already invoked from map_to_storage, not the core
handler. and blocks are preserved as-is,
but sections become specific to the filesystem handler
alone. Because alternate filesystem schemes could be loaded, this
should be exposed, from the core, for other file-based stores to
share. Consider an archive store where the layers become
-> ->
Justin: How do we map Directory entries to Locations?
* The "Location tree" is an in-memory representation of the URL
namespace. Nodes of the tree have configuration specific to that
location in the namespace.
Something like:
typedef struct {
const char *name; /* name of this node relative to parent */
struct ap_conf_vector_t *locn_config;
apr_hash_t *children; /* NULL if no child configs */
} ap_locn_node;
The following config:
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
Creates a node with name=="server_status", and the node is a
child of the "/" node. (hmm. node->name is redundant with the
hash key; maybe drop node->name)
In the config vector, mod_access has stored its Order, Deny, and
Allow configs. mod_core has stored the SetHandler.
During the Location walk, we merge the config vectors normally.
Note that an Alias simply associates a filesystem path (in
mod_filesystem) with that Location in the tree. Merging
continues with child locations, but a merge is never done
through filesystem locations. Config on a specific subdir needs
to be mapped back into the corresponding point in the Location
tree for proper merging.
* Config is parsed into a tree, as we did for the 2.0 timeframe,
but that tree is just a representation of the config (for
multiple runs and for in-memory manipulation and usage). It is
unrelated to the "Location tree".
* Calls to apr_file_io functions generally need to be replaced
with operations against the ap_resource. For example, rather
than calling apr_dir_open/read/close(), a caller uses
resource->repos->get_children() or somesuch.
Note that things like mod_dir, mod_autoindex, and mod_negotation
need to be converted to use these mechanisms so that their
functions will work on logical repositories rather than just
filesystems.
* How do we handle CGI scripts? Especially when the resource may
not be backed by a file? Ideally, we should be able to come up
with some mechanism to allow CGIs to work in a
repository-independent manner.
- Writing the virtual data as a file and then executing it?
- Can a shell be executed in a streamy manner? (Portably?)
- Have an 'execute_resource' hook/func that allows the
repository to choose its manner - be it exec() or whatever.
- Won't this approach lead to duplication of code? Helper fns?
gstein: PHP, Perl, and Python scripts are nominally executed by
a filter inserted by mod_php/perl/python. I'd suggest
that shell/batch scripts are similar.
But to ask further: what if it is an executable
*program* rather than just a script? Do we yank that out
of the repository, drop it onto the filesystem, and run
it? eeewwwww...
I'll vote -0.9 for CGIs as a filter. Keep 'em handlers.
Justin: So, do we give up executing CGIs from virtual repositories?
That seems like a sad tradeoff to make. I'd like to have
my CGI scripts under DAV (SVN) control.
* How do we handle overlaying of Location and Directory entries?
Right now, we have a problem when /cgi-bin/ is ScriptAlias'd and
mod_dav has control over /. Some people believe that /cgi-bin/
shouldn't be under DAV control, while others do believe it
should be. What's the right strategy?