Mark Brouwer wrote: > Bob Scheifler wrote: >> Mark Brouwer wrote: >>> SourceAliveRemoteEvent extends RemoteEvent >>> SourceAliveNotificationTime implements InvocationConstraint >>> >>> You obtain the ServiceRegistrar proxy and prepare it with constraints >>> including a SourceAliveNotificationTime with a time-out or 30 seconds. >>> >>> You registering for receiving ServiceEvents through the >>> RemoteEventListener passed in with ServiceRegistrar.notify(). >> >> One thing that bothers me is the use of constraints to pass >> what seem to be method arguments. It seems that this constraint >> is only applicable to the event registration method, and it >> isn't altering the communication semantics, it's being used as >> a way to pass extra arguments without altering the method signature. >> Both aspects feel outside the bounds of how I think constraints were >> originally intended to be used. There isn't a bright line drawn, >> but from the constraint package javadoc: "At each remote call through >> a proxy, the proxy implementation is responsible for using communication >> mechanisms that satisfy the client's constraints." >> >> I'm curious if you share any concerns here? > > Yes I've had my concerns here and I agree we are on a slippery slope > given the way constraints are specified. > > No doubt you can remember we've had our fair share of discussions over > the years with regard to the applicability of constraints for > controlling QoS aspects at the proxy level (working over multiple remote > method invocation, etc.) among other things. > > I think there was also a discussion with JavaSpace05.contents of how to > control e.g. whether the MatchSet should be populated asynchronous or > when done in batches what the batch size should be (AFAIK none of the > JavaSpace05 implementation provide any QoS constraints in this area). >
There was a similar discussion and it's been popping up in Blitz land again. I was likely to make it a config thing for starters and then move to add an additional parameter to the method and include something like MatchSet.DEFAULT_BATCH_SIZE so one can leave it up to the space. That said it's likely due to various implementation options that might not do batching, this parameter could only ever be a hint which wouldn't fit well with the Constraints philosophy I suspect. > I tend to think an invocation constraint its influence should be allowed > to things that are a direct consequence of the remote method invocation. > In this case the event notifications caused by the event registration. > Although I agree the usage in the field of constraints is likely limited > (which is also due to that it is hard to work with them) and therefore > people are not likely to design them I have 2 others [1] in the pipeline > now that I have the tools and ability to work with them [2]. > > For me constraints have a similarity with the usage of Configuration to > many of the constructors of the utility classes, it can cater for > aspects that otherwise have to be represented by arguments that might > not be applicable to each and every implementation and to cater for > things not foreseen at design time. > > So yes I'm concerned with some of the QoS constraints I've been thinking > of the past years given the current language, but less concerned about > whether it really incorrect. Maybe the language should be relaxed or > altered, although I have no idea of a better way to describe it. > > One question for you, do you think the > com.sun.jini.discovery.MulticastMaxPacketSize constraint used for > controlling the size of the buffers used to receive incoming multicast > request and announcement packets is within the bounds of the semantics > for constraints? > > > [1] one constraint I have is to control whether logging to a logging > service must take place in a synchronous versus asynchronous way, see > http://www.cheiron.org/utils/release/v0.2/api/org/cheiron/logging/SynchronousLogging.html > > . Another one I plan to work on some day is an experiment with batching > remote events for the inverted event model, allowing the backend to > batch all remote events in a window of x ms. > > [2] as part of the security work for Seven I had the need for creating > BasicMethodConstraints by adding constraints to an existing set of > BasicMethodConstraints and this utility class I recently moved into > Cheiron Utils, see > http://www.cheiron.org/utils/release/v0.2/api/org/cheiron/util/ConstraintsUtils.html > > . Together with the fact that currently ~100% of the implementations of > MethodConstraints returned by RemoteMethodControl.getConstraints() are > of the type BasicMethodConstraints you have a proper tool for constraint > manipulation with which you can create other nice utility > methods/classes. As an example see > http://www.cheiron.org/utils/release/v0.2/api/org/cheiron/util/logging/LogUtils.html#setSynchronousRemoteLogging(org.cheiron.logging.RemoteLogger,%20boolean) >
