Real time resource tracking use case

[mkgn]

I am trying to prototype a system for tracking resources. A resource can be anything (car, person, place etc…) I am trying to prototype two use cases.

1. Cab tracking scenario;
   
   1. Vehicles publishes it's location to server
   2. Server stores the current location in a database for history & other info
   3. Pass the vehicle location coordinates to subscribers fleet owners to visually see their vehicles on a map
   4. Traveler can request a cab to his current location
   5. Traveler can see the location of his cab if it's confirmed (only the assigned cab can be seen by the traveler since vehicles are always publishing it's locations)

1. Location based queries
   
   1. There are certain data stored in DB with coordinates related to the stored resources (ex:- restaurants)
   2. A user set a rule (ex:- Alert me if there are vegetarian restaurants within 1km of my current location)
   3. As user navigates; current location is passed to server which performs a geo query in database existing data and return data if any matches the rules.

After finding Lightstreamer I feel it's a better fit for this. I am trying to figure out how the data adapters be used for these two user cases. For example;



For fleet tracking; should I create a data adapter per fleet(ex:- cab service 1 & 2)?

How should be the data adapter operate for the 2nd use case?

What is the optimal subscription mode for this kind of use cases (DISTINCT?)

[mkgn]

So... no response means what I have mentioned above is unrealistic?

[DarioCrivelli]

Lightstreamer seems appropriate for the data exchange through the internet between the various actors involved.

For point 1.1, where the car position has to be uploaded, the sendMessage feature is available.

For point 1.5, where car positions have to be sent to travelers, MERGE mode seems more appropriate, because each new sample (i.e. position) obsoletes the previous ones. But if you want to ensure that many past observations are available for the sake of the graphic presentation, the DISTINCT also makes sense.

For point 1.3, where all car positions have to be sent at the same time, you can use multiple items.
But if the set of all cars is not constant, then it is a case of "two level push" and the set of cars can be kept updated with an item in COMMAND mode.

About the second use case:
If I understand correctly, there is a set of current matches that changes as the user moves. Hence, an item in COMMAND mode can be used, to add and remove elements from the set in real time.
In this case, the "item" corresponds to the result of a query, so the query must be in some way represented by the item name itself; how to do this is left to the application and clients and adapters must cooperate.
Since the query is based on the position (that, again, can be kept updated via sendMessage), this position, which is available to the Metadata Adapter, must be communicated to the Data Adapter.

About how to separate the items among multiple Data Adapters, we have no particular recommendations. It is a feature that you can leverage at your convenience.
Usually, different Data Adapters are associated with different channels to collect data from the back-end. Also note that if the clients wants to subscribe to multiple items in a single subscription operation, then all items must come from the same Data Adapter.

[mkgn]

Thank you for the explanations! I have another question about the subscribing for items. In the documentation it says that we can subscribe to an ITEM which has fields (some sort of a schema). As I understood, we can subscribe to the item or a field in the item. Is it correct?

If that is the case; For one of my scenarios I can have a parent item (company) & fields for each car that belongs to the company. So, for any employee they can subscribe to "company" item and get all updates from vehicles under that item. If anyone want to monitor only one car, they can subscribe to the specific car field.

If my understanding is correct; I may be able to make a hierarchical schema like;

[Holding Company]
------Company1
-----------Monitor1
-----------Monitor2
------Company2

[DarioCrivelli]

For the sake of precision, you can subscribe to an item AND you also have to specify the fields you are interested in.

Your use of the fields is not what we expect.
We assume that an item corresponds to some entity and that the fields are its attributes, so that the set of current field values makes up the current state of the item.
You can say that the state of the company is made of the positions of all its cars, but, since the cars are quite independent of one another, we would rather associate an item to each car.
In the latter case, in order to monitor all cars of a company, you would have to subscribe to all car-related items of that company.
This is not less efficient, and allows you to manage the addition or removal of a car with new subscriptions and unsubscriptions (for instance, by getting the current set of cars through an item in COMMAND mode, as already suggested). Note that, also with car-related fields, the set of subscribed fields is static: you cannot request "all available fields".
The only difference is that, with different items, the client cannot get the positions of multiple cars in a single update callback, but you will receive different updates in an unpredictable order, even if the car positions were sampled exactly at the same time. Would that be a limitation?

[mkgn]

Ok, got it!. Not being able to get an update about the cars at the same time will not be an issue. However a concern I have is that if each car will work as an item (which makes sense as you said); in general there can be thousands of cars in a car rental company. So, is there a limitation in LightStreamer as to how many items it can handle at a time? If there is a limitation is it something to do with available server resources such as RAM or CPU cycles?

I suggest it'll be good to have a demo code prepared for this kind of a use-case. May be with a google map and some mock up geo-cords to simulate a vehicle marker moving on a map!