Messages, queues, and tags

Hello,

I’ve been following the changes Josh is making to the GR messaging
system.
I am not sure that a gr_tag is a good fit for a generic message. For
example, the ‘offset’ may not be relevant to many messages.

We’ve been using tags very extensively in our designs and they are great
but serve a very different purpose than messages should. Perhaps a
better
idea is to define a standard message header?

How about something like this:

A pmt_t tuple with

  1. First entry is a string indicating the packet type
  2. A sequence of zero or more pairs with (key, value), where key is a
    string, and value is any pmt_t

Eugene

On 11/23/2011 06:11 PM, Eugene Grayver wrote:

Hello,

I’ve been following the changes Josh is making to the GR messaging system.
I am not sure that a gr_tag is a good fit for a generic message. For
example, the ‘offset’ may not be relevant to many messages.

Well, so basically I wanted a object with key, value, and srcid. All of
those concepts from tags fit really well with the pmt-based message
passing.

So I decided to use gr_tag which has all of that good stuff. However,
there is an offset member, which only applies to streams. Yes, it is
laziness on my part (or is it efficiency?)

Did you have an issue other than the unused “offset” member?

We’ve been using tags very extensively in our designs and they are great
but serve a very different purpose than messages should. Perhaps a better
idea is to define a standard message header?

How about something like this:

A pmt_t tuple with

  1. First entry is a string indicating the packet type

In this current design above, this is the purpose of tag.key

  1. A sequence of zero or more pairs with (key, value), where key is a
    string, and value is any pmt_t

I suppose if you wanted to aggregate several messages (several key/value
pairs), you could set tag.key to “my super message aggregate” and then
tag.value would be this combined tuple format of keys and values.

I would like to keep the pmt-based message passing parallel with the
tags API, so if one deserves changing, than I think changes are merited
for both.

keep the feedback coming! Thanks,
-Josh

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs