[zeromq-dev] Devices and config files

[Pieter Hintjens]

Gonzalo,

I've made the small fixes to the RFC.

Binary data is a conundrum.  There's no clean way of representing it
in JSON, but that also applies to a UNIX-style format.  We could use
base64 encoding, or byte strings ("bytestring": [ 123, 8, 62, 12]), or
we could simply mandate "no binary", that subscriptions and identities
must be plain text strings.

Regarding comments, and normalisation of endpoints, what struck me
yesterday is that what we probably want is an address broker.  Device
configurations themselves won't change so much once they're working,
but endpoints will move around, I guess.  It should be quite doable to
speak to an address broker to translate endpoint names into literal
values.

-Pieter


On Mon, Aug 23, 2010 at 8:23 PM, Pieter Hintjens <ph at imatix.com> wrote:
> On Mon, Aug 23, 2010 at 6:18 PM, gonzalo diethelm <gdiethelm at dcv.cl> wrote:
>
>> I have a couple of comments about the documentation for ZDCF; there is
>> no talk page, so I am posting them here:
>
> You should be able to join the site and create a talk page.  Join
> here: http://rfc.zeromq.org/main:registration.
>
>> 1. You say "Conceptually, one ZDCF file maps to one process, consisting
>> of a single context and zero or more device threads", but there is no
>> reason why this has to be the case.
>
> I'm not yet sure whether the syntax scales to N processes but it's
> worth exploring.  Another option for device configuration is what Zed
> Shaw did for Mongrel2, i.e. a sqlite database.  It sounds weird but
> lets one easily modify the configuration on the fly (e.g.
> enable/disable logging) etc.  Maybe for later...
>
>> 2. Where you say "specifies zero or more addresses to connect the socket
>> to", I would use "zero or more endpoints" to be consistent.
>
> Indeed.  I keep thinking of 'address' in zmq_connect but it's an
> endpoint of course.
>
>> 3. What is the plan for binary values? These could apply for identity
>> and subscribe.
>
> Well, how would you want to edit and maintain these?
>
>> 4. mcast_loop should be a boolean, not an integer.
>
> Thanks for catching that.
>
> Would you re-post your comments to the talk page so we don't lose them?  Thanks.
>
>
> -
> Pieter Hintjens
> iMatix - www.imatix.com
>



-- 
-
Pieter Hintjens
iMatix - www.imatix.com