Hi all,
About the message format, I have some comments.
1. Seems there're duplicate fields in SendWebsiteReport and
SendServiceReport:
162<http://dev.umitproject.org/projects/icm/repository/revisions/master/entry/proto/messages.proto#L162>
// send_report
163<http://dev.umitproject.org/projects/icm/repository/revisions/master/entry/proto/messages.proto#L163>
message SendWebsiteReport {
164<http://dev.umitproject.org/projects/icm/repository/revisions/master/entry/proto/messages.proto#L164>
required RequestHeader header = 1;
165<http://dev.umitproject.org/projects/icm/repository/revisions/master/entry/proto/messages.proto#L165>
required WebsiteReport report = 2;
166<http://dev.umitproject.org/projects/icm/repository/revisions/master/entry/proto/messages.proto#L166>
}
In the RequestHeader structure to the aggregator, there're are token
and agentID. And in WebsiteReport.ICMReport, there're also agentID. Though I
didn't know the difference between token and agentID. I suggest we eliminate
the agentID field in ICMReport.
2. Besides that, the optional fields: redirectLink, htmlResponse,
htmlMedia, seems to be better in the WebsiteReportDetail structure, because
it's more test specific. I suppose the Report messages should have only two
parts, the header and the detail.
3. Since we don't have a field in the message to identify the message
type, I don't know how we can create a message instance after receiving a
bunch of raw bytes. Currently I send the message type string before send the
message itself. But I think the better solution is tag it in the message
structure.
4. Another slightly modification, I suggest that we use float type
for responseTime, the unit is seconds, for accuracy.
Best Regards.
Alan
On Sat, Jun 4, 2011 at 5:34 PM, Adriano Monteiro Marques <
[email protected]> wrote:
> Right, mainly for nodes who stays connected for long periods of time. Also,
> if we want a test to be run ASAP, we need to send this info everytime so the
> node knows of a brand new test version, updates their test set and run them
> ASAP. On the software version, if we figure any security issue, the nodes
> will also update ASAP.
>
>
> On Jun 4, 2011, at 6:22 AM, Zubair Nabi wrote:
>
> Hi,
>
> I think the idea was to keep the binary and test versions as fresh as
> possible. This ResponseHeader would make sure of that.
>
> On Sat, Jun 4, 2011 at 4:04 AM, Diogo Pinheiro
> <[email protected]>wrote:
>
>> Hi
>>
>> I have another question. Why the ResponseHeader has the currentVersionNo
>> and currentTestsVersion ? I think we shouldn't send that information all the
>> time. Just when the agent connect, and in a rpc call.
>>
>> What do you think ?
>>
>
>
>
> --
> Best,
> __
> Zubair
>
>
> ---
> Adriano Monteiro Marques
>
> http://www.thoughtspad.com
> http://www.umitproject.org
> http://blog.umitproject.org
> http://www.pythonbenelux.org
>
> "Don't stay in bed, unless you can make money in bed." - George Burns
>
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Umit-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/umit-devel
>
>
--
Zhongjie Wang
Master Candidate
Computer System Architecture
Peking University, China
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Umit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/umit-devel
