From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <9front-bounces@9front.inri.net>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE
	autolearn=ham autolearn_force=no version=3.4.4
Received: from 9front.inri.net (9front.inri.net [168.235.81.73])
	by inbox.vuxu.org (Postfix) with ESMTP id 4513B22B73
	for <ml@inbox.vuxu.org>; Thu, 20 Jun 2024 07:04:44 +0200 (CEST)
Received: from pb-smtp21.pobox.com ([173.228.157.53]) by 9front; Thu Jun 20 01:00:26 -0400 2024
Received: from pb-smtp21.pobox.com (unknown [127.0.0.1])
	by pb-smtp21.pobox.com (Postfix) with ESMTP id 9E6F134D07
	for <9front@9front.org>; Thu, 20 Jun 2024 01:00:24 -0400 (EDT)
	(envelope-from me+unobe@fallglow.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=message-id
	:date:from:to:subject:in-reply-to:mime-version:content-type
	:content-transfer-encoding; s=sasl; bh=IiJQxc1SiKJ1Ro5Ie/IicYfJi
	AH32dpDDDd7HB54LOs=; b=WQKDJMBQOaKI6uqcN+UOTwxTzF+xo/IRKVIUAzXwl
	la05cCW40tWv6uyP1TQxde8iQEHLN+H2bXhS6bz64DAXutPhexhB91c301JI0dyg
	k9cGANLCRNr0KxgCvW2yoPYtU6tVsDkFIaUyF2rtHcnjg5HfcbFpCctqrLqoHtV4
	5M=
Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1])
	by pb-smtp21.pobox.com (Postfix) with ESMTP id 970DC34D06
	for <9front@9front.org>; Thu, 20 Jun 2024 01:00:24 -0400 (EDT)
	(envelope-from me+unobe@fallglow.com)
Received: from strider.localdomain (unknown [97.131.41.27])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by pb-smtp21.pobox.com (Postfix) with ESMTPSA id DE00434D05
	for <9front@9front.org>; Thu, 20 Jun 2024 01:00:19 -0400 (EDT)
	(envelope-from me+unobe@fallglow.com)
Message-ID: <1DD347016319C412B78377B0244084CF@smtp.pobox.com>
Date: Wed, 19 Jun 2024 22:00:17 -0700
From: Romano <me+unobe@fallglow.com>
To: 9front@9front.org
In-Reply-To: <8124838e-a6a3-41ea-9169-5a5fe42347fc@posixcafe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID:
 FE2EBFAA-2EC1-11EF-B310-DFF1FEA446E2-09620299!pb-smtp21.pobox.com
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: lossless base enhancement CSS base cloud template 
Subject: Re: [9front] ndb doc patch
Reply-To: 9front@9front.org
Precedence: bulk

On Wed Jun 19 14:30:21 -0700 2024, moody@posixcafe.org wrote:
> On 6/18/24 12:35, Romano wrote:
> > Hello list,
> > 
> > At the end of last year I had a small patch
> > for ndb's man page. There was a bit of
> > discussion re: it in January ( https://inbox.vuxu.org/9front/39A39E500516DB6E2B4CE0BC27677DEF@eigenstate.org/ )
> > and I have tried to address Ori's suggestion
> > here: http://okturing.com/src/20100/body
> 
> I would probably much prefer to fix this than to document a bug.
> If anything should change regarding this, it should be picking a
> sensible maximum and then documenting it in ndb(6) as part of the
> file specification. Not in ndb(8) as a bug of the implementation.

Yeah, I that would be preferable but I thought at least documenting
the known behavior that could trip someone else would would be okay.

Instead of documenting tho', the attribute name should not be limited
to 32 bytes (and not silently truncated) but I'm not sure what a
sensible maximum is. The attribute values as far as I can tell will
happily consume as much memory as possible, and Ndbvlen (as Ori
pointed out) is just a starting default.

For the line parsing limitation of 8K, do you think that is
also something that should be fixed or something that is OK to
document as a limitation?