We're not matching, we're filtering to ignore attributes we have no interest in (which in turn avoids unnecessary codebase access). So we're simply indicating the types of things we are prepared to accept thus:
ServiceInfo.class, Name.class As opposed to: new ServiceInfo(....), new Name(.....) Matching is done as a standard part of lookup and is tuplespace'ish already. On 5 February 2011 19:41, <jgr...@simulexinc.com> wrote: > To state the obvious, matching entries that the client passes in sounds > like tuplespace template matching. > > Perhaps this is a case where we'd benefit from having around a tuplespace > data structure, in addition to the service? > > jamesG > > -----Original Message----- > From: "Peter Firmstone" <j...@zeus.net.au> > Sent: Saturday, February 5, 2011 5:28am > To: river-dev@incubator.apache.org > Subject: Re: MarshalledServiceItem > > Ok, good reasoning, we can keep the Entry's explicit, in the call. > > So we make the Entry's the client's interested in, the only Entry's > that'll be unmarshalled, those and the ServiceID. > > Cheers, > > Peter. > > >
