Subject: RE: [Seamoby] My thoughts on server approaches (and other fun stu ff)

From: [email-masked]
Date: Mon, 17 Mar 2003 09:25:29 -0500

>> AJOY-> You did not answer my question about the simplicity 
>of protocol.
>> The DT proposal of CARD is lot simpler than what is
>> being proposed in dycard. 

Do you have anything of substance here to say? Why on earth is a server-based
approach simpler than an approach that does not require said server? Statements
don't get right just because you post them. And rejecting our questions regarding the grounds
for what you claim with "I would like to hear opinions of others" doesn't make it better.
You post statements on the list with claims, and everybody, the silent WG members and the 
dycard authors, have a right to hear the grounds for your argument. Otherwise, it is nothing 
more than a simple, unproven claim which can easily be rejected.

Thanks,

Dirk
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Pat Calhoun <[email-masked]>
Date: 18 Mar 2003 11:20:35 -0800

I think a list of the alternatives, and the cost associated with each
alternatives, would be a VERY worthwhile discussion to have.

PatC
On Tue, 2003-03-18 at 12:17, Liebsch wrote:
> Hi Dirk,
> 
> I agree that it would be helpful to get some feedback from outside
> DT and dycard authors. Now, hope we can get some opinion during
> the Seamoby meeting.
> Now, as you know, there are some characteristics of a server-function
> approach that are not really convincing for reasons that are actually valid for
> ALL server-based approaches. DT proposal tried to make the use of the server
> function clear, keeping it restricted to very basic functionality to avoid
> complexity. I wonder why statements like 'static config at the server'
> and 'server is used for initial population of caches only' appear, this
> is not what the server function is for, and DT doesn't introduce a server
> function only to introduce additional complexity ;-), but to avoid protocol
> complexity, ensure scalability and meet expectation on functional
> requirements.
> As referred to many times, if WG wants an alternative approach for
> cache maintenance, DT is open for modification. But tradeoff coming with
> a currently available alternative approach, that's what I tried to summarize
> in my last mails. Maybe we should take them over to slides for
> Thursday's meeting to not put bias on 'knocking on the server function
> approach'.
> 
> marco
> 
> 
> [email-masked] wrote:
>

---

From: Pat Calhoun <[email-masked]>
Date: 18 Mar 2003 11:20:35 -0800

PatC

---

From: Liebsch <[email-masked]>
Date: Tue, 18 Mar 2003 21:17:06 +0100

Hi Dirk,

marco

---

From: Liebsch <[email-masked]>
Date: Tue, 18 Mar 2003 21:17:06 +0100

Hi Dirk,

marco