We are also concerned with the other stuff involved, e.g. saving the request so that it can be correlated with the results at a later time, validating the request in terms of whether the specific commands make sense for the hardware units requested etc. This is expensive for the large requests, but those requests (often with thousands of ids) is usually only carried out once a day and often during the night. It is acceptable that this request takes hours to complete (worst case up to 6-8 hours, most of the time spend in the network). The priority here is that the radio network, is utilized efficiently, because if not, the request will take more than the night to complete.
During the day several smaller request will be made against more specific hardware ids. These request can contain between 1-500 ids and again the network is the primary bottleneck. I understand your concern regarding unbounded result sets, and hopefully we will be able to design it differently in the future, as the hardware get smarter and better but for now I can't see how we can do it much differently, but performance is a major concern for us. So as to whether the collection size limit of 256 items is reasonable or not, I guess it depends, I still believe we have a valid scenario where it should be bypassed. -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/J-KXC0uju4cJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
