[545] in java-interest
Re: Cannonical name for JAVA classes - further thoughts
daemon@ATHENA.MIT.EDU (Douglas Barnes)
Thu Jun 29 20:48:36 1995
Date: Thu, 29 Jun 1995 16:26:21 -0800
To: James C Deikun <jcdst10+@pitt.edu>
From: cman@communities.com (Douglas Barnes)
Cc: java-interest@java.sun.com
Not only would using Internet domain names lead to grief
because of mapping problems (domain names don't necessarily
map neatly onto Java development entities), but they can be
pretty bulky for the task.
Take for example, a domainname that recently crossed my desk...
let's say the folks at psychology.nottingham.ac.uk did a package
with parts. Their full class names would be:
uk.ac.nottingham.psychology.package.part.ClassName
That's about 40 characters of package name. Yecch. Also note
that given the tools, the files would need to reside in:
.../classes/uk/ac/nottingham/psychology/package/part/...
Also yecch. I vote for some other approach for registering
top-level package names.
James C. Deikun wrote:
>On Wed, 28 Jun 1995, Dr_George_D_Detlefsen wrote:
>
>> Yesterday, I suggested that a full cannonical name for a JAVA class
>> might be composed of an fully qualified Internet domain name plus
>> components local to that domain.
>
>What if the class is made by an individual, and that individual
>wants or needs to change providers? What if two of the many completely
>unrelated people at netcom.com want to use the same local part?
>
>> This morning in the shower, it occurred to me that a good extension
>> of the classloader would be to check the first component of the
>> class name for a match against the DNS top level domains, ie. com,
>> edu, us, jp, uk, .... If there was a match, it would search the
>> DNS space for the longest string of name components that a hostname
>> lookup succeded for. It would then make a TCP connection to the
>> 'javad' daemon on a well known port on that host. It would then
>> send the remaining portion of the class name to the 'javad', which
>> would then look up the class in its directory structure and send
>> the .class file back thru the TCP socket. This would give world wide
>> access to reuseable class libraries for the cost of implementing
>> a extension to 'hotjava.src/src/share/java/runtime/classloader.c'
>> and a relatively simple 'javad' daemon process.
>
>Tying name to location to a greater than necessary degree is a bad idea.
>What if someone's site can't handle the stress and they want to use
>mirrors, but they don't have that kind of control over their nameservice
>(i.e. an individual college student with a net-connected PC)?
>
>This won't really solve any more problems than it would cause.
>Organization/company name conflicts are more or less a nonproblem anyway,
>since these are strongly discouraged all over for tons of business, PR,
>and legal reasons.
>
>And if the company/organization wants to subdivide this further, they are
>perfectly capable of using further (opaque) name components defined by
>internal policy.
>
>--
>James "edu.pitt.unless.i.quit?" Deikun
>"Frankly, if it's not good enough for K.C. Harper, it's not good enough
>for you." -- Pittsburgh area used car dealership commercial
>-
>Note to Sun employees: this is an EXTERNAL mailing list!
>Info: send 'help' to java-interest-request@java.sun.com
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
