PROPGET and my messing

[Alex Hudson]

_______________________________________________
Bongo-devel mailing list
Bongo-devel-8nu/***@public.gmane.org
https://mail.gna.org/listinfo/bongo-devel

[Lance Haig]

Hi alex,

I like the 1000 OK end as it makes writing other code easier as all the
commands that we will work with.

So my vote in favour

Lance

Hey everyone,
Steve managed to bump his head on a change I made to the Store PROPGET
command recently, while writing some new bindings. When you do a
PROPGET, you can retrieve one or more properties from the Store -
unfortunately, the responses change slightly in both cases. Before,
/Command/
/Response/
PROPGET /mail/INBOX/document nmap.flags
2001 nmap.flags 2
18
PROPGET /mail/INBOX/document nmap.flags,nmap.length
propget 11 nmap.flags,nmap.length
2001 nmap.flags 2
18
2001 nmap.length 3
434
1000 OK
You can see in the second example that there is an extra return code -
the 1000 OK - to indicate the end of a list. This lead to client code
which would effectively implement two different functions - one to read
a single property value, and another to read a list of values. That
makes a small amount of sense in C but makes no sense in any other
language, and to write it as a single function you have to count the
number of properties being asked for before deciding whether or not to
look for the final 1000 code.
The change I made was to add the 1000 response to single property
requests; and aside from the extra ConnWrite() this has only really
resulted in code being removed - it simplifies the logic.
I've changed the nmap client library to correctly pick up this change,
and had already changed the Python library (I think!). However, we can
revert these changes too - they're quite small.
Does anyone have an opinion on reverting this? I didn't actually think
there were any agents consuming this feature, but that was because I
only grepped on the agent code (missing the nmap library - d'oh!) and
probably wouldn't have made the change otherwise :S
Cheers,
Alex.
--
This message has been scanned for viruses and
dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
believed to be clean.
------------------------------------------------------------------------
_______________________________________________
Bongo-devel mailing list
https://mail.gna.org/listinfo/bongo-devel

[Lance Haig]

This e-mail did not make much sense.

What I meant was that if we keep consistency between all our codes it
will give predictable results.

So all successes are 1000 OK

Thanks

Lance

Post by Lance Haig
Hi alex,
I like the 1000 OK end as it makes writing other code easier as all the
commands that we will work with.
So my vote in favour
Lance

Hey everyone,
Steve managed to bump his head on a change I made to the Store PROPGET
command recently, while writing some new bindings. When you do a
PROPGET, you can retrieve one or more properties from the Store -
unfortunately, the responses change slightly in both cases. Before,
/Command/
/Response/
PROPGET /mail/INBOX/document nmap.flags
2001 nmap.flags 2
18
PROPGET /mail/INBOX/document nmap.flags,nmap.length
propget 11 nmap.flags,nmap.length
2001 nmap.flags 2
18
2001 nmap.length 3
434
1000 OK
You can see in the second example that there is an extra return code -
the 1000 OK - to indicate the end of a list. This lead to client code
which would effectively implement two different functions - one to read
a single property value, and another to read a list of values. That
makes a small amount of sense in C but makes no sense in any other
language, and to write it as a single function you have to count the
number of properties being asked for before deciding whether or not to
look for the final 1000 code.
The change I made was to add the 1000 response to single property
requests; and aside from the extra ConnWrite() this has only really
resulted in code being removed - it simplifies the logic.
I've changed the nmap client library to correctly pick up this change,
and had already changed the Python library (I think!). However, we can
revert these changes too - they're quite small.
Does anyone have an opinion on reverting this? I didn't actually think
there were any agents consuming this feature, but that was because I
only grepped on the agent code (missing the nmap library - d'oh!) and
probably wouldn't have made the change otherwise :S
Cheers,
Alex.
--
This message has been scanned for viruses and
dangerous content by *MailScanner*<http://www.mailscanner.info/>, and is
believed to be clean.
------------------------------------------------------------------------
_______________________________________________
Bongo-devel mailing list
https://mail.gna.org/listinfo/bongo-devel

[Patrick Felt]

I agree. I think it brings the protocol into more of a stardard format with predictable results.

-----Original Message-----
From: Lance Haig <lhaig-zEUx8viRvUBWk0Htik3J/***@public.gmane.org>
To: Alex Hudson <alex-b4STkJ5ddZioClj4AeEUq9i2O/***@public.gmane.org>
Date: Sat, 09 May 2009 12:41:05 +0100
Subject: Re: [Bongo-devel] PROPGET and my messing

Hi alex,

I like the 1000 OK end as it makes writing other code easier as all the
commands that we will work with.

So my vote in favour

Lance

Hey everyone,
Steve managed to bump his head on a change I made to the Store PROPGET
command recently, while writing some new bindings. When you do a
PROPGET, you can retrieve one or more properties from the Store -
unfortunately, the responses change slightly in both cases. Before,
/Command/
/Response/
PROPGET /mail/INBOX/document nmap.flags
2001 nmap.flags 2
18
PROPGET /mail/INBOX/document nmap.flags,nmap.length
propget 11 nmap.flags,nmap.length
2001 nmap.flags 2
18
2001 nmap.length 3
434
1000 OK
You can see in the second example that there is an extra return code -
the 1000 OK - to indicate the end of a list. This lead to client code
which would effectively implement two different functions - one to read
a single property value, and another to read a list of values. That
makes a small amount of sense in C but makes no sense in any other
language, and to write it as a single function you have to count the
number of properties being asked for before deciding whether or not to
look for the final 1000 code.
The change I made was to add the 1000 response to single property
requests; and aside from the extra ConnWrite() this has only really
resulted in code being removed - it simplifies the logic.
I've changed the nmap client library to correctly pick up this change,
and had already changed the Python library (I think!). However, we can
revert these changes too - they're quite small.
Does anyone have an opinion on reverting this? I didn't actually think
there were any agents consuming this feature, but that was because I
only grepped on the agent code (missing the nmap library - d'oh!) and
probably wouldn't have made the change otherwise :S
Cheers,
Alex.
--
This message has been scanned for viruses and
dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
believed to be clean.
------------------------------------------------------------------------
_______________________________________________
Bongo-devel mailing list
https://mail.gna.org/listinfo/bongo-devel