You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@bellsouth.net> on 2000/03/23 01:05:51 UTC
OS/390-, BS2000-, and TPF-specific files
(These comments definitely do NOT apply to 1.x!)
I hope these notes take into account most/all of the ideas people
expressed, but I must admit that there was a big cloud of dust and it
is hard to find any consensus.
Anybody disagree with (and why):
. move translation tables and a function to translate to APR
We could have some concept of default translation table for now (in
case they are different). Eventually, users may want to tell Apache
what translation to perform, at which point we need to select the
translation table. At that point it would be helpful if the native
translation support (e.g., iconv() on OS/390) can be used to load
the table, so that the user can deploy existing tools to build
custom tables.
The exact form of the APR support needs more thought. It could be
extremely simple :)
. move general EBCDIC support (code used to decide when to do it) out
of os/bs2000, os/tpf, and os/os390 into main/http_ebcdic.c or
similar
. move the OS/390-specific xebcdic.sh extraction script (and any
future build scripts which may be needed just for OS/390 or for any
other platform) to the src directory
That will leave the uninteresting os-inline.c in each of those
directories. Does anyone know why these platforms have their own
os-inline.c with the single function ap_os_is_path_absolute()?
Doesn't that sound like APR material?
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: OS/390-, BS2000-, and TPF-specific files
Posted by Jeff Trawick <tr...@bellsouth.net>.
> Tables don't work on all platforms. Specifically, AS/400 has repeatedly
> said they can't just use tables.
Oops... Rob? What is implemented now? If you need to have non-SBCS
working in the next few months, then I won't be so gung ho on the
simplest possible solution. If it is a theoretical need for the
future, then OS/390 is in the same boat, though for OS/390 I'd expect
that nobody cares until Apache runs very well in general.
> > . move general EBCDIC support (code used to decide when to do it) out
> > of os/bs2000, os/tpf, and os/os390 into main/http_ebcdic.c or
> > similar
>
> This is waiting for somebody to do it. I thought we had decided this was
> the right way to go months ago, but nobody has done it yet.
I think someone here in RTP is itching to get 2.0 running on
OS/390... We'll take care of that then, assuming that the other
two platforms haven't gotten there first or come up with something
better. The best suggestion so far is util_ebcdic.c.
There is always the opportunity for other EBCDIC folks to speak
up here.
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: OS/390-, BS2000-, and TPF-specific files
Posted by rb...@apache.org.
> . move translation tables and a function to translate to APR
>
> We could have some concept of default translation table for now (in
> case they are different). Eventually, users may want to tell Apache
> what translation to perform, at which point we need to select the
> translation table. At that point it would be helpful if the native
> translation support (e.g., iconv() on OS/390) can be used to load
> the table, so that the user can deploy existing tools to build
> custom tables.
>
> The exact form of the APR support needs more thought. It could be
> extremely simple :)
Tables don't work on all platforms. Specifically, AS/400 has repeatedly
said they can't just use tables.
> . move general EBCDIC support (code used to decide when to do it) out
> of os/bs2000, os/tpf, and os/os390 into main/http_ebcdic.c or
> similar
This is waiting for somebody to do it. I thought we had decided this was
the right way to go months ago, but nobody has done it yet.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: OS/390-, BS2000-, and TPF-specific files
Posted by Greg Stein <gs...@lyra.org>.
On Wed, 22 Mar 2000, Jeff Trawick wrote:
>...
> . move translation tables and a function to translate to APR
+1
I agree with APR support here because different platforms have different
facilities. iconv() on some, Win32 has some, etc.
> We could have some concept of default translation table for now (in
> case they are different). Eventually, users may want to tell Apache
> what translation to perform, at which point we need to select the
> translation table. At that point it would be helpful if the native
> translation support (e.g., iconv() on OS/390) can be used to load
> the table, so that the user can deploy existing tools to build
> custom tables.
(and load into shared memory so the process memory footprint isn't bloated
by translation tables...0
> The exact form of the APR support needs more thought. It could be
> extremely simple :)
When I brought up some of the translation stuff with Ryan, he was pretty
ambivalent about what/how it should work. I sense that I received was,
"hey... I'm not too fussed about this; whoever gets to coding the real
stuff is free to define the 'proper' interfaces."
> . move general EBCDIC support (code used to decide when to do it) out
> of os/bs2000, os/tpf, and os/os390 into main/http_ebcdic.c or
> similar
The EBCDIC is unrelated to http, so (IMO) this would be util_ebcdic.c. It
definitely seems to be used in a few places, so having multiple copies
seems prone to error. Platform-specific defines in util_ebcdic.c can
handle the minor codepage variances that somebody mentioned earlier.
> . move the OS/390-specific xebcdic.sh extraction script (and any
> future build scripts which may be needed just for OS/390 or for any
> other platform) to the src directory
I think this would go into src/helpers. Maybe src/support. I really don't
think it would go directly into src/ though.
> That will leave the uninteresting os-inline.c in each of those
> directories. Does anyone know why these platforms have their own
> os-inline.c with the single function ap_os_is_path_absolute()?
> Doesn't that sound like APR material?
Yes, it does sound like APR material, along with filename
canonicalization. Bill mentioned a reason why canon filenames might be
Apache-specific, but I'm not sure that I agree with that.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/