[bind10-dev] Format for the Packet Between BigTool and Configure Manager

[ZhangLikun]

>My take on this is that we should first define what commands we want to
>support, and then decide on what types to use for them, and add to that
>what types we expect we will need.
 

The commands what we need to support are depended on the functionality 

of the modules. But the common command are clear, like:

 

getClassAttribute

getInstanceAttribute

getClassMethods

getInstanceMethods

 

 
>The control channel API itself handles "opaque blobs" (which are usually
>just UTF-8 strings), "lists" (ordered list), "hashes" (tag/value pairs),
>and NULL type (used only in lists and hashes to indicate no data at that
>element or tags without data.)
> 
>Some comments:
> 
>I like to include a sequence number on all messages sent.  This can be
>added automatically somewhere, but the sequence is handy for one simple
>reason:  it allows replies to be matched up with commands.  Either this,
>or there needs to be a requirement that commands are only processed in
>the order they are received.  For status and other commands, it might be
>nice to get the data back in any order.  What are your thoughts on this?
 
Yes, I agree,
 
> 
>Also, on type 'string' either those need to be always defined as UTF-8
>or we need an encoding="" parameter on those.  I would just as soon say
>UTF-8 encoding on all string values.
 
I think UTF-8 is enough for us.
 
> 
>Will we ever want binary blobs?  I don't know if we'll ever be
>transmitting things like images around or not.  It might be cool for a
>UI to get little icons, for instance.  :)
> 
>- --Michael
 
 
I will write some python code for BigTool,  which parse the command inputed
by user, and produce a xml packet,  then send the packet to the Config
Daemon, Finally display 
the feedback to user.
 
ZhangLIkun
CNNIC

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20090923/be3d4cf1/attachment.html>