Subject: RE:

From: Eddy Quicksall <[email-masked]>
Date: Thu, 21 Mar 2002 10:44:45 -0500

That would be ok for something like an expression parser but our parser
should be very simple minded and it is better if it is not context
sensitive. It is the same idea as "don't use two characters".

Also, the "looks" of it is not very important.

Eddy

-----Original Message-----
From: Bill Studenmund [mailto:[email-masked]]
Sent: Thursday, March 21, 2002 10:37 AM
To: Eddy Quicksall
Cc: iSCSI; [email-masked]; Rod Harrison; Julian Satran
Subject: RE: 

On Thu, 21 Mar 2002, Eddy Quicksall wrote:

> A dash is also used for negative numbers (we don't have any yet but could
in
> the future).

True, but is that a concern here? For a range, you have to have two
numbers with the dash/minus between them. "-number" would not be a
valid range. So even if we ever get negative numbers, ranges should be
readily different.

The only point of confusion would be if we ever permitted algebraic
expressions, when the '-' would look like subtraction. But I think that
would neither be sensible nor likely.

Take care,

Bill

---

From: Bill Studenmund <[email-masked]>
Date: Thu, 21 Mar 2002 09:03:43 -0800 (PST)

> sensitive. It is the same idea as "don't use two characters".

While I agree simple is good, there has to be some sort of context
senstivity. I mean you have to figure out if you have one value or a
range, don't you? How do you do that? Don't you parse one number and then
look at the next character to decide if you have a range or not? If the
next character is the range-indicating character, you remove it from the
stream and then call the number parser again, don't you? Given that, how
is using a '-' a problem? It's the exact same code (hardware or software)
as using ';', just a different constant.

Since I really doubt algebraic expressions will ever be valid, the
sequence " ... number '-' number ... " can never mean anything other than
a range. So how is that hard for even a simple parser to deal with?

Also, I think you've assumed that: 1) we should use '-' either for
negative numbers or for ranges not both, and 2) that we would rather use
'-' for negative numbers than for ranges. While I don't care much about
the first assumption, if we have to choose between ranges using '-' and
negative numbers, ranges seem to make more sense to me here. Most programs
accept them, and it's a rather intuitive way to express them.

Also, are we really ever going to need negative numbers? SCSI doesn't have
them. IP doesn't. TCP does not.  Since those protocols use unsigned
numbers, why would we need signed?

> Also, the "looks" of it is not very important.

I think you took my use of "look" at too simplistic a level. I did not say
aesthetics. :-) My use of "look" reflects parsability of text. If
something "looks" like something else, I'm saying it's more difficult to
distinguish the two interpretations in a parser (you need extra context
which we both agree is usually bad). If things "look" like each other,
it's harder to tell them apart. We don't want that, in order to keep the
parser simple as you mentioned above. Thus "looks" are important.

Take care,

Bill

---

From: Luben Tuikov <[email-masked]>
Date: Thu, 21 Mar 2002 13:48:50 -0500

> sensitive. It is the same idea as "don't use two characters".

Context: are you parsing ``MaxConnections=3''
or ``3''. You see, your parser is already
context sensitive.

As iSCSI grows, undoubtedly each parameter/variable
will be handled by it's own string value parser,
and _THEN_ you'd abstractize into
 integer value, or
 string value, or
 range.

Note, that a range is
a string (we know this already) of
<integer><range symbol><integer> to use context
free grammar (stripped down version :-).

Philosophically, the debate is whether to use
1 character or many.

I vote for just a single char. Anywhich one.

Using a different character to tell us that
this string denotes a range is not quite a
solution here. E.g.:

MaxConnections=3<your range symbol here>10

So the Target will know that it is a range,
but it doesn't matter... it will have to check
the context anyway...

That is, the context really matters! (AI anyone?)

P.S. It would also be nice to see keys' values
in context free grammar (EBNF will do the trick,
or even BNF)... Then everything will be easier. :-)

-- 
Luben

---

From: Bill Studenmund <[email-masked]>
Date: Thu, 21 Mar 2002 12:10:09 -0800 (PST)

> will be handled by it's own string value parser,

Well, there probably won't be that many parsers. One set-of-numbers parser
can be used for all the number-expecting cases.

> I vote for just a single char. Anywhich one.

Agreed.

> but it doesn't matter... it will have to check

Won't the parser already have to have figured out the context anyway? We
have to know if the key is: 1) valid, and 2) appropriate for this phase
already, don't we? After figuring that out, is it hard to know if we
expect a string or one or more numbers?

Take care,

Bill

---

From: Bill Studenmund <[email-masked]>
Date: Thu, 21 Mar 2002 13:40:43 -0800 (PST)

On Thu, 21 Mar 2002, Luben Tuikov wrote:

> Bill Studenmund wrote:
> Yes, of course. I was merely trying to show that
> we cannot escape from the variable's context.

Ahhh.... Ok.

> Once we all recognize this fact we'd see that
> we could overload certain symbols to denote
> ranges. I mean certain, since overloading the comma
> will not be that wise as in the _future_ we may
> want to have a list of ranges (e.g. for choosing
> a bit as in ``OurBitRange=1-4,13-16'').

Agreed, ',' would be bad.

Take care,

Bill

---

From: Luben Tuikov <[email-masked]>
Date: Thu, 21 Mar 2002 16:34:31 -0500

> can be used for all the number-expecting cases.

Yes, that's why I was mentioning contex-free
grammars to describe the values which the
variables can take, since then it is really easy
to see what the terminals are (aka tokens, primitives),
and one would need to have an integer, and string
parser, the rest is left to the key's handler/negotiator.

> > free grammar (stripped down version :-).

[cut]

-- 
Luben

---

From: Bill Studenmund <[email-masked]>
Date: Thu, 21 Mar 2002 17:53:27 -0800 (PST)

Is something wrong with the mailing list? (Does it have anything to do
with orbs going away?) Here's part of the log for one message I sent to
the list.

Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
        by mononoke.wasabisystems.com (Postfix) with ESMTP id 4A41130710
        for <[email-masked]>; Thu, 21 Mar 2002 18:12:54 -0500 (EST)
Received: (from majordom@localhost)
        by ece.cmu.edu (8.11.0/8.10.2) id g2LLjT110652
        for ips-outgoing; Thu, 21 Mar 2002 16:45:29 -0500 (EST)

Those headers show that the message sat on the mail server for 90 minutes.

Looking at one of the messages Eddie sent me, I see:

Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200])
        by mononoke.wasabisystems.com (Postfix) with ESMTP id 3132230715
        for <[email-masked]>; Thu, 21 Mar 2002 19:40:39 -0500 (EST)
Received: (from majordom@localhost)
        by ece.cmu.edu (8.11.0/8.10.2) id g2LN6fV17916
        for ips-outgoing; Thu, 21 Mar 2002 18:06:41 -0500 (EST)

Does anyone know what's up? I figure everyone else is seeing it.

Take care,

Bill

---

From: Paul Koning <[email-masked]>
Date: Fri, 22 Mar 2002 10:31:59 -0500

>>>>> "Bill" == Bill Studenmund <[email-masked]> writes:

 Bill> Is something wrong with the mailing list? 

I've rarely seen it be any faster than a multi-hour latency.

     paul

---

From: Luben Tuikov <[email-masked]>
Date: Fri, 22 Mar 2002 14:19:12 -0500

> I've rarely seen it be any faster than a multi-hour latency.

I've also seen it drop messages...

What is the reason and/or can it be fixed?

-- 
Luben