Re: GNOME Namespace Management - ARC & GNOME

[Ed Hunter <ed hunter Sun COM>]

I think the last two messages from Murray and Mark bring up one important
point.  We should try and first narrow down (or at least prioritize) the
"interfaces" we care about.  Brian's initial question was around file system
location.  He followed that up with a list of possible interface types that
are of interest inside Sun and might be of interest to the GNOME community.
Murray made a pass at identifying which of those were relevant.

It seems like the next step is to see if there is general agreement on those
things and then start talking about what to do about them.  From the Sun side
we can probably provide some observations about how we have dealt with such
things.

To cut down on some of the includes I've edited down Murray's last response to
the parts I'd like to discuss.  His first pass at shrinking the interface
types.


> 
>        The ARC definition of "interface" is broad -- any syntax or semantics
>        that another project (or a human) could depend on. It is not limited
>        to APIs nor limited to customer-visible project boundaries. Some common
>        kinds of interfaces are:
> 
>           1. Libraries (APIs and SPIs, both functions and header files)
>           2. Command Line Utilities (applications or configuration or 
>		administration tools)
>           3. Graphical User Interfaces (GUIs)
> 
> I think it would be best to forget this one. GNOME's UI is meant to
> improve, and it doesn't change without good reason.
> 
>           4. Character User Interfaces (CUIs)
> 
> Not relevant to GNOME.
> 
>           5. Command line Interpreter languages
> 
> Probably also not relevant.
> 
>           6. Input/output file formats
>           7. Resource & configuration file names and formats
>           8. Databases
> 
> Not relevant, I think.
> 
>           9. Protocols or inter-component messages
>          10. Log files
> 
>          11. Solaris package names
>          12. Java package names
> 
> Obviously not relevant.
> 
>          13. Daemons
>          14. URLs
> 
> Do you have examples of interfaces and changes to them for these?
> 
>          15. Windows EXEs, DLLs, VxDs, and registry IDs
> 
> I think you know that this is not relevant. 


Taking Murray's edits as a given we get the following list which could
probably use some refinement and better definitions.

 1. Libraries (APIs and SPIs, both functions and header files)
 2. Command Line Utilities (applications or configuration or 
		administration tools)
 3. Input/output file formats
 4. Resource & configuration file names and formats and location
 5. Protocols or inter-component messages
 6. Log files location and format
 7. Solaris package names
 8. Daemons
 9. URLs (need and example of this)
 
I would separate item one from the list since it sounds like there is already
a lot of focus on that.  The next eight seem ripe for discussion on how their
evolution might be documented and managed (if at all).

Does it make sense to pick up the discussion there and try to further refine
the list and discuss what makes sense to do here?
-edh