commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Conrad" <andrewcon...@attbi.com>
Subject RE: [lang] System properties
Date Sat, 24 Aug 2002 17:26:32 GMT
For the most part it is a hierarchy.  And you could define

OS_FAMILY_OSX = OS_BASE_MAC | OS_BASE_UNIX;

Then

true = (( OS_FAMILY_OSX & OS_BASE_UNIX ) == OS_BASE_UNIX )
true = (( OS_FAMILY_OSX & OS_BASE_MAC ) == OS_BASE_MAC )


My thought was to define a few of the OS_BASE_XXX in the interface (with
room to grow) , and leave the OS_FAMILY_XXX for the implemented class to
define.

Our implementation can decide how to resolve the cases, and if someone
needs to meet their own situation, they can plug their own
implementation in.

- Andrew

> -----Original Message-----
> From: Steve Downey [mailto:steve.downey@netfolio.com] 
> Sent: Saturday, August 24, 2002 12:42 PM
> To: Jakarta Commons Developers List
> Subject: RE: [lang] System properties
> 
> 
> The problem is that it really isn't a heirarchy. Mac OS X is 
> both Mac and Unix. Depending on what capabiities you're 
> actually interested in.
> 
> The real question is, what's the use case for the interface?
> 
> > -----Original Message-----
> > From: Andrew Conrad [mailto:andrewconrad@attbi.com]
> > Sent: Saturday, August 24, 2002 1:21 AM
> > To: 'Jakarta Commons Developers List'
> > Subject: RE: [lang] System properties
> >
> >
> > Thanks, I was just thrown off by the extra verbage.  I 
> think defining 
> > an interface a good idea, allowing the utility to be extended as 
> > needed.
> >
> > What does everyone else think?
> >
> >
> > An OSClassifier interface, A GenericOSClassifier class, load 
> > GenericOSClassifier by default in SystemUitls, and adding 
> appropriate 
> > set and get methods to change the OSClassifier ?
> >
> >
> > Also, what about defining a property hierarchy base upon the code 
> > base, then the operating system family, kind of like:
> >
> > OS_BASE_UNIX
> > OS_BASE_MAC
> > OS_BASE_WINDOWS
> >
> >
> > OS_FAMILY_LINUX
> > OS_FAMILY_AIX
> > OS_FAMILY_WINDOWS_NT
> > OS_FAMILY_WINDOWS_9X
> >
> > Each family is also a part of the base....
> >
> >
> > - Andrew
> >
> > > -----Original Message-----
> > > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > > Sent: Friday, August 23, 2002 2:04 PM
> > > To: Jakarta Commons Developers List
> > > Subject: RE: [lang] System properties
> > >
> > >
> > >
> > >
> > > On Fri, 23 Aug 2002, Andrew Conrad wrote:
> > >
> > > > Date: Fri, 23 Aug 2002 13:14:50 -0400
> > > > From: Andrew Conrad <andrewconrad@attbi.com>
> > > > Reply-To: Jakarta Commons Developers List 
> > > > <commons-dev@jakarta.apache.org>
> > > > To: 'Jakarta Commons Developers List'
> > > <commons-dev@jakarta.apache.org>
> > > > Subject: RE: [lang] System properties
> > > >
> > > > What do you mean by pluggable interface and a processor class 
> > > > identifier?  Can you point me to a class that does this, so
> > > I can try
> > > > and get up to speed?
> > > >
> > >
> > > I don't know of any specific code that does this for OS 
> clases, but 
> > > consider something along the following lines:
> > >
> > >   public interface OSClassifier {
> > >     public String getOSClass();
> > >   }
> > >
> > > that would have the responsibility to grab the 
> appropriate operating 
> > > system property and "classify" it -- in the current 
> discusson we've 
> > > talked about classes like "SunOS" versus "Linux" versus "Windows" 
> > > being returned.
> > >
> > > Now, it would be possible to hard code a mapping algorithm into a 
> > > static
> > > getOSClass() method inside SystemUtils, but that's not very 
> > > extendable. It would be better to allow apps to plug in their own 
> > > classifier algorithm
> > > -- just as a simple example, some apps will care about the 
> > > distinction between SunOS and Solaris, and others won't.
> > >
> > > The standard SystemUtils class would support something like:
> > >
> > >   public class SystemUtils {
> > >     ...
> > >     public static OSClassifier getOSClassifier();
> > >     public static void setOSClassifier(OSClassifier classifier);
> > >     ...
> > >   }
> > >
> > > and provide a default implementation of OSClassifier that is 
> > > generally
> >
> > > useful -- but applications needing more specialized 
> analysis of the 
> > > system property string can do so.
> > > >
> > > > - Andrew
> > > >
> > >
> > > Craig
> > >
> > >
> > > > > -----Original Message-----
> > > > > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > > > > Sent: Friday, August 23, 2002 12:59 PM
> > > > > To: Jakarta Commons Developers List
> > > > > Subject: RE: [lang] System properties
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Fri, 23 Aug 2002, Steve Downey wrote:
> > > > >
> > > > > > Date: Fri, 23 Aug 2002 12:42:14 -0400
> > > > > > From: Steve Downey <steve.downey@netfolio.com>
> > > > > > Reply-To: Jakarta Commons Developers List 
> > > > > > <commons-dev@jakarta.apache.org>
> > > > > > To: Jakarta Commons Developers List 
> > > > > > <commons-dev@jakarta.apache.org>
> > > > > > Subject: RE: [lang] System properties
> > > > > >
> > > > > > I think trying to make these distinctions will end up in a
> > > > > morass of
> > > > > > fine differences without utility. SunOS is how Solaris
> > > identifies
> > > > > > itself, although the version numbers aren't the same.
> > > > > Solaris 7, for
> > > > > > example, is SunOS 5.7.
> > > > > >
> > > > > > Even with what's there now, what does IS_LINUX say that 
> > > > > > IS_UNIX doesn't? That is, what action could you take on the

> > > > > > basis
> > > > > of IS_LINUX
> > > > > > being true, that you couldn't with just IS_UNIX being true.
> > > > > >
> > > > >
> > > > > To make something like this more generally useful and
> > > scalable, it
> > > > > might be better to abstract the notion of OS 
> identification by 
> > > > > providing a pluggable interface that returns a 
> "processor class 
> > > > > identifier" or something.  The default implementation 
> could be 
> > > > > what's originally proposed, but people wouldn't be stuck with 
> > > > > it.
> > > > >
> > > > > The same sort of thing happens in the web app world when
> > > it comes to
> > > > > the "User-Agent" header.  There are lots of libraries around 
> > > > > that attempt to classify these strings into general 
> categories, 
> > > > > but no such scheme is going to be universally applicable.
> > > > >
> > > > > Craig
> > > > >
> > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: scolebourne@btopenworld.com 
> > > > > > > [mailto:scolebourne@btopenworld.com]
> > > > > > > Sent: Friday, August 23, 2002 5:18 AM
> > > > > > > To: commons-dev@jakarta.apache.org
> > > > > > > Subject: RE: [lang] System properties
> > > > > > >
> > > > > > >
> > > > > > > >  from:    Andrew Conrad <andrewconrad@attbi.com>
> > > > > > > > So your saying that potentially there could be 
> a Solaris 
> > > > > > > > family encompassing all Solaris versions, Windows
NT 
> > > > > > > > family
> > > > > encompassing
> > > > > > > > NT, 2000, XP?
> > > > > > >
> > > > > > > I think that demand will come. Is Mac OSX a Mac or a UNIX?
> > > > > > >
> > > > > > >
> > > > > > > > Without thinking too hard about it, the only thing
I
> > > > > can think of
> > > > > > > > is to use a byte as the enumeration type then AND
them 
> > > > > > > > together and compare. That will allow a boolean method
> > > > > isOSFamilyLinux and
> > > > > > > > isOSFamilyUnix to both return true  (and other possible
> > > > > options:
> > > > > > > > I think I heard OSX ).
> > > > > > >
> > > > > > > One thing I hate is manipulating bytes with AND and OR
> > > > > operations.
> > > > > > > It requires me to think too much.
> > > > > > >
> > > > > > > > What's the reasoning behind wanting to differentiate
> > > > > between Linux
> > > > > > > > and Unix, but not SunOS and AIX?
> > > > > > >
> > > > > > > I would have added a Solaris option, but didn't know if
> > > > > Solaris ==
> > > > > > > SunOS or not.
> > > > > > >
> > > > > > > Stephen
> > > > > > >
> > > > > > > --
> > > > > > > To unsubscribe, e-mail: 
> > > > > > > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > > > > For additional commands, e-mail: 
> > > > > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > > > > For
> > > > > additional commands,
> > > > > e-mail:
> > > > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org> For
> > > > > additional commands,
> > > > > e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > > For
> > > additional commands,
> > > e-mail:
> > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > For
> > > additional commands,
> > > e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail: 
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: 
> > <mailto:commons-dev-help@jakarta.apache.org>
> >
> >
> >
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message