Hi Zubair,
Awesome!! Keep up with the good work. Let me know if you need anything else.
Cheers!
On May 27, 2011, at 3:27 PM, Zubair Nabi wrote:
> Hi Adriano,
>
> No. I was having issues adding the common repository to the mobile repository
> as submodule but Luis and Rodolfo helped me solve that problem.
> A couple of messages were missing from the .proto. I added them.
> Now I'll add the optional messageType field for p2p messages.
>
> On Fri, May 27, 2011 at 10:55 PM, Adriano Monteiro Marques
> <[email protected]> wrote:
> Hi Zubair,
>
> You have write perms there already... are you having any issues with that
> repo?
>
> On May 27, 2011, at 1:04 PM, Zubair Nabi wrote:
>
>> Sounds good. Let's keep it a string. The type would be the name.
>>
>> Let's keep it optional. It will be used in p2p communication but not in
>> aggregator communication.
>> So this is the extra field that I propose:
>>
>> optional string messageType = x;
>>
>> Does everyone agree?
>>
>> Adriano - Do we have write access to the common ICM repository?
>>
>> On Fri, May 27, 2011 at 8:59 PM, Zhongjie Wang <[email protected]> wrote:
>> Hi Zubair,
>> That's a good way. I agree. :)
>>
>>
>> On Fri, May 27, 2011 at 11:49 PM, Zubair Nabi <[email protected]>
>> wrote:
>> That's a very good point. In case of p2p agents we will only be sending
>> messages using a standard send function. So, there is no way to tell the
>> message type. We should add an int32 for message type considering that we
>> have a standard number of messages.
>> If int32 messageType == 1 then that could an authentication message and so
>> on. What do you say?
>>
>>
>> On Fri, May 27, 2011 at 8:44 PM, Zhongjie Wang <[email protected]> wrote:
>> Hi Adriano,
>>
>> Sorry, I didn't see the email of that doc. Then it's perfect. :)
>> There's one more question, how to detect the message type when I receive a
>> message?
>> Is there any field to indicate the type?
>>
>>
>> On Fri, May 27, 2011 at 11:34 PM, Adriano Monteiro Marques
>> <[email protected]> wrote:
>> Hi Alan,
>>
>> On May 27, 2011, at 12:30 PM, Zhongjie Wang wrote:
>>
>> > Hi Zubair, Diogo:
>> > I hope you guys could join and figure out the detailed message format
>> > for the communication interfaces. :)
>> > In the spec, we have decided to use RESTful webservice and RPC call for
>> > the communications. Now the
>> > form of RPC call is somewhat obscure, we need to make a clearly defined
>> > message format. Do you think we
>> > should still use protobuf, or json/xml, or customized binary/text format?
>> > This is important.
>>
>> We've already decided on using protobuf, right? Event the ones we defined
>> today and shared with you in that google doc.
>>
>> > At first, there should be an authentication process after connected.
>> > Then we use the negotiated
>> > symmetric key to encrypt the following messages. The messages will be in
>> > pair, like Request/Response.
>> > For a request, there should be a RPC function name and then the
>> > parameters, finally maybe end with a checksum.
>> > And for a response, it will indicate which request it response to, and
>> > then the result.
>> > If we use protobuf, then we need to put the function name out of the
>> > message. So after the agent read the name,
>> > it will generate a proper class for the message.
>> >
>> > How do you think which one we should choose?
>> >
>> > Regards
>> >
>> > --
>> > Zhongjie Wang
>> > Master Candidate
>> > Computer System Architecture
>> > Peking University, China
>> > ------------------------------------------------------------------------------
>> > vRanger cuts backup time in half-while increasing security.
>> > With the market-leading solution for virtual backup and recovery,
>> > you get blazing-fast, flexible, and affordable data protection.
>> > Download your free trial now.
>> > http://p.sf.net/sfu/quest-d2dcopy1_______________________________________________
>> > Umit-devel mailing list
>> > [email protected]
>> > https://lists.sourceforge.net/lists/listinfo/umit-devel
>>
>> ---
>> 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
>>
>>
>>
>>
>> --
>> Zhongjie Wang
>> Master Candidate
>> Computer System Architecture
>> Peking University, China
>>
>> ------------------------------------------------------------------------------
>> vRanger cuts backup time in half-while increasing security.
>> With the market-leading solution for virtual backup and recovery,
>> you get blazing-fast, flexible, and affordable data protection.
>> Download your free trial now.
>> http://p.sf.net/sfu/quest-d2dcopy1
>> _______________________________________________
>> Umit-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/umit-devel
>>
>>
>>
>>
>> --
>> Best,
>> __
>> Zubair
>>
>>
>>
>> --
>> Zhongjie Wang
>> Master Candidate
>> Computer System Architecture
>> Peking University, China
>>
>>
>>
>> --
>> 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
>
>
>
>
> --
> 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
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Umit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/umit-devel
