As I recall it, there was general rejection of the idea that ACAP, as a
protocol, would enforce syntax. There was some agreement that one could
have an implementation that would apply some syntax or content rules, but
it should be pretty exceptional. Your example was using ACAP to store
server configuration, where you wanted to be sure not to let anyone store
"Hi Mom!" in the "Maximum number of threads" attribute. That might be OK,
but having an ACAP server apply all sorts of rules to the data would mean
that you then have to invent a way for clients to discover the rules, and
you end up with a very complex mess. If syntax enforcement is required,
then it needs to be in the protocol. I think we've decided it doesn't need
to be in ACAP. Maybe I was jet-lagged and wasn't following the discussion,
but that's how I remember it. I suppose this is a question for the ACAP
list.
It was my understanding that the ACAP protocol itself would not impose
any limitations, but any backend coudl reject the data. If this is not
the case, I will strongly bring this up in Memphis. If I have to accept
anything that is thrown at me in any case, then ACAP's usefulness for
me goes downhill approaching terminal velocity.
For example, what happens if someone tries to set the value of one of
the fields of an address book to a GIF image that is over 200K? Am I,
as an ACAP server implementor, supposed to not accept that image and
store it? If so, its pretty brain dead.
I think Steve Hole's big concern was on checking every piece of data,
and mine was that we were just acting as a generic data store with
absolutely no format.
... I took mail I wanted to deal with and do something, and as the default
bounce the message. These would be hard to convey with an entry by
entry basis, as would any idea of including other files.
I really think we need to keep the filtering spec as simple and bare-bones
as possible, otherwise it will never get consensus. I recall the BOF in
San Jose saying explicit inclusion of other filters was too complex for now.
I recall that it would be too complex for a first pass, but there was no
objection to having it included.
...and have the backend verify the script when the script is set up.
For example, my backend verifies the script and only generates and
updates the 'compiled' script when it detects no errors.
I don't think the ACAP back-end should do anything except store and
retrieve the data. No syntax checking.
In that case, I will bring up this point at the ACAP WG meeting in
Memphis, against some of the positions expressed at the conference
we just had in Pittsburg. Not having ACAP enforcing the data, I can
live with. Not having any checking of the data I cannot. Having to
accept "Hi Mom!" for a numeric field is stupid. Not putting the
focus on the ACAP server, no problems... but not allowing any feedback
to the client that there is a problem or that there may be a problem is
inviting too many problems.
regards,
Jack
p.s. just my own 2 cents, and I am a strong proponent for the ACAP protocol.
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 576-3873 http://www.wildbear.on.ca/
Author of SLMail for 95 & NT (http://www.seattlelab.com/)