${taskforce.name} Avatar
  1. OMG Task Force

Naming FTF — Open Issues

  • Key: NAM
  • Issues Count: 21
Open Closed All
Issues not resolved

Issues Descriptions

Name equivalence

  • Key: NAM-41
  • Legacy Issue Number: 498
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The Name equivalence issue has appeared in comp. object.corba. Follow up posting from Michi Henning

  • Reported: NAM 1.0b1 — Wed, 12 Feb 1997 05:00 GMT
  • Updated: Wed, 11 Mar 2015 23:32 GMT

List binding return type

  • Key: NAM-31
  • Legacy Issue Number: 24
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The "list" operation to access the bindings within a naming context has an overly verbose return type. Could it (and some of its exceptions) be simplified?

  • Reported: NAM 1.0b1 — Mon, 1 Jul 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

BindingIterator

  • Key: NAM-30
  • Legacy Issue Number: 64
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The name service doesn"t really specify when false is first returned. Is when it returns the last one, or when it is already pointing out of range?

  • Reported: NAM 1.0b1 — Sat, 3 Aug 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

FormalNumber: formal/04-10-03, Section TOC

  • Key: NAM-32
  • Legacy Issue Number: 9811
  • Status: open  
  • Source: MITRE ( Mr. Kevin Richardson)
  • Summary:

    This is simply an administrative error, the table of contents within the document does not reflect the fact that the lightweight naming chapter (chapter 3) was incorporated into the document

  • Reported: NAM 1.3 — Thu, 8 Jun 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Name comparisons

  • Key: NAM-17
  • Legacy Issue Number: 270
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Naming Service spec: "The kind attribute adds descriptive power to names.."(p. 3-2) Interpretation: kind value is opaque, never looked at, carried arround with each name. Interpretation correct?

  • Reported: NAM 1.0b1 — Thu, 17 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Open Interpretation for next_one

  • Key: NAM-18
  • Legacy Issue Number: 271
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It is open to interpretation as to whether FALSE is returned with the last valid binding or after the last valid binding. Call next_one one more time after last valid binding to get FALSE?

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Changes to struct binding

  • Key: NAM-27
  • Legacy Issue Number: 280
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Proposal to revise the Naming Service. p. 3-6 and 3-12 of CORBAservices replace the definition of Binding

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Destroy operation in original spec

  • Key: NAM-26
  • Legacy Issue Number: 279
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The destroy operation was the only option in original spec before Lifecycle spec. By inheriting from LifeCycleObject, we get the remove operation which does same as destroy.

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specification of out parameter bl

  • Key: NAM-21
  • Legacy Issue Number: 274
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: When next_n returns FALSE, it needs to be specified what happens to the out parameter bl. Spec should mandate that lenght of returned sequence must be zero.

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

next_n return

  • Key: NAM-20
  • Legacy Issue Number: 273
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: next_n returns a boolean value. It is specified nowhere what the return value means in various cases

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Destroying an iteratorr

  • Key: NAM-24
  • Legacy Issue Number: 277
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Naming Service implementation should be free to destroy an iterator as soon as last value has been retrieved. Clients should be allowed to call next_one or next_n after one of these calls.

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Text for destroy should be updated

  • Key: NAM-25
  • Legacy Issue Number: 278
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Text for destroy should be updated to state that a call to destroy after next_one or next_n have returned FALSE may no longer be valid and may raise OBJECT_NOT_EXIST.

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Meaning of "Why"member in the NotFound exception

  • Key: NAM-29
  • Legacy Issue Number: 298
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Text explains when the NotFound exception is raised, but it does not explain the meaning of "why"member in the exception. Why can be missing node, not_context, not_object

  • Reported: NAM 1.0b1 — Wed, 23 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fewer returns of requested number of bindings

  • Key: NAM-23
  • Legacy Issue Number: 276
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The spec says nothing about whether the Naming Service is allowed to return fewer than requested number of bindings.

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specification of return value from next_one

  • Key: NAM-19
  • Legacy Issue Number: 272
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The return value from next_one is specified as "If there are no more bindings, false is returned". What is returned if there is another binding?

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Value of how_many

  • Key: NAM-22
  • Legacy Issue Number: 275
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The spec says nothing about how to say "as many as you can" with the value of how_many. Specify that how_many value should return as many bindings as it can in a single call.

  • Reported: NAM 1.0b1 — Fri, 18 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Names Library Benefits?

  • Key: NAM-28
  • Legacy Issue Number: 281
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Problem understanding benefits of Names Library. There are differences between what the standard says and what the pseudo-IDL for the names library says.

  • Reported: NAM 1.0b1 — Tue, 22 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Binding a Stringified Name

  • Key: NAM-4
  • Legacy Issue Number: 5926
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The NamingContextExt interface has a resolve_str
    operation that takes a string and returns its
    binding.

    I suggest to add a converse bind_str operation:

    void bind_str (in StringName sn, in Object obj)
    raises (NotFound, CannotProceed, InvalidName,
    AlreadyBound);

    That would allow not only lightweight clients to
    use the Naming Service, but also lightweight servers
    to publish their references as easily as possible.

    (And a Lightweight Naming Service would be possible
    that just implemented these two operations.)

  • Reported: NAM 1.0 — Fri, 2 May 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

INS Issue: Orderof how the Initial reference is resolved

  • Key: NAM-2
  • Legacy Issue Number: 3360
  • Status: open  
  • Source: Anonymous
  • Summary:

    The latest INS doc 99-12-03.pdf explains the order the Initial reference
    should be resolved is
    1. Try using -ORBInitDef definition
    2. Try using -ORBDefaultInitDef defintion
    3. Then finally try with Pre-Configured ORB Settings.

    The above would be the resolve_initial_references protocol. Now, If the user
    sets a -ORBInitDef in the format

    -ORBInitDef NotificationService=corbaloc:rir:/NotificationService

    If the user does orb.resolve_initial_references( "NotificationService" )
    then according to the spec, r_i_r() first checks -ORBInitDef's, In this case
    finds one and also finds that the NotificationService can be obtained by
    r_i_r()
    again it calls the same method. Doesn't this lead to an infinite loop ?

  • Reported: NAM 1.0 — Thu, 24 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

fragment part in file: or http: IOR

  • Key: NAM-1
  • Legacy Issue Number: 3100
  • Status: open  
  • Source: Anonymous
  • Summary:

    I am just reflecting over the optional IOR syntaxes using file:// and
    http:// URI's and have one suggestion. URI's sport a `fragment identi-
    fier', i.e. an identifier following a hash sign.
    Now this fragment identifier could be useful to disambiguate between
    many IORs in the referenced file. I can think of several possibilities:

    1.) The fragment-id is numerical. The file contains many IORs, separated
    by newlines, and the fragment-id is an index into the file.

    2.) The file contains many lines of the format `identifier WS IOR', i.e.
    a simple tab-separated table. The fragment-id denotes the first IOR
    where the identifier matches.

    3.) The ORB checks each IOR in the file and looks for one whose Reposi-
    tory Id matches the fragment-id.

  • Reported: NAM 1.0 — Wed, 8 Dec 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

INS Issue: When are -ORBInitRef arguments processed?

  • Key: NAM-3
  • Legacy Issue Number: 3535
  • Status: open  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    Section 4.8.2 of ptc/99-12-03 should specify at what time strings
    given to -ORBInitRef are processed into object references. Should they
    be processed during ORB_init() and stored for later use by
    resolve_initial_references(), or should they be processed each time
    resolve_initial_references() is called?

    This matters for corbaname: (and file:, http:, etc.) URIs whose
    resolutions can change over time.

    If they are processed at ORB_init() time, are they processed in the
    order they were specified on the command line? Suppose an ORB with an
    administratively configured NameService reference is called with a
    command line of

    -ORBInitRef Foo=corbaname:rir:#foo -ORBInitRef NameService=IOR:...

    If ORB_init() processes the arguments into object references in order,
    foo will be looked up in the administratively configured name service,
    rather than the one specified on the command line. This may or may not
    be considered a useful feature.

  • Reported: NAM 1.0 — Fri, 7 Apr 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT