Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #34976 > unrolled thread

Disappearing API docs

Back to article view | Back to comp.lang.java.programmer

Contents

  Disappearing API docs Roedy Green <inquiry@mindprod.com> - 2016-07-19 06:46 -0700
    Re: Disappearing API docs Eric Douglas <e.d.programmer@gmail.com> - 2016-07-19 06:54 -0700
      Re: Disappearing API docs Lew <lewbloch@gmail.com> - 2016-07-19 10:36 -0700
        Re: Disappearing API docs Roedy Green <inquiry@mindprod.com> - 2016-07-19 12:23 -0700
          Re: Disappearing API docs Eric Douglas <e.d.programmer@gmail.com> - 2016-07-19 12:49 -0700
            Re: Disappearing API docs Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-19 20:31 +0000
              Re: Disappearing API docs Eric Douglas <e.d.programmer@gmail.com> - 2016-07-19 13:59 -0700
                Re: Disappearing API docs Lew <lewbloch@gmail.com> - 2016-07-19 14:52 -0700
                Re: Disappearing API docs Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-19 22:03 +0000
                  Re: Disappearing API docs Eric Douglas <e.d.programmer@gmail.com> - 2016-07-20 05:36 -0700
                    Re: Disappearing API docs Nigel Wade <nmw@local.domain> - 2016-07-20 17:10 +0100
                      Re: Disappearing API docs Eric Douglas <e.d.programmer@gmail.com> - 2016-07-20 10:39 -0700
                        Re: Disappearing API docs Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-20 13:59 -0400
                          Re: Disappearing API docs Eric Douglas <e.d.programmer@gmail.com> - 2016-07-20 11:08 -0700
                            Re: Disappearing API docs Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-20 21:55 +0000
                            Re: Disappearing API docs Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-07-20 18:19 -0400
                          Re: Disappearing API docs Arne Vajhøj <arne@vajhoej.dk> - 2016-07-22 13:31 -0400
                        Re: Disappearing API docs Nigel Wade <nmw@local.domain> - 2016-07-21 10:08 +0100
                        Re: Disappearing API docs Arne Vajhøj <arne@vajhoej.dk> - 2016-07-22 13:30 -0400
                    Re: Disappearing API docs Arne Vajhøj <arne@vajhoej.dk> - 2016-07-22 13:16 -0400
                      Re: Disappearing API docs Gene Wirchenko <genew@telus.net> - 2016-07-22 15:24 -0700
                        Re: Disappearing API docs Lew <lewbloch@gmail.com> - 2016-07-22 15:34 -0700
                        Re: Disappearing API docs Arne Vajhøj <arne@vajhoej.dk> - 2016-07-22 19:29 -0400
                          Re: Disappearing API docs Gene Wirchenko <genew@telus.net> - 2016-07-23 21:45 -0700
                            Re: Disappearing API docs Arne Vajhøj <arne@vajhoej.dk> - 2016-07-30 22:33 -0400
                              Re: Disappearing API docs Gene Wirchenko <genew@telus.net> - 2016-08-02 11:07 -0700
                                Re: Disappearing API docs Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-08-02 14:26 -0400
                                  Re: Disappearing API docs Gene Wirchenko <genew@telus.net> - 2016-08-02 15:53 -0700
                                Re: Disappearing API docs Arne Vajhøj <arne@vajhoej.dk> - 2016-08-03 21:55 -0400
                Re: Disappearing API docs Arne Vajhøj <arne@vajhoej.dk> - 2016-07-19 20:43 -0400
            Re: Disappearing API docs Arne Vajhøj <arne@vajhoej.dk> - 2016-07-19 20:40 -0400
              Re: Disappearing API docs Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-20 11:45 +0000
                Re: Disappearing API docs Arne Vajhøj <arne@vajhoej.dk> - 2016-07-20 08:47 -0400
                  Re: Disappearing API docs Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-20 18:44 +0000
    Re: Disappearing API docs Arne Vajhøj <arne@vajhoej.dk> - 2016-07-19 20:24 -0400

Page 2 of 2 — ← Prev page 1 [2]

#35094

On Fri, 22 Jul 2016 13:16:31 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>On 7/20/2016 8:36 AM, Eric Douglas wrote:

[snip]

>> I have worked with unix before, I am aware of case sensitive
>> systems. I was not previously aware that a web server would allow
>> case sensitive, as I'm sure I've never encountered one before.
>> Unless you want to obscure your publicly available data making it
>> hard for anyone to get to without a link it doesn't make sense.
>
>It does not matter for links.

     It does matter.  Try the following links:
          https://en.wikipedia.org/wiki/Kyoto
          https://en.wikipedia.org/wiki/KyotO
The only difference is the final character.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#35096

Gene Wirchenko wrote:
> Arne Vajhøj wrote:
> 
> >On 7/20/2016 8:36 AM, Eric Douglas wrote:
> 
> [snip]
> 
> >> I have worked with unix before, I am aware of case sensitive
> >> systems. I was not previously aware that a web server would allow
> >> case sensitive, as I'm sure I've never encountered one before.
> >> Unless you want to obscure your publicly available data making it
> >> hard for anyone to get to without a link it doesn't make sense.
> >
> >It does not matter for links.
> 
>      It does matter.  Try the following links:
>           https://en.wikipedia.org/wiki/Kyoto
>           https://en.wikipedia.org/wiki/KyotO
> The only difference is the final character.

Arne is the one saying that the path part of a URL is case sensitive, so no disagreement there.

You misinterpreted Arne's remark. He's saying that the user needn't worry about case because the link already has the correct case. It doesn't matter that the file system is case sensitive because you aren't typing in the file name, is what he said. You just proved Arne correct, Gene.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#35097

On 7/22/2016 6:24 PM, Gene Wirchenko wrote:
> On Fri, 22 Jul 2016 13:16:31 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote:
>> On 7/20/2016 8:36 AM, Eric Douglas wrote:
>>> I have worked with unix before, I am aware of case sensitive
>>> systems. I was not previously aware that a web server would allow
>>> case sensitive, as I'm sure I've never encountered one before.
>>> Unless you want to obscure your publicly available data making it
>>> hard for anyone to get to without a link it doesn't make sense.
>>
>> It does not matter for links.
>
>      It does matter.  Try the following links:
>           https://en.wikipedia.org/wiki/Kyoto
>           https://en.wikipedia.org/wiki/KyotO
> The only difference is the final character.

Q: What does not matter for links mean?
A1) That URL's work no matter case.
A2) That it is not a problem to get case correct.

You get one guess.

It is even allowed to read the next paragraph that
you did not quote:

#People typing in URL's manually are supposed to know that
#while protocol and hostnames are not case sensitive then
#the other parts of URL's may be.

Arne

[toc] | [prev] | [next] | [standalone]

#35123

On Fri, 22 Jul 2016 19:29:02 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>On 7/22/2016 6:24 PM, Gene Wirchenko wrote:
>> On Fri, 22 Jul 2016 13:16:31 -0400, Arne Vajhøj <arne@vajhoej.dk>
>> wrote:
>>> On 7/20/2016 8:36 AM, Eric Douglas wrote:
>>>> I have worked with unix before, I am aware of case sensitive
>>>> systems. I was not previously aware that a web server would allow
>>>> case sensitive, as I'm sure I've never encountered one before.
>>>> Unless you want to obscure your publicly available data making it
>>>> hard for anyone to get to without a link it doesn't make sense.
>>>
>>> It does not matter for links.
>>
>>      It does matter.  Try the following links:
>>           https://en.wikipedia.org/wiki/Kyoto
>>           https://en.wikipedia.org/wiki/KyotO
>> The only difference is the final character.
>
>Q: What does not matter for links mean?
>A1) That URL's work no matter case.
>A2) That it is not a problem to get case correct.
>
>You get one guess.
>
>It is even allowed to read the next paragraph that
>you did not quote:
>
>#People typing in URL's manually are supposed to know that
>#while protocol and hostnames are not case sensitive then
>#the other parts of URL's may be.

     Are they?  When do most people get told this?  And even if they
know this, who knows what an individual Website does?

     For example, Wikipedia appears to not care about the case of the
first letter of each word but does care about the case of the other
letters.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#35154

On 7/24/2016 12:45 AM, Gene Wirchenko wrote:
> On Fri, 22 Jul 2016 19:29:02 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote:
>> #People typing in URL's manually are supposed to know that
>> #while protocol and hostnames are not case sensitive then
>> #the other parts of URL's may be.
>
>      Are they?  When do most people get told this?

Those people can either do it the easy way and read about it
or the hard way and notice that sometimes it does not work
and figure out why.

>                                         And even if they
> know this, who knows what an individual Website does?

It does not matter.

Assuming that URL's are case sensitive will always work.

>      For example, Wikipedia appears to not care about the case of the
> first letter of each word but does care about the case of the other
> letters.

Wikipedia uses MySQL and ElasticSearch, which must have way
more advanced match options than a standard web server
and file system provides.

Arne

[toc] | [prev] | [next] | [standalone]

#35171

On Sat, 30 Jul 2016 22:33:08 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>On 7/24/2016 12:45 AM, Gene Wirchenko wrote:
>> On Fri, 22 Jul 2016 19:29:02 -0400, Arne Vajhøj <arne@vajhoej.dk>
>> wrote:
>>> #People typing in URL's manually are supposed to know that
>>> #while protocol and hostnames are not case sensitive then
>>> #the other parts of URL's may be.
>>
>>      Are they?  When do most people get told this?
>
>Those people can either do it the easy way and read about it
>or the hard way and notice that sometimes it does not work
>and figure out why.

     Or get confused.

     Again, when do most people get told or find out?  Just us
technical people knowing is not really enough.

>>                                         And even if they
>> know this, who knows what an individual Website does?
>
>It does not matter.
>
>Assuming that URL's are case sensitive will always work.

     Sure.  And since assuming that URLs are not case-sensitive will
almost always work, a lot of people may have never learned and they
have saved a lot of fussing over case.  They just conclude that there
is something wrong with those odd Websites.  From a usability poit of
view, they are right.

>>      For example, Wikipedia appears to not care about the case of the
>> first letter of each word but does care about the case of the other
>> letters.
>
>Wikipedia uses MySQL and ElasticSearch, which must have way
>more advanced match options than a standard web server
>and file system provides.

     How do you think the non-technical Web user is going to view
this?

Sincerely,

Gene Wirchenkko

[toc] | [prev] | [next] | [standalone]

#35173

On 8/2/2016 2:07 PM, Gene Wirchenko wrote:
> On Sat, 30 Jul 2016 22:33:08 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote:
>
>> On 7/24/2016 12:45 AM, Gene Wirchenko wrote:
>>> On Fri, 22 Jul 2016 19:29:02 -0400, Arne Vajhøj <arne@vajhoej.dk>
>>> wrote:
>>>> #People typing in URL's manually are supposed to know that
>>>> #while protocol and hostnames are not case sensitive then
>>>> #the other parts of URL's may be.
>>>
>>>      Are they?  When do most people get told this?
>>
>> Those people can either do it the easy way and read about it
>> or the hard way and notice that sometimes it does not work
>> and figure out why.
>
>      Or get confused.
>
>      Again, when do most people get told or find out?  Just us
> technical people knowing is not really enough.

     What percentage of Web page visits do you imagine begin with
the visitor typing a URL?  As opposed to, say, clicking on a link
or a bookmark or an "Add to Cart" button, or copying and pasting?

     For myself, I type in my browser's Search box often, in its
address bar almost never.  YMmV.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#35179

On Tue, 2 Aug 2016 14:26:02 -0400, Eric Sosman
<esosman@comcast-dot-net.invalid> wrote:

[snip]

>     What percentage of Web page visits do you imagine begin with
>the visitor typing a URL?  As opposed to, say, clicking on a link
>or a bookmark or an "Add to Cart" button, or copying and pasting?

     I do not know.  Anyone with an answer is guessing.

     Sometimes, URLs get mangled (say, split into more than one line),
and this might prompt some adjusting.

     I do a bit of experimenting sometimes trying to get a to a page.

>     For myself, I type in my browser's Search box often, in its
>address bar almost never.  YMmV.

     I do quite frequently, but this is almost always using my
browsers suggestions for completions.  As to raw, often enough that is
not rare, but not commonly.

     So, if it does happen that case gives trouble, it is rather
infrequent and understandable that someone not know.  This is like
looking at that code you wrote last year but have not looked at since
until now.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#35189

On 8/2/2016 2:07 PM, Gene Wirchenko wrote:
> On Sat, 30 Jul 2016 22:33:08 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote:
>> On 7/24/2016 12:45 AM, Gene Wirchenko wrote:
>>> On Fri, 22 Jul 2016 19:29:02 -0400, Arne Vajhøj <arne@vajhoej.dk>
>>> wrote:
>>>> #People typing in URL's manually are supposed to know that
>>>> #while protocol and hostnames are not case sensitive then
>>>> #the other parts of URL's may be.
>>>
>>>      Are they?  When do most people get told this?
>>
>> Those people can either do it the easy way and read about it
>> or the hard way and notice that sometimes it does not work
>> and figure out why.
>
>      Or get confused.
>
>      Again, when do most people get told or find out?  Just us
> technical people knowing is not really enough.

The above applies to all people not just technical people.

>
>>>                                         And even if they
>>> know this, who knows what an individual Website does?
>>
>> It does not matter.
>>
>> Assuming that URL's are case sensitive will always work.
>
>      Sure.  And since assuming that URLs are not case-sensitive will
> almost always work,

But that is a wrong assumption.

Case sensitive is the default in the most popular web server
on the most popular OS.

Assuming that you will not encounter the the most popular web server
on the most popular OS in default setup is unrealistic.

Just for fun I let a program check URL's in my bookmarks file.

Out if the first 100 that returned code 200 and had a path longer
than 1, then for path 37 was case sensitive and 63 was case insensitive.

>>>      For example, Wikipedia appears to not care about the case of the
>>> first letter of each word but does care about the case of the other
>>> letters.
>>
>> Wikipedia uses MySQL and ElasticSearch, which must have way
>> more advanced match options than a standard web server
>> and file system provides.
>
>      How do you think the non-technical Web user is going to view
> this?

The non-technical user will just learn to type the URL case
sensitive.

Arne

[toc] | [prev] | [next] | [standalone]

#34997

On 7/19/2016 4:59 PM, Eric Douglas wrote:
> On Tuesday, July 19, 2016 at 4:32:08 PM UTC-4, Martin Gregorie wrote:
>> If the underlying OS is case sensitive then, unless the webserver has
>> been configured to be caseless, pathnames following the host name are
>> also case sensitive. I'm not aware of any deviation from this.
>>
>>> https://www.google.com/ is a valid web site.
>>> https://www.gOOglE.coM/ redirects to https://www.google.com/
>>> https://yAhOo.CoM redirects to https://www.yahoo.com/
>>>
>> But these examples are unsurprising because DNS is by definition case-
>> agnostic, so all three of these should 'just work' - and they do,
>> regardless of whether you use ping or a webbrowser to test that.
>
> I'm not sure what you mean, how that's any different, but it seems
 > to me if I take any url and capitalize any of the letters I end up in
 > the same place.  I tested this one for instance.
>
> http://www.npr.org/2016/07/18/486464177/zero-days-documentary-exposes-a-looming-threat-of-the-digital-age

The fact that one site is totally case in-sensitive does not require
all sites to be.

Arne

[toc] | [prev] | [next] | [standalone]

#34996

On 7/19/2016 3:49 PM, Eric Douglas wrote:
> On Tuesday, July 19, 2016 at 3:23:48 PM UTC-4, Roedy Green wrote:
>> Put it this way, I had all kinds of reference in my website with
>> Javase.  My link checker warns me of broken links after failing 5
>> days.  It went off this morning. Perhaps Oracle have just stopped
>> accepting Javase as an alternate.
>
> It does seem odd.  I put these in Chrome:
> http://docs.oracle.com/javase/8/docs/api/ is a valid web site.
> http://docs.oracle.com/Javase/8/docs/api/ is not a valid web site.
> https://www.google.com/ is a valid web site.
> https://www.gOOglE.coM/ redirects to https://www.google.com/
> https://yAhOo.CoM redirects to https://www.yahoo.com/
>
> FTP paths would be case sensitive if the server is unix based.  I didn't think web sites were.

Hostnames are not case sensitive.

RFC 952 for host names say:

"No distinction is made between upper and lower case."

RFC 3986 for URI's say:

"Although host is case-insensitive, producers and normalizers
should use lowercase for registered names"

Paths may be case sensitive.

https://www.w3.org/TR/WD-html40-970708/htmlweb.html

say:

"URLs in general are case-sensitive (with the exception of machine
names). There may be URLs, or parts of URLs, where case doesn't matter,
but identifying these may not be easy. Users should always consider
that URLs are case-sensitive."

I think that in practice path is case sensitive when mapped
to a case sensitive file system and case in-sensitive when
mapped to a case in-sensitive file system.

It is just practical.

Assume you have a dir with:

x.html
X.html

For case sensitive path then it is easy:

http://blabla/x.html gets x.html
http://blabla/X.html gets X.html

For case in-sensitive path then I am not sure
what these URL's should return:

http://blabla/x.html
http://blabla/X.html

Arne

[toc] | [prev] | [next] | [standalone]

#35005

On Tue, 19 Jul 2016 20:40:30 -0400, Arne Vajhøj wrote:

> On 7/19/2016 3:49 PM, Eric Douglas wrote:
>> On Tuesday, July 19, 2016 at 3:23:48 PM UTC-4, Roedy Green wrote:
>>> Put it this way, I had all kinds of reference in my website with
>>> Javase.  My link checker warns me of broken links after failing 5
>>> days.  It went off this morning. Perhaps Oracle have just stopped
>>> accepting Javase as an alternate.
>>
>> It does seem odd.  I put these in Chrome:
>> http://docs.oracle.com/javase/8/docs/api/ is a valid web site.
>> http://docs.oracle.com/Javase/8/docs/api/ is not a valid web site.
>> https://www.google.com/ is a valid web site.
>> https://www.gOOglE.coM/ redirects to https://www.google.com/
>> https://yAhOo.CoM redirects to https://www.yahoo.com/
>>
>> FTP paths would be case sensitive if the server is unix based.  I
>> didn't think web sites were.
> 
> Hostnames are not case sensitive.
> 
> RFC 952 for host names say:
> 
> "No distinction is made between upper and lower case."
> 
> RFC 3986 for URI's say:
> 
> "Although host is case-insensitive, producers and normalizers should use
> lowercase for registered names"
> 
> Paths may be case sensitive.
> 
> https://www.w3.org/TR/WD-html40-970708/htmlweb.html
> 
> say:
> 
> "URLs in general are case-sensitive (with the exception of machine
> names). There may be URLs, or parts of URLs, where case doesn't matter,
> but identifying these may not be easy. Users should always consider that
> URLs are case-sensitive."
> 
> I think that in practice path is case sensitive when mapped to a case
> sensitive file system and case in-sensitive when mapped to a case
> in-sensitive file system.
> 
> It is just practical.
> 
> Assume you have a dir with:
> 
> x.html X.html
> 
> For case sensitive path then it is easy:
> 
> http://blabla/x.html gets x.html http://blabla/X.html gets X.html
> 
> For case in-sensitive path then I am not sure what these URL's should
> return:
> 
> http://blabla/x.html http://blabla/X.html
>
They both return the same file because there's only the one item in a 
case agnostic filing system. It should be selected regardless of the case 
used to do so.

The following is based on the behaviour of Microware's OS/9, formerly 
quite a popular real-time OS, but I'm pretty sure that all case-
insensitive OSes would work the same way.

OS/9 allows you to use upper,lower or mixed case to name a new file or 
directory and gives it the name exactly as typed, but it does caseless 
comparisons when looking for an existing file or directory. The common 
convention was to use UPPER-CASE for naming directories and lower case 
for naming files and devices. Since directory listings are always 
lexicographically sorted, this means that directories will appear first, 
followed by files. However, commands that reference existing files and 
directories can be written entirely in lower case.

HTH


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#35007

On 7/20/2016 7:45 AM, Martin Gregorie wrote:
> On Tue, 19 Jul 2016 20:40:30 -0400, Arne Vajhøj wrote:
>> Assume you have a dir with:
>>
>> x.html X.html
>>
>> For case sensitive path then it is easy:
>>
>> http://blabla/x.html gets x.html http://blabla/X.html gets X.html
>>
>> For case in-sensitive path then I am not sure what these URL's should
>> return:
>>
>> http://blabla/x.html http://blabla/X.html
>>
> They both return the same file because there's only the one item in a
> case agnostic filing system. It should be selected regardless of the case
> used to do so.

The assumption was that you had two files.

Arne

[toc] | [prev] | [next] | [standalone]

#35014

On Wed, 20 Jul 2016 08:47:02 -0400, Arne Vajhøj wrote:

> On 7/20/2016 7:45 AM, Martin Gregorie wrote:
>> On Tue, 19 Jul 2016 20:40:30 -0400, Arne Vajhøj wrote:
>>> Assume you have a dir with:
>>>
>>> x.html X.html
>>>
>>> For case sensitive path then it is easy:
>>>
>>> http://blabla/x.html gets x.html http://blabla/X.html gets X.html
>>>
>>> For case in-sensitive path then I am not sure what these URL's should
>>> return:
>>>
>>> http://blabla/x.html http://blabla/X.html
>>>
>> They both return the same file because there's only the one item in a
>> case agnostic filing system. It should be selected regardless of the
>> case used to do so.
> 
> The assumption was that you had two files.
> 
Sure - for a case sensitive filing system. 

I'm far from certain that a caseless filing system can ever hold two 
files whose names differ only in the case of one or more characters. 
If you try that with OS/9:, here's what happens:

/dd/DEV/C : echo file >x.txt; cat x.txt; echo File-X >X.txt; cat x.txt
file
File-X
/dd/DEV/C : 

In other words, the first echo wrote 'file' to x.txt. The second echo 
discovered that a file whose name matches X.txt already existed and so it 
overwrote the original file. 

This is exactly how I'd expect any case-agnostic filing system to work. 
Anything else would be quite confusing to use.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#34995

On 7/19/2016 9:46 AM, Roedy Green wrote:
> Oracle has renamed the files that form the Java API Java doc.
>
> https://docs.oracle.com/Javase/8/docs/api/java/util/zip/ZipEntry.html
> is now
> https://docs.oracle.com/javase/8/docs/api/java/util/zip/ZipEntry.html
>
> Oracle's server is case-sensitive.

No surprise in that.

Very common.

Arne

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web