Hi -
I've revised the problem statement. Thanks for the feedback.
"To provide a modular mechanism for delivering the required data to the
AI client which is scalable, delivers high performance, and provides a
compelling user experience."
ginnie.
On 05/11/09 14:40, Dave Miner wrote:
> sanjay nadkarni (Laptop) wrote:
>> Virginia Wray wrote:
>>> Hi -
>>>
>>> I've been thinking more about the problem statement. I would like to
>>> broaden and hone it at the same time. Here is what I've come up
>>> with, and I welcome any feedback:
>>>
>>>
>>> "To provide a mechanism for delivering the AI manifest and install
>>> image to the AI client which is scalable, delivers high performance,
>>> and provides a good user experience."
>>>
>>>
>>>
>>> I've used the term mechanism instead of webserver so that we leave
>>> options open. I think "delivers high performance" is a little vague,
>>> but I think that can be solved by defining what high performance means.
>>>
>>> I was talking with Sanjay, and he asked me a couple of questions -
>>>
>>> 1. For what we are doing, is it worth having an entire webserver to
>>> do this?
>>>
>>> 2. In the user environment, is the data that we are dealing with
>>> going to be static or dynamic?
>>>
>> To elaborate, can we clearly describe what types of data we will be
>> dealing with this mechanism. We probably have a good understand of
>> what we do now. But what about in the future ?
>>
>
> Types, volumes, and peak loads would all seem to be important
> characteristics to define. And I'd actually throw one additional
> requirement in: that the mechanism be modular with respect to the rest
> of the installation, such that it can be evolved/replaced with
> alternate protocol sets. At least one user has expressed a lot of
> interest in using torrents, for example.
>
> Dave
