[item_type] not encoded?

Fri, 30 Aug 2019 14:34:05 +0000

To date, we have only propagated "post" type items through ZOT with Articles, Cards, etc. sent only to channel clones and are not distributed to contacts.

However, I'm working on adding a new Item Type  ==  ITEM_TYPE_CUSTOM (9) for use by addons that may desire to propagate using ZOT.  However, I've run into a problem in that include/items.php::encode_item() does not encode the item_type field when encoding an item for distribution.

The question is:  Is there a particular reason for this?  Or is it just a consequence of the evolution of the protocol that it didn't get added in?

Is there a reason not to just encode the [item_type] in the packet?  Or should  ITEM_TYPE_CUSTOM be designed to set [item_type] to ITEM_TYPE_CUSTOM during item_store() (or maybe in zot_import()?) based on the [obj_type] and/or [tgt_type]?

Fri, 30 Aug 2019 17:24:56 +0000 last edited: Fri, 30 Aug 2019 17:23:20 +0000

*Here's the edited text for the above post (xref the post "Local edits of remote forum posts" for info on why it's a comment).

To date, we have only propagated "post" type items (and related activities eg. LIKE/DISLIKE/comment/etc.) through ZOT with Articles, Cards, etc. sent only to channel clones but not distributed to contacts.

I'm working on adding a new Item Type  ==  ITEM_TYPE_CUSTOM (9) for use by addons that may desire to propagate more specialized items using ZOT.
Currently, I'm using the item_type as the trigger for the hooks that would be included in the addon.  I did this so that nodes without addons can just quickly and easily ignore items that need special processing.   However, I've run into a problem in that include/items.php::encode_item() does not encode the item_type field when encoding an item for distribution.  Thus, nodes receiving the item set the item type to "0" and the custom code never processes -- and besides this - the specialty items show up in the activity stream (perhaps a helpful fallback, but not what was originally intended).

The question is:  Is there a particular reason [item_type] is not encoced?  Or is it just a consequence of the evolution of the protocol that it didn't get added in?

Is there a reason not to just encode the [item_type] in the packet?  Or should  ITEM_TYPE_CUSTOM be designed to set [item_type] to ITEM_TYPE_CUSTOM during item_store() (or maybe in zot_import()?) based on the [obj_type] and/or [tgt_type]?

Tue, 03 Sep 2019 11:07:21 +0000

After a deep dive in the code - yes there is a reason not to encode it - it probably wouldn't hurt anything - but it's the wrong path to the destination I'm seeking.

I'd simply delete this thread but because of the way that it was created, I"m unable to. So for historical purposes - I'm following up here.

Except durring the channel mirroring/cloning process - our own local "item type" should be set based on aspects of the object itself as it is received - most reasonably based on the verb and obj_type.