Heated discussion is running on nbdev right now.  I attach the more
informative message

From: Svatopluk Dedic <Svatopluk.Dedic@sun.com>
Subject: Re: [nbdev] Small core & JNDI
To: <nbdev@netbeans.org>
Date: Tue, 5 Mar 2002 14:55:02 +0100 (CET)
Reply-To: nbdev@netbeans.org

On 5 Mar 2002, Trung Duc Tran wrote:

> the fundamental question I like to ask is "Should we use JNDI or not?".
> What's the reason?  What problem are we trying to solve?  Why JNDI?
> Usage scenarios?
> 

1) Ability to name an instance & retrieve the instance in another IDE 
session.
This is achieved by storing Lookup.Item.getId(), but it's not defined 
whether the returned ID is a path through the Lookup contents, identifier 
of the returned instance or what. Besides that, Naming interfaces are the 
*standard* way how to name objects and retrieve them later.

2) Separate identification and communication protocol
Currently inteface's type is both a protocol between the client and the 
service being looked up, but also the service's identifier.
What if there are more service, which serve the interface ? Has the
client 
always sort through them, using the service-private protocol to locate
and 
identify the "correct" one ? If the client could use a different name (as 
with Naming), it could get the correct service using a well-known (JNDI) 
mechanism.

3) Performance
Since Name gives a path through the (possibly) compound namespace, 
navigation to the identified service is straightforward and much faster 
than wide search for anything matching the attributes (the lookup class 
and its supertypes) in a flat namespace

4) Binding attributes.
Since DirectoryContext from JDNI supports attributed bindings, you can 
take further our InstanceCookie.Of, allowing clients to search for 
something that match their needs based on attributes without needing
to materialize 
the service. This is currently hacked into InstanceCookie.Of as a special 
case. If you allow different naming convention than the implementation 
type, generalized attributes is the correct way.

5) Well-defined registration.
An implementation of a serivce can't choose how it gets registered in 
Lookup: it is registered as any of its supertypes. It's really not 
possible to register a subclass of JavaCompilerType specialzed for a 
particular task, because anyone looking for a (generic) JavaCompilerType 
will find it. With JNDI, one can bind the service to several names and
may 
choose what those names should be. In other words, although I need to 
derive the service from JavaCompilerType because of implementation 
reasons, I am not obliged to publish it as a generic java compiler type.

6) Scalability
Consider (3) in a system with several dozens of modules communicating
with 
each other. A module has to publish its services somehow so others can 
locate them. If the registry is flat, the performance will degrade more 
than linearly with number of registered modules. Look at Windows
registry, 
under KHEY_CLASSES_ROOT - this is what Lookup is about. On the contrary, 
look in HKEY_CURRENT_USER/Software: this is what JNDI is about.

> What I would like to avoid at all cost is the bitter lesson learned from
> the original Lookup, which was supposed to solve all problems of the
> world but haven't met its promises.  The original Lookup code is not
> that old and we are already trying to switch to a new interface (JNDI).
> "Which Lookup do you want to use today?"
> 
As you said - Lookup was said to solve all problems and use cases. It 
didn't. So either we should extend Lookup to solve them, work around
them - 
or use a standard interface which offers the solution. Lookup is good for 
undirected queries of one style "just give me something that understands 
protocol org.netbeans.Foo". Try to persuade me that we don't need other 
types of queries.

> Don't forget we are only 9 weeks away from NB 3.4 freeze, and the bug
> count is going up (among other things)
> 
Yes, I know. But on the other hand, I would like to have some *usable* 
registration tool which performs well and scales well: isn't version 
3.4 mature enough to have one ? I'm not accepting this argument given
that 
core team is supposed to build a platform (or the IDE's core), which 
*does* scale.

-Svata

Another message from Petr Nejedly

From: Petr Nejedly <petr.nejedly@Sun.COM>
Subject: Re: [nbdev] Small core & JNDI
To: nbdev@netbeans.org
Date: Tue, 05 Mar 2002 12:05:27 +0100
Reply-To: nbdev@netbeans.org

[...]

I'll try to reply both David and Trung at once:

Why I always see the "One Size Fits All" paradigm here?
Lookup is Lookup and Naming is Naming. The original discussion
died without conclusion IIRC, but there was a consensus that Naming
is better for singletons than the Lookup. We did not come to
a consensus regarding services.

What problem is JDNI trying to solve? That is a question. One problem
of the Lookup is that it needs to preprocess the metadata which is costly.
(We're replaced initialization of data with initialization of metadata)
We're thinking about persisting the content of the lookup, but this
is more a workaround than a solution (OK, I know it worked for TeX
20 years ago, so it may work for us as well).
The other problem is the current size of the FolderLookup.
Just unhide the SFS and look at the Services folder.

Naming can help us reduce even the amount of the metadata initialized.
I asked a question: Why there is a need to have those (mostly) module
private singletons (Settings), which can be easily moved to naming,
placed in the Lookup? Because the system needs to know about them
because of visualization in Options dialog.
Maybe there is another solution for this, like remove the options
from the Services folder and make the SystemOption to look
not only to Lookup but also to the place where we'll move
Options to (other than the Naming).

My idea is following: Lookup probably has its place in the general
intermodule communication. But for well-estabilished channels
we could use something more effective, as the Lookup (as defined
and implemented by the FolderLookup) is not very scallable
and probably won't be without clever* caching.

*) clever = more than serialization of the content

Paralel: In the NB2.x days, every module was unpacking his templates
from a jar to SFS during the instalation and was manually creating
the menu items, toolbars and so on. We've replaced it with layers,
i.e. we're holding the initialized state from the beginning, modules
don't have to do it explicitely in their ModuleInstall.
I see some similarity here with Lookup vs. Naming:
Lookup - preparse the content of settings files to have the information
 needed for subsequent queries.
Naming - Prepare nothing, queries will lead us to proper place.

I'm not pushing this issue now as it would mean some design work
and a lot of changes in modules to have real impact and we have
only those 9 weeks. And I have not yet convinced Yarda to admit
the Lookup was not the best possible thing (although quite qood) :-)

I only expressed my feeling that we should not have separate module
for every other class.

Yarda in his own words

From: Jaroslav Tulach <yarda.tulach@czech.sun.com>
Subject: [nbdev] Why JNDI + Lookup is not dead was: [nbdev] Small core
& JNDI
To: nbdev@netbeans.org
Date: Wed, 06 Mar 2002 16:51:00 +0100
Reply-To: nbdev@netbeans.org
Organization: Sun Microsystems, Inc.

Trung Duc Tran wrote:

> the fundamental question I like to ask is "Should we use JNDI or not?".

That is the question. Answers may vary...

> What's the reason?

...but we need a solution to kill code like this
http://www.netbeans.org/source/browse/core/src/org/netbeans/core/windows/PersistenceManager.java.diff?r1=1.17&r2=1.18

(line 408) and this
http://www.netbeans.org/source/browse/core/src/org/netbeans/core/xml/FileEntityResolver.java.diff?r1=1.8&r2=1.9

(line 242, findObject)
and the bunch of similar code that would have to be introduced in
openidex/commands and openidex/looks modules if they do not use naming.

> What problem are we trying to solve?

The ones described above plus the need to deprecated FolderInstance
(which has
grown and is too complicated to change anything there) and replace it
with a
cleaner API. I'll try to prepare webpage summary of the problems.

> What I would like to avoid at all cost is the bitter lesson learned from
> the original Lookup, which was supposed to solve all problems of the
> world but haven't met its promises.

Trung, maybe you should be a bit appreciative - the lookup was not
supposed to
solve all problems and it delivers exactly what it promised - service
oriented
communication between modules.

> The original Lookup code is not
> that old and we are already trying to switch to a new interface (JNDI).

This is a misunderstanding. We are not going to stop using
org.openide.util.Lookup. We are going to stop using FolderInstance and the
code in PersistenceManager and FileEntityResolver. Comparing this to
lookup is
like comparing oranges to bananas.

> Don't forget we are only 9 weeks away from NB 3.4 freeze, and the bug
> count is going up (among other things)

Another reason to introduce common framework and vanish the uglyness
of above
mentioned classes.
y.

And Jesse's

From: Jesse Glick <jesse.glick@sun.com>
Subject: Re: [nbdev] Why JNDI + Lookup is not dead was: [nbdev] Small
core & JNDI
Newsgroups: netbeans.nbdev
To: nbdev@netbeans.org
Date: Wed, 06 Mar 2002 17:44:14 +0200
Reply-To: nbdev@netbeans.org
Organization: Sun Microsystems / NetBeans

> Trung Duc Tran wrote:
>>What's the reason?
Jaroslav Tulach wrote:
> ....but we need a solution to kill code like this
>
http://www.netbeans.org/source/browse/core/src/org/netbeans/core/windows/PersistenceManager.java.diff?r1=1.17&r2=1.18
> (line 408) and this
>
http://www.netbeans.org/source/browse/core/src/org/netbeans/core/xml/FileEntityResolver.java.diff?r1=1.8&r2=1.9
> (line 242, findObject)
> and the bunch of similar code that would have to be introduced in
> openidex/commands and openidex/looks modules if they do not use naming.

FWIW I agree that adding JNDI support is not gratuitous but solves present
needs:

- The window system needs to find top components according to a particular
name. There is working but rather ugly (and hard-to-extend) code to do
this
now. Using JNDI would centralize the process of finding the instances
and make
the winsys code simpler.

- There are other places where we have a clear need to find an object or
collection of them according to a well-defined name/path. XML environment
processors are one example. Looks (however these work out) will need the
same. I would like to do something like this to find URL stream
handlers, so as
to replace static registration calls.

- Lookup and JNDI overlap a bit, but serve different purposes and
should be
expected to coexist.

- JNDI is included in the Java platform and is the standard and
recognized way
to find objects by their name. Many programmers will already be
familiar with
its basic usage, so it should not make module writing conceptually less
intuitive.

I don't see any pressing need to replace service lookup (e.g. compiler
types)
with JNDI searches, since I think it is tolerably optimized already
(and an
effective caching scheme is known); I think this should be considered
out-of-scope for 3.4, to be discussed as time permits.

Looking forward to a summary of why you think FolderInstance needs to be
deprecated, and what the replacement would look like.

-Jesse

I have recorded this discussion at
http://openide.netbeans.org/proposals/settings/access.html

*** This issue has been marked as a duplicate of 17934 ***

change lookup/core -> lookup/openide