Ivan Krstić wrote:
On Feb 26, 2008, at 5:48 AM, Morgan Collett wrote:
actually we are normally using b64 encoding so
that brought it down to 28 bytes. Using SHA-256 it's 44 bytes in the TXT
record.
But _why_ are we encoding at all? TXT RDATA is one or more character
strings, which are
OK, put like this, I agree with you. We can burn 12 bytes to save a
flag day conversion; we will already have saved a ton of bytes as it is;
12 bytes is no more than a 10% improvement on top
- Jim
On Thu, 2008-02-28 at 21:27 +0200, Morgan Collett wrote:
Ivan
On Feb 26, 2008, at 2:49 AM, Sjoerd Simons wrote:
Does sugar make any assumptions about the size of the key? IOW can
we instead of removing the key completely, use a smaller key?
As I've told daf, smcv et al many months ago in Boston, there's no
point in advertising the whole key.
Ivan Krstić wrote:
On Feb 26, 2008, at 2:49 AM, Sjoerd Simons wrote:
Does sugar make any assumptions about the size of the key? IOW can we
instead of removing the key completely, use a smaller key?
As I've told daf, smcv et al many months ago in Boston, there's no point
in advertising the
On Feb 26, 2008, at 4:24 AM, Morgan Collett wrote:
I've logged #6572 against Presence Service with a patch, to replace
the
public key with its sha1 hash. Works in jhbuild.
That ticket indicates a 40-byte hash, but SHA-1 is a 160-bit function.
Whence the doubling? Also, would you mind
Morgan Collett wrote:
Ivan Krstić wrote:
On Feb 26, 2008, at 2:49 AM, Sjoerd Simons wrote:
Does sugar make any assumptions about the size of the key? IOW can we
instead of removing the key completely, use a smaller key?
As I've told daf, smcv et al many months ago in Boston, there's no point
Ivan Krstić wrote:
On Feb 26, 2008, at 4:24 AM, Morgan Collett wrote:
I've logged #6572 against Presence Service with a patch, to replace the
public key with its sha1 hash. Works in jhbuild.
That ticket indicates a 40-byte hash, but SHA-1 is a 160-bit function.
Whence the doubling? Also,
On Feb 26, 2008, at 10:29 , Ivan Krstić wrote:
On Feb 26, 2008, at 4:24 AM, Morgan Collett wrote:
I've logged #6572 against Presence Service with a patch, to replace
the
public key with its sha1 hash. Works in jhbuild.
That ticket indicates a 40-byte hash, but SHA-1 is a 160-bit function.
On Feb 26, 2008, at 5:20 AM, Bert Freudenberg wrote:
Hex-encoding.
I figured, but why? Is passing around network-order raw bytes an
issue? If so, and we're trying to squeeze out bytes, surely a more
efficient packing than hex encoding can be used.
--
Ivan Krstić [EMAIL PROTECTED] |
On Feb 26, 2008, at 5:48 AM, Morgan Collett wrote:
actually we are normally using b64 encoding so
that brought it down to 28 bytes. Using SHA-256 it's 44 bytes in the
TXT
record.
But _why_ are we encoding at all? TXT RDATA is one or more character
strings, which are each a length octet
On Tue, 26 Feb 2008 at 06:58:10 -0500, Ivan Krstić wrote:
On Feb 26, 2008, at 5:48 AM, Morgan Collett wrote:
actually we are normally using b64 encoding so
that brought it down to 28 bytes. Using SHA-256 it's 44 bytes in the
TXT
record.
But _why_ are we encoding at all? TXT RDATA is
Hi,
As a result of a talk of Jim, Lennart and some Collabora folks at LCA there
were some suggestions how one could potentially optimise the network load of
avahi. See the commented list below :)
* play around with the announce intervals, RR TTLs and stuff
- We already changed the
On Mon, 2008-02-25 at 18:08 +0100, Sjoerd Simons wrote:
Hi,
As a result of a talk of Jim, Lennart and some Collabora folks at LCA there
were some suggestions how one could potentially optimise the network load of
avahi. See the commented list below :)
* play around with the
On Mon, Feb 25, 2008 at 12:21:22PM -0500, Jim Gettys wrote:
On Mon, 2008-02-25 at 18:08 +0100, Sjoerd Simons wrote:
Hi,
As a result of a talk of Jim, Lennart and some Collabora folks at LCA
there were some suggestions how one could potentially optimise the
network load of
On Mon, 2008-02-25 at 19:28 +0100, Sjoerd Simons wrote:
I also note we do nothing regarding suspend/resume and adjusting
timeouts properly, per the mdns spec. Do you have a feel for what the
effect of implementing that there would be?
Which potentially changes are you specifically
On Mon, Feb 25, 2008 at 02:42:21PM -0500, Jim Gettys wrote:
Search for sleep in draft-cheshire-ext-multicastdns.txt. My memory is
that Lennart said there wasn't anything implemented in Avahi for these
cases.
Rather than improvements, I'm worried that frequent suspend/resumes
may be
* Minimize size of announced services (i.e. drop unnecessary data from TXT)
- The biggest item in the TXT of contacts is the key (which is BIG). But
this key is a requirement of bitfrost, so we can't get rid of it.
So far as I have been informed, the Bitfrost protections that
As soon as we have a baseline measurement of packets to measure against,
I think we should remove this and the workstation record, and then
retake the measurements.
- Jim
On Mon, 2008-02-25 at 16:42 -0500, Michael Stone wrote:
* Minimize size of announced
Michael Stone wrote:
* Minimize size of announced services (i.e. drop unnecessary data from
TXT)
- The biggest item in the TXT of contacts is the key (which is BIG). But
this key is a requirement of bitfrost, so we can't get rid of it.
So far as I have been informed, the
On Tue, Feb 26, 2008 at 12:57 AM, Morgan Collett
[EMAIL PROTECTED] wrote:
Michael Stone wrote:
* Minimize size of announced services (i.e. drop unnecessary data from
TXT)
- The biggest item in the TXT of contacts is the key (which is BIG).
But
this key is a requirement
On Tue, Feb 26, 2008 at 07:57:27AM +0200, Morgan Collett wrote:
However, Sugar's UI code currently tracks buddy objects by key, so the
key is required to be unique. I have a patch in #4656 to fix this, as it
prevented more than one key-less buddy from being displayed (e.g. a
regular XMPP
21 matches
Mail list logo
