I'd like to see Generics used for Jini too, unfortunately, Java's generic 
implementation has limitations we cannot work around.

We might create some sort of pre processor that inserts type cast checks to 
ensure runtime type safety.

I don't know the solution unfortunately.

We could create a post processor with ASM that weaves in instanceof checks 
before every type cast.  

The problem is, what action must be taken if the type cast is wrong?

I wish it did work, sorry to be the bearer of bad news.

Peter.

----- Original message -----
> You are talking about a a field of an Entry, but it does aim at generics type
> safety. Too, the fields of an Entry as returned per the specification are not 
> to
> be of different class types than what were given. If the instances contained 
> in
> the collection given during a write are String...they will be String on
> retrieve. Sure, if some other processes write does something or if the
> serialized format is changed or manipulated you may be dealing with something
> particularly strange; but then again, we're talking about a bug in the
> application using spaces not in generics per se. That would be a different bag
> of worms.
>
> On the Entry returned, one is going to perform a cast of this class to the
> expected type to be able to access the fields in the Entry. There is no magic
> which is going to make that cast work if it is not at least some byte code
> modified extension of that same class type; that same cast is happening for
> generics...no other magic there either. Even the spec states: "An entry is a
> typed group of object references represented by a class that implements the
> marker interface net.jini.core.entry.Entry. Two different entries have the 
> same
> type if and only if they are of the same class."
>
>
> I would very much like to see the generics changes in Jini myself. I am 
> willing
> to work on that as a change with who ever initially proposed it if they would
> like. We can come up with something you can poke holes in. I don't see an
> implementation breaking things unless it is not following the specs though, 
> but
> I'm always willing and up for being schooled. It is great to learn something 
> new
> every day :-D Perhaps you can point me to the area in the specs which says the
> Entry or the field can be returned as some other type than that which was
> written; I couldn't find it, but did look around and am curious about it.
>
> Thanks,
>
> Wade
>
>  ==================
> Wade Chandler
> Software Engineer and Developer
> NetBeans Dream Team Member and Contributor
>
>
> http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
> http://www.netbeans.org
>
>
>
> ----- Original Message ----
> > From: Peter <j...@zeus.net.au>
> > To: river-dev@incubator.apache.org
> > Sent: Fri, December 17, 2010 7:03:25 PM
> > Subject: Re: Space/outrigger suggestions
> >
> > There is one additional problem, the use of generics causes a narrowing of 
> > scope, the template and return value must be the same type. The entry spec 
> > currently allows the template to be a different class, a dummy class can be
> > used    instead.
> >
> >
> > Once Generics are introduced into service api, at the  boundaries of
> > separately  compiled code, without the type safety checks performed  by 
> > javac,
> > only ill will  come of it. Welcome to the slippery slope of  complication.
> >
> > Time is precious, but seeing as you require me to do some  work, it's only
> > fair  that you provide me with an implementation, for me to break  with a 
> > test
> > case.
> >
> > This implementation will require an Entry that contains  a collection and a
> > client that uses objects from the collection.
> >
> > The test  case will put new entries into the space that contain collections
> > also, these  collections will contain objects of a different type.
> >
> > Your implementation  will need to use a template that uses a wildcard for 
> > the
> > collection, and your  client will need to access the objects contained 
> > within,
> > using Generics to  access their implementation methods.
> >
> > Then after I break it, I'll  demonstrate that without Generics in a similar
> > implementation, the collection  can be handled in a typesafe manner.
> >
> > From my experience, consistant  reliable results build better developer
> > confidence than nice looking but broken  api's.
> >
> >
> > Peter.
> >
> > ----- Original message -----
> > > In this case,  I believe one must first prove the contrary; prove there 
> > > is a
> > > problem  with generics in this case. Is there an example of where this
> > proposal
> > >  for JavaSpaces causes an issue. I don't know of any. I would be very 
> > surprised
> > > if one could give a working example of such an issue. We are  talking 
> > > about
> > an
> > > Entry type. Whether this entry were passed into this  call using generics 
> > > or
> > not,
> > > one could have a generic List in some field  of some instance of their
> Entry.
> > > This can happen right  now.
> > >
> > > Wade
> > >
> > >  ==================
> > > Wade  Chandler
> > > Software Engineer and Developer
> > > NetBeans Dream Team  Member and Contributor
> > >
> > >
> > >  http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
> > >  http://www.netbeans.org
> > >
> > >
> > >
> > > ----- Original Message  ----
> > > > From: Peter <j...@zeus.net.au>
> > > > To: river-dev@incubator.apache.org
> > >  > Sent: Fri, December 17, 2010 5:09:47 PM
> > > > Subject: Re:  Space/outrigger suggestions
> > > >
> > > > There seems to be support  for using generics in this case.
> > > >
> > > > If we can  develop  some good documentation to explain why it works and
> why
> > > > it's  the    exception to the rule for using generics in service api, if
> > this is
> > > >  indeed  the  case, then I think it is acceptable.
> > > >
> > > > Do  we have any good wordsmith's on  the list?
> > > >
> > > > I think we  must do our due diligence and check for potential  problems.
> > >  >
> > > > This will work for the simple case, but what about an entry    that
> > > > contains
> > a
> > > > collection, the user will expect the generic  collection to be  typesafe
> > but
> > > > runtime checks can't be  performed.
> > > >
> > > > Instanceof  List<String> doesn't work  for example.
> > > >
> > > > I'm worried this won't work  in all cases  as expected.
> > > >
> > > > Are you prepared to do some research to  proove  runtime type safety?
> > > >
> > > > If boilerplate code is  the problem, is it possible  to use annotations 
> > > > to
> > > > perform checked  type casts  instead?
> > > >
> > > > Cheers,
> > > >
> > > >  Peter.
> > > >
> > > > ----- Original message  -----
> > > > >  public Entry read(Entry template, Transaction txn, long  timeout);
> > > >  >
> > > > > That is indeed the original/current method's    signature.
> > > > >
> > > > > A couple of points.
> > > >  > 1) "The client knows the  []'s class type, the class cast isn't much 
> > work"
> > > > > is
> > > > an
> > > > > argument against    all generics, not just generics in this case.     
> > > > >      It
> > > > >  ignores
> > > > the
> > > > >  additonal specification power and  type safety that the generic
> > provides.   
> > > > >
> > > >  It
> > > > > also discounts the work of adding the cast every time  (mandatory
> > > > > boilerplate
> > > > is
> > > > >  bad).
> > > > >
> > > > > 2) Returning "Entry" is what the    method signature promises now, but
> > it's
> > > not
> > > > > what the  space specification  promises.          The read/take 
> > > > > family of
> > methods
> > > >  has a
> > > > > semantic gap between  what is contractually promised and  what is
> > > > > checked
> > by
> > > > the
> > > > > compiler, and  generics  can close that gap.
> > > > >
> > > > > ---
> > > >  >
> > > > > I think I may  still be missing something when it comes  to your point
> > about
> > > > > "separate  compilation".          In the case  of using generics at 
> > > > > the
> > method
> > > level
> > > > >  (again, not the  class level), the compiler not resolves on each
> method
> > > >  call,
> > > > > does it not?          How then would we get in trouble with  
> > > > > different 
> > compilation
> > > > times?
> > > > >
> > > > >  With the definition:
> > > > > public <T  extends Entry>  T read(T  template, Transaction txn, long
> > > timeout)
> > > > >
> > > >  > Foo foo = space.read(someFoo,t,0); //Fine
> > > > > Bar  bar =  space.read(someBar,t,0); //Also fine
> > > > >
> > > > >  Granted, if the space  had previously seen some prior version of 
> > > > >Foo, 
> > that's
> > > > a
> > > > > runtime kind of  problem, but that's a  runtime problem with or 
> > > > > without
> > the
> > > > >  generic...
> > > >  >
> > > > > Perhaps another example or a pointer to some  resources  to read would
> > > clarify
> > > > > this for me.          (If you have  the  time.)
> > > > >
> > > > > jamesG
> > > > >
> > >  > > -----Original Message-----
> > > > >  From: "Peter Firmstone"  <j...@zeus.net.au>
> > > >  >
> > > > > The  alternative method signature that is typesafe for  James:
> > > > >
> > > > > public  Entry read(Entry template,  Transaction txn, long timeout);
> > > > >
> > > > > The  client  knows the template's class type, the class cast isn't 
> > > > > much
> > > > >  work  for the client developer.  Simpler is best I think, Generic's 
> > offer
> > > > > no  benefit for Service API.
> > > > >
> > >  > > Hope this helps to clear it  up.
> > > > >
> > > > >  Cheers,
> > > > >
> > > > >  Peter.
> > > > >
> > >  > >
> > > > >
> > > > > Patricia Shanahan wrote:
> > >  > > > I'm  working on a replacement FastList that assumes JDK1.5 or  
> > >later,
> > so
> > > > > >  that I can depend on the new memory model and  some of the
> > > > > >  java.util.concurrent features.
> > > >  > >
> > > > > > Do you advise using, or  avoiding, generics in  its definition?
> > > > > >
> > > > > > Patricia
> > >  > >  >
> > > > > >
> > > > > > On 12/14/2010 2:22  PM, Peter wrote:
> > > > > >  > Generics are replaced with casts  in bytecode.  All typesafe 
> > > > > >checks
> > > > >  > > are done at  compile time and the generic replaced with a cast.  
> > > > >If
> > > > > >  > clients are compiled separately, this check won't occur,  and 
> > > > > >the 
> > cast
> > > > > > > will be unchecked at runtime.
> > > > >  >  >
> > > > > > > If clients with identical bytecodes or  type casts use  javaspace 
> > > > > > > it
> > > > > > > will work, if  separately compiled clients with  different type
> casts
> > > > > >  > try to use the same space service, it  will fail with class cast
> > >  > > > > exceptions at runtime.
> > > > > >  >
> > >  > > > > However since your T template is declared as a method    
> > >parameter,
> > the
> > > > > > > javaspace service can check the class  name at  runtime and only
> > return
> > > > > > > that type.  This  must be done in the  javaspace service
> > implementation.
> > > > > >  >
> > > > > > > Only then  will your generic method be  typesafe.  So yes it will
> > work,
> > > > > > >  but I want to make  sure the complications of generics in
> separately
> > > > > >  >  compiled code is well understood. It is not simple, but can be
> done
> > > >  >  > > with due care.
> > > > > > >
> > > > >  > > Users are going to  have a hard time understanding how to 
> implement
> > > > > > > generics in  their service  implementations, it is fraught with
> > > > > > > pitfalls  that  may not bite until after deployment.
> > > > > > >
> > > >  > > >  User devs expect generics to make life simpler, but it has  the
> > > > > > >  opposite effect in remote code.
> > > >  > > >
> > > > > > > We're either  going to have to  document the use of generics in
> > service
> > > > > > > api  really  well, or prohibit them.
> > > > > > >
> > > > > > >  I think  because it's possible it should be allowed, but we have 
> > > > > > >to
> > > >  > > >  document it well as an advanced feature that places the type 
> check
> > > > > >  > burden on the service implementation.
> > >  > > > >
> > > > > > >  Cheers,
> > > > > >  >
> > > > > > > Peter.
> > > > > > >
> > > >  >  > > ----- Original message -----
> > > > > > > >  Perhaps you could  unpack your statement about generics for me 
> > > > > > > >a
> > > >  > > > > bit.                      Are you
> > > > > > > >  saying this wouldn't work?
> > > > > > >  >
> > > > >  > > > public<T extends Entry>  T read(T template,  Transaction  txn,
> > long
> > > > > > > > timeout)
> > > > > > >  >  (... with similar modifications to the other methods)
> > > > >  > >  >
> > > > > > > > The generic is defined at the  method-level,  enforcing that the
> > type
> > > > > > > > returned  is
> > > > > > >  > the type of the template (and that the  template extends 
> > > > > > >Entry). 
> >           
> > > > > > > > This  is,
> > > > > > > > indeed, the current  contractual obligation  of the method.
> > > > > > > >
> > > > > > >    > It would be unfortunate if we couldn't add this, because this
> > would
> > >  > >  > > > save our
> > > > > > > > users a cast  every time they used  JavaSpace, but there may be 
> > > > > > > > a
> > > > > > >  > technical hurdle
> > > > >  > > > which I'm not  understanding.
> > > > > > > >
> > > > > >  >  > Anyway, thought I'd attempt to clarify, since last time there 
> > was
> > >  > > > > > confusion over
> > > > > > > > whether  I was  asking for method-level generics or class-level
> > > > > >  > > generics  (the
> > > > > > > > latter would break  JavaSpace generally).
> > > > >  > > >
> > > > > >  > > jamesG
> > > > > > > >
> > > > > >  >  > -----Original Message-----
> > > > > > > > From:  "Peter"<j...@zeus.net.au>
> > > > > >  > >  Sent: Tuesday, December 14, 2010 6:28am
> > > > > > >  > To: river-dev@incubator.apache.org
> > >  > >  > > > Subject: Re: Space/outrigger suggestions
> > > >  > > >  >
> > > > > > > > I believe we can create  jini community  standards.
> > > > > > > >
> > > > >  > > > If the service api is  different, it is not breaking  backward
> > > > > > > > compatibility,  it
> > > > >  > > > is simply a different service.  A bridging service  smart 
> > > > >proxy 
> > can
> > > > > > > > implement
> > > > > > > >    javaspace and utilise the new service, allowing legacy 
> > > > > > > >clients
> to
> > > >  > >  > > utilise the
> > > > > > > > new  service.
> > > > > > >  >
> > > > > > > > You  could call it Balinda, Borne again Linda.  ;)
> > > > > > >  >
> > > > > > > > With generics and service api,  compile  time generic 
> > > > > > > > replacements
> > > > > > > > must be the
> > >  > >  > > > same, otherwise a runtime class cast exception will  occur.   
> > >  
> > This
> > > > > > > > will work when
> > > > >  > > > T is replaced  by the same class, but will break when it isn't 
> in
> > > > > > > >  separately
> > > > > > > >  compiled code.  Generics that are specific  will work.
> > > > > >  > >
> > > > > > > > Cheers,
> > > > > >  >  >
> > > > > > > > Peter.
> > > > > > >  >
> > > > > > >  >
> > > > > > > >
> > >  > > > > >
> > > > > > > > -----  Original  message -----
> > > > > > > > > Who controls the JavaSpace    API specification? Is it 
> > > > > > > > > something
> > we
> > > can
> > > > > > >  > > change, as  part of River, or do we just have an 
> > implementation?
> > > > > > > >  >
> > > > > >  > > > Should we be considering designing RiverSpaces,  similar  to
> > > > JavaSpaces
> > > > > > > > > but with an  updated API,  including generics, more use of
> > > > collections,
> > >  > > > > > > and  better naming?
> > > > > > >  > >
> > > > > > > > > James -  if you have time, could  you file a Jira issue? That
> > way,
> > > > these
> > > > > > >    > > ideas will not get lost in the mail archives.
> > > > > >  > >  >
> > > > > > > > > Patricia
> > > > >  > > > >
> > > > >  > > > > On 12/14/2010 12:33  AM, James Grahn wrote:
> > > > > > >  > > > I have a  small list of suggestions for 
> > > > > > >javaspace/outrigger,
> > > > largely
> > >  > > > > > > > derived from my experience creating a    wrapper for space
> > > > functionality
> > > > > > > >  > > and direct  usage prior to the creation of that wrapper.
> > > >  > > > > >  >
> > > > > > > > > > Many  of these suggestions involve breaking  backwards
> > > > > > >  > > > compatibility, so
> > > > > > >  > > >  many tears will be shed and perhaps we'll decide against
> > > >  implementing
> > > > > > > > > > any of these. But, I'm  hoping this  might lead to some
> > discussion
> > > > and
> > > > >  > > > > > perhaps some  improvements.
> > > > > > >  > > >
> > > > > > > > > >  ---
> > > > >  > > > > >
> > > > > > > > > > 1) Generic    methods.
> > > > > > > > > > First, use generics in the  method  signatures to minimize
> > casting,
> > > > in
> > > > > >  > > > > this  manner:
> > > > > > > > >  >
> > > > > > > > > >  public<T extends Entry>    T read(T template, Transaction 
> > > > > > > > > >txn,
> > long
> > > > >  > > > >  > timeout)
> > > > > > > > > >
> > > > > >    > > > > Seems broadly like a win, if use of Java 1.5 idioms  is
> > > > acceptable.
> > > > > > > > > >  This
> > > > > > > > >  > is the only one I've mentioned  before, and the reaction 
> > > > > > > > >was
> > > fairly
> > > > >  > > >  > > positive on this list.
> > > > > > > > >    >
> > > > > > > > > > ---
> > > > > > >  > >  >
> > > > > > > > > > 2) More  collection-like naming of space  methods, more
> > > consistency.
> > > >  > > > > > >
> > > > > > >  > > > read,  take, readIfExists, takeIfExists, write, snapshot, 
> > notify,
> > > > >  > > > > > registerForAvailabilityEvent all have  fine names. That  
> > > > >is,
> > they
> > > > > > > > > > properly
> > > > >  >  > > > > describe the functionality and how the methods  
> > > > >themselves 
> > relate
> > > > > > > > > > to one
> > >  > > > > > > >  another.
> > > > > > > >  > >
> > > > > > > > > > I do,  however, take issue  with "contents", "take (with a
> > > > > > > > >  >  collection)",
> > > > > > > > > > and "write (with a    list)".
> > > > > > > > > >
> > > > > > >  > > > I  would suggest the following renamings:
> > > > > >  > > > > contents  ->  readAllExisting
> > > > > > >  > > > take (with collection)  ->  takeAny
> > > > > >  > > > > write (with list) ->      writeAll
> > > > > >  > > > >
> > > > > > > > > > This  would  eliminate the awkward overloading of "take" and
> > > "write"
> > > >  > > >  > > > while
> > > > > > > > > >  bringing "contents" into a  consistent naming plan.
> > > > > > >  > > >
> > > > > > > >  > > The goal is a naming  scheme which clearly communicates
> > > > functionality:
> > > > >  > > > > > "exists/existing" suffix =  nonblocking call
> > >  > > > > > > > "any" suffix = one or more  templates will be  satisfied,
> > > > multi-return
> > > > > > > > > >  "all"  suffix = all templates will be satisfied, 
> > > > > > > > > >multi-return
> > > > >  > > >  > > If unmodified, standard blocking call.
> > > >  > > > > >  >
> > > > > > > > > > The  clearer naming also points to new  functionality we 
> > > > > > > > > > could
> > > > > >  > > > > choose to
> > > > > >  > > > >  support, namely:
> > > > > > > > > > readAll -  blocking  call with all templates
> > > > > > > > > > readAny -    blocking call on any template
> > > > > > > > > >  takeAllExisting -  nonblocking call with multiple 
> > > > > > > > > >templates.
> > > > >  > > > > >  takeAll - blocking call with all templates
> > >  > > > > > >  >
> > > > > > > > >  >
> > > > > > > > > >  Addendums:
> > > > >  > > > > > 1) I'll admit that "any" is the  weakest part of the  
> > > > >syntax,
> > as it
> > > > > > > > > > fails
> > > >  >  > > > > > to connote the multi-return. I was stretching to  cover  
> > > >the
> > > > current
> > > > > > > > > >  "take
> > > > > > > > >  > (with collection)" semantics,  which blocks until at least
> one
> > > > > >  > > > >  template
> > > > > > > > > > match is  available. Open to  better suggestions.
> > > > > > > > > >
> > > >  >  > > > > > 2) Though generally I dislike overloading  methods,  there
> > > > is
> > one
> > > > > > > > > > case  I'm
> > > > > > > >  > > sympathetic to: overloading  "all" and "allExisting" 
> > > > > > > >methods
> > to
> > > > >  > > > > >  take in a
> > > > > > > > > > single  template or  multiple templates. This would save 
> > > > > > > > > > some
> > calls
> > > > to
> > > > >  > >  > > > Collections.singleton() for our users while  maintaining a
> > > > consistent
> > > > > > > > >  > return type for the method.
> > > > >  > > > >  >
> > > > > > > > > > ---
> > > > > > >    > > >
> > > > > > > > > > 3) Collections or  remote  iterators, not both.
> > > > > > > > > >  "contents" returns a  remote iterator named "MatchSet", 
> > > > > > > > > >while
> > >  "take
> > > > > > > > > >  (with
> > > > > >  > > > > collection)" returns a collection. I can  understand the 
> > argument
> > > > > > > > > > behind
> > > > >  >  > > > > both use cases, but not necessarily the argument for  
> > > > >using 
> > both
> > > > > > > > > > simultaneously.
> > >  > > > > >  > >
> > > > > > > > > >  ---
> > > > > > > > >  >
> > > > > > > >  > > 4) Exception soup.
> > > > > > > >  > >  Javaspace methods return a vast cornucopia of possible
> > > > > >  > > exceptions.
> > > > I
> > > > > > > > > >  would propose wrapping any Exceptions  bubbling up to River
> > users
> > > >  > > > > > > to be
> > > > > >  > > > >  wrapped in RiverException. Those few(?) who have special
> > > > > >  handlers
> > > > to
> > > > > > > > > > deal with  problem conditions can  peek into the cause.
> > > > > > > >  > >
> > > > > > > >  > >                  From my  observation, most libraries are 
> > > > > > > >either
> > taking  this
> > > > > > >  > > > route (ala
> > > > > > > > >  > JAXB) or  wrapping everything in runtime exceptions 
> > > > > > > > >(Spring,
> > > IIRC).
> > > >  >  > > > > >
> > > > > > > > > >  Presumably this  suggestion could be applied to all of 
> > > > > > > > > >River,
> > not
> > > >  just
> > > > > > > >  > > JavaSpaces.
> > > > >  > > > > >
> > > > > > > >  > > ---
> > >  > > > > > > >
> > > > > > > > > >    5) Clearer javadocs.
> > > > > > > > > > The current  Javaspace docs  are part protocol 
> > > > > > > > > > specification,
> > part
> > > > > >  > > > >  implementation with some vital bits of information 
> > squirreled
> > > > > > > > > > away
> > > >  in
> > > > >  > > > > > obscure reaches.
> > > >  > > > > >  >
> > > > > > > > > > For  instance, in the 9 paragraphs  describing the behavior 
> > > > > > > > > > of
> > > "take
> > >  > > > > > > > (with
> > > > >  > > > >  > collection)":
> > > > > > > > > > "If  there is at  least one matching Entry available in the
> > space,
> > > > an
> > > >  > >  > > > > invocation of this method must take at least one  Entry. 
> > > >If 
> > more
> > > > > > > > > > than one
> > > >  > > > > > >  matching Entry is available, the invocation may  take
> > additional
> > > > > >  > > > > entries.
> > >  > > > > > > > It must not take  more than maxEntries, but  an
> > > implementation
> > may
> > > > > > > > > >  chose
> > >  > > > > > > > to take fewer entries from the space than    the maximum
> > available
> > > or
> > > > > > > > > >  the
> > > > > > >  > > > maximum allowed by  maxEntries."
> > > > > > > > >  >
> > > > > >  > > > > The above is a broad protocol  specification to 
> > > > > >implementers 
> > (even
> > > > > > > > > > allowing  that the method may  always return an empty list 
> > > > > > > > > > ;-)
> > ).
> > > > > > > >  > >  Frustrating to users because the definition is so 
> > > > > > > >amorphous.
> > > > >    > > > > >
> > > > > > > > > > It also  takes some  doing to track down the fact that the
> > > > > > >  > > >  implementation
> > > > > > > > > > does,  in fact, limit the number  of entries returned from a
> > "take
> > > > >  > > > > > (with
> > > > >  > > > > >  collection)". That tidbit is stored within the  outrigger
> > > >  *package*
> > > > > > > > > > documentation, which    reveals the setting and default 
> > > > > > > > > > (only
> > 100).
> > > > > > > >  >  >
> > > > > > > > > >
> > > > > >  > > > >
> > > > >  > > > > > Aside: In prior  discussion, I believe the reason for  
> > > > >using
> > that
> > > > limit
> > > >  > > > > > > was that the implementation  creates an array of  size
> > > > Minimum(limit,
> > > > > > > > > >    maxEntries)... and I think there's already a JIRA bug to
> > switch
> > > >  > >  > > > > from the
> > > > > > > > >  > array to a  collection. When we do, we should be a bit more
> > > >  > > > > > >  generous with
> > > > > > > >  > > the default (or remove the  setting).
> > > > > > > >  > >
> > > > > > > > > >  ---
> > > > > >  > > > >
> > > > > > > > > > Anyway,  hope  this stirs some discussion.
> > > > > > > > > >
> > >  > > >  > > > > I'll be on vacation the rest of the month,  so 
> > >unfortunately
> > > 
> > my
> > > > > > > > > > participation in  said discussion will likely  be spotty
> > (though
> > > > > > > >  > > I'll try
> > > > > > >  > > > to look in). I've  been meaning to push out these
> > recommendations
> > > > for
> > > >  > > > > > > some time, though, so I figured better now  than  waiting
> > another
> > > > > > > > > > month.
> > > >  > > >  > > >
> > > > > > > > > >  jamesG
> > > > > > > >  > >
> > > > > > >  > >
> > > > > > > >
> > > > > > >    >
> > > > > > > >
> > > > > > >
> > > >  > > >
> > > > >  >
> > > > > >
> > > >  >
> > > > >
> > > > >
> > > >
> > > >
> >
> >

Reply via email to