Subject: npds Digest V1 #13

From: Listar <nospam_listar_at_ml.free_dot_fr>
Date: Thu, 23 Nov 2000 03:23:14 +0100 (CET)

<x-charset x-mac-text>------------------------------------
npds Digest	Wed, 22 Nov 2000	Volume: 01  Issue: 013

In This Issue:
		[NPDS] [Protocol] SHARE & QUERY result

----------------------------------------------------------------------

Date: Wed, 22 Nov 2000 09:27:53 +0100
From: Paul Guyot <nospam_pguyot_at_kallisys_dot_net>
Subject: [NPDS] [Protocol] SHARE & QUERY result

Hi all,

I've been working a little bit on the protocol this morning. I remind 
you where we're going to. There are two formats for commands, 1.0 and 
1.1
Everything that is 1.0 is what Matt's tracker does.

Some new commands are introduced with 1.1

Summary:

Command		Version		Format(s)	Purpose
ABOUT		1.0		1.0, 1.1	Tell about the server
REGUP		1.0		1.0, 1.1	Register a Newton
REGDN		1.0 (r)		1.0, 1.1	Unregister a Newton
SHARE		1.1		1.1		Communication between servers
QUERY		1.1		1.1		Get a list of known Newtons

(REGDN is just recommanded in version 1.0)

What's new in 1.1 is the ability to encode the Newton description in 
any character encoding. Besides, there can be line feeds in this 
description. (this can be restricted, it's one of the solutions to my 
problem).

The 1.0 format for REGUP is
REGUP host[:port] Description

And the description goes till the end of the line.

The 1.1 format for REGUP has the charset in the header and the 
description is in the body. Therefore the description goes till the 
end of the request.

Now, with the SHARE & QUERY methods, we need to return a list of the 
available servers/Newtons. My problem is: which format to choose.

I think that the best is to put in the headers the encoding of the whole body.
Then in the body a description of each server/newtons.

I found basically three options:
a/ we limit the Newton description to anything but carriage 
returns/line feeds. The structure of the SHARE & QUERY results will 
look like Victor's current response to these commands, i.e. data at 
the beginning of the line separated by tabulations, description at 
the end, next line is a new server/newton.
b/ we encode the carriage returns/line feeds with something like \n, \r.
c/ we use XML for the whole structure.

The easiest to implement (both the servers and the Newton should 
decode this result, the servers for the SHARE method, the Newton for 
the QUERY method) is point (a). But it has a serious limitation: the 
data about a Newton should be limited to have a single text with 
allowed tabulations.
However, with this new 1.1 format, this could be changed in the 
future if we need it.

What do you think about it?

Paul
-- 
http://www.kallisys.com/

------------------------------

Date: Wed, 22 Nov 2000 07:40:09 -0800
Subject: [NPDS] Re: [Protocol] SHARE & QUERY result
From: "Josh Burker" <nospam_Josh_Burker_at_misd.wednet_dot_edu>

[email-masked] writes:
>Command		Version		Format(s)	Purpose
>ABOUT		1.0		1.0, 1.1	Tell about the server
>REGUP		1.0		1.0, 1.1	Register a Newton
>REGDN		1.0 (r)		1.0, 1.1	Unregister a Newton
>SHARE		1.1		1.1		Communication between servers
>QUERY		1.1		1.1		Get a list of known Newtons

<SNIP>

>Now, with the SHARE & QUERY methods, we need to return a list of the 
>available servers/Newtons. My problem is: which format to choose.
>
>I think that the best is to put in the headers the encoding of the whole
>body.
>Then in the body a description of each server/newtons.
>
>I found basically three options:
>a/ we limit the Newton description to anything but carriage 
>returns/line feeds. The structure of the SHARE & QUERY results will 
>look like Victor's current response to these commands, i.e. data at 
>the beginning of the line separated by tabulations, description at 
>the end, next line is a new server/newton.
>b/ we encode the carriage returns/line feeds with something like \n, \r.
>c/ we use XML for the whole structure.
>
>The easiest to implement (both the servers and the Newton should 
>decode this result, the servers for the SHARE method, the Newton for 
>the QUERY method) is point (a). But it has a serious limitation: the 
>data about a Newton should be limited to have a single text with 
>allowed tabulations.
>However, with this new 1.1 format, this could be changed in the 
>future if we need it.
>
>What do you think about it?

The (a) option would be close to how the Newton descriptions are currently
offered on the Tracker page:  short and to the point, but customizable
like John Solon's Newton Exobrain.  If (a) is the easiest to implement but
changeable if you decide to revise the format I would suggest using (a). 
I'd say keep it simple:  that's part of the beauty of NPDS.  But I also
like the power behind the software, so implementing an option that can be
built upon makes sense.

Thanks,

Josh Burker

------------------------------

End of npds Digest V1 #13
*************************

</x-charset>