Hi Scott (and rest of IBM team),
I wanted to take some time to go over some of the outstanding feature
requests for Rifidi Tag Streamer. As we had talked about we think that
most of the original feature set was discussed and we have implemented
most of the ones that we jointly felt were important to complete the tool.
The one feature that we had outstanding was the one outlined below.
---------------------
7. The current XML tag streamer file has reader definitions contained within
the segment definitions. While this is fine for simulating a fixed assembly
line of tags passing by one or several readers it is not sufficient for a
general load generation scenario where readers can be geographically dispersed
and not exposed to the same set of tags.
Is it possible to specify a pattern of tags (and GPIO events) on a per
reader basis so that each reader can generate tag reads and interact with the
gateway/data capture independantly?
---------------------
In order to implement this feature there are core parts of our architecture
that will need to be changed. The reason for this is because the Tag Streamer
application is quite tied to the structure of our XML and the new features
represent a change in the way our original XML and load generation was
designed.
So before we proceed further we wanted to first make sure that we have
understood the requirements and that we come up with a solution together.
So as we see it here is a general summary of the requirements:
1) The segments (the basic action sequence) of a scenario are too coupled with
the readers and data that it needs.
2) It would be great to have a template mechanism. What this means is that a
template (scenario) can be defined that describes the scenario. This template
would have informations strictly about the path and flow of GPI events and Tags
in a scenario.
3) This template (scenario) can then be filled in with any type of reader or
RFID device by linking logical names.
4) The template (scenario) is then input a data file or a dynamically
generated one that can generate tags and events. This will then flow through
the template (scenario) on the path that was defined without any further
interaction or tight coupling of data and actions.
I think that the requirements was meant to address the tight coupling that now
exists in the various XML files and logic of the Tag Streamer.
In response to this Kyle and Andreas have come up with a design and solution to
best handle these requirements. The new design and sample XML files can be
found at:
http://wiki.rifidi.org/index.php/TagStreamerSpecification
What we are asking from your team and any interested Rifidi contributer
is to first look at these requirements and see if they make sense. Then
to look at the design and see if this will satisfy the requirements.
Again the goal of tag streamer is to be a user friendly RFID load
generation tool that can accurately mimic real scenarios as easily as
what-if system load scenarios. The new design and implementation should
be a step in this direction.
Thanks and sorry for the long email blast.
Prasith
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Rifidi-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rifidi-developers
