Re: what to make external (ISSUE-78)

On Tue, 07 Oct 2008 13:23:23 -0400
Chris Welty <cawelty@gmail.com> wrote:
 
> Michael Kifer wrote:
> > 
> > On Mon, 06 Oct 2008 19:34:47 -0400
> > Chris Welty <cawelty@gmail.com> wrote:
> > 
> >>
> >> At the F2F we had a lengthy but ultimately inconclusive discussion on what to 
> >> allow in an external call:
> >>
> >> 1) ATOM
> >> 2) ATOMIC
> >> 3) ATOM | FRAME
> >>
> >> In a straw poll, one person objected to each choice, and there were 3, 6, and 2 
> >> people resp. who preferred each choice.
> > 
> > I remember that csma did retract his objections to (3).
> 
> No, it was Axel who objected to (3).  Csma agreed that we could remove "at risk" 
> on external frames (which was not really an objection).

As far as I remember, Axel was not really objecting

> >> While more people prefer choice 2, it would require re-doing last call.  1&3 
> >> would not, as 1 is covered by external frames being at-risk, and 3 is the way 
> >> the spec reads now.
> > 
> > I think we should do what is right and the LC consideration is not very
> > important, if the change is relatively simple (which is what will be in this
> > case).
> 
> The LC consideration *is* important.  We lose a bit of credibility if we redo 
> last call.
> 
> > I think the right thing to do is Atomic-Equal|Frame
> 
> </chair>
> So far each time we've discussed it a new alternative has come forth! I'm 
> definitely leaning toward Jos' position - the right thing is to keep it simple 
> and go with External(ATOM)
> <chair>

I don't think ATOM is the right thing to go with. The fact that classification
terms were not added was an oversight on my part (~~ bug)

> > Why minus Equal? In principle equality does not matter here, but one should
> > realize that External(a=b) does not imply a=b. So, I am afraid that some people
> > will be confused. But maybe this is a non-issue.
> > 
> > I think the LC thing will need to be redone anyway, because of the problem with
> > the External primitive, which we discussed: it should really have the remote
> > site's IRI as an additional argument.
> 
> This is not a good reason to retract last call - you are basically proposing to 
> add a feature to BLD.  We should redo last call to fix a bug, not to add features.

This was a design bug.

michael

 
> -Chris
> 
> > 
> > 
> > 	--michael  
> > 
> > 
> >> Let's try and come to some sort of closure by email.
> >>
> > 
>

Received on Tuesday, 7 October 2008 18:10:29 UTC