[Playerstage-users] Problems with RFID structures and type

[Giulio Z. <Giu...@ir...>]

MY CONFIGURATION (though we will use the same on different machines,
both LinuX and MacOs):
Player 2.0.4
Stage 2.0.3
OS Linux Ubuntu 7.04, kernel 2.6.20-16-generic

THE PROBLEM:
RFID technology developement is bringing us into considering these tags
not only for applications related to barcode replacing and unique ID
problems, but also for storing relevant data on them. Different
paradigmas for R/W on RFID tags have already been shown in research
field, and I thus think that the structure used in Player should reflect
this matter. It's not only us who need it: I mean, I can't really think
about future developement of this technology without exploiting all the
possibilities it can offer... moreover if someone else is already going
that way.
That's why I think a fundamental change has to be made: adding a field
in player_rfid_tag_t for storing tag data, and using dynamic size for
storing GUID and data.

SUGGESTED CHANGES:
This is the suggested structure in file Player.h (in CVS version this is
in player_interfaces.h).
All the subsequent changes are omitted for brevity.

// type, guid_count, and guid are left for immediate usage and further
compatibility
// data_count is needed to construct the message that will be sent back
to the Client
// data is needed to store informations on the tag. This is also a more
complex use already envisioned for the evolution of this technology


/** @brief Structure describing a single RFID tag. */
typedef struct player_rfid_tag
{
  /** Tag type. */
  uint32_t type;
  /** GUID count. */
  uint32_t guid_count;
  /** The Globally Unique IDentifier (GUID) of the tag. */
  char * guid;
  /** Data count. */
  uint32_t data_count;
  /** The data stored on the tag. */
  char * data;
} player_rfid_tag_t;

/***************/


Does anybody have any suggestions on I should change (more than all the
files wich won't compile after the changes)?
If you need more details feel free to ask.

Thanks in advance to everybody.