This is the message I've got:
"
git.exe submodule add -- "[email protected]:/higwidgets.git" ""
Cloning into higwidgets...
ERROR:gitosis.serve.main:Repository read access denied
fatal: The remote end hung up unexpectedly
Clone of '[email protected]:/higwidgets.git' into submo
Just fixed for higwidgets, but umit-common is readable/writable by everyone
already. What is the error you're getting?
On May 27, 2011, at 10:38 PM, Zhongjie Wang wrote:
> Hi, I'm also having issues with downloading the higwidgets and umit-common.
> Seems no reading permissions. :(
>
> On Sat,
Hi, I'm also having issues with downloading the higwidgets and umit-common.
Seems no reading permissions. :(
On Sat, May 28, 2011 at 3:48 AM, Zubair Nabi wrote:
> Okay guys,
> I'm done with the .proto.
> I've made a number of changes. Please have a look at the changelog to
> follow them.
> I thin
Okay guys,
I'm done with the .proto.
I've made a number of changes. Please have a look at the changelog to follow
them.
I think these messages are now in a shape that we can start using them in
our code.
Just in case, please go through all the messages in detail (following the
flow of request/respo
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
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,
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
On May 27, 2011, at 12:49 PM, Zubair Nabi 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 nu
HI Alan!
No worries pal. In cases where more than one type of message can be received,
we try the one that occurs most first, and then the other if the first fails.
Every remote method will have a pre-determined request and response type.
Kind Regards,
On May 27, 2011, at 12:44 PM, Zhongjie W
But then we'll have to keep extra information to translate what every
messageType means. That's just extra information.
Rather than sending an int32 and then figuring out what it translates to,
wouldn't it be better that we keep it string to increase readability?
On Fri, May 27, 2011 at 9:22 PM, Z
nonono, your proposal in the previous email is quite right.
It's better to use a int32 fields prior to the message. then we can know the
message type after reading that tag field.
On Sat, May 28, 2011 at 12:04 AM, Zubair Nabi wrote:
> Sounds good. Let's keep it a string. The type would be the nam
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 t
Hi Zubair,
That's a good way. I agree. :)
On Fri, May 27, 2011 at 11:49 PM, Zubair Nabi 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 mes
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 a
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:
> H
Hi Alan,
Actually, the common .proto that Adriano just shared addresses all your
concerns. Can you please go through it and then we can decide if anything
needs to be added/subtracted. We will also be using the same messages for
p2p communication as well.
On Fri, May 27, 2011 at 8:30 PM, Zhongjie
Hi Folks,
In order to make sure we have always available reusable libraries, I created
two repositories that you guys must adapt your code to use and the respective
projects in our redmine:
[email protected]:/higwidgets.git -
http://dev.umitproject.org/projects/higwidgets/repository
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
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 define
Hi Alan,
Sorry messed up with the names!! Comment below...
On May 27, 2011, at 3:08 AM, Zhongjie Wang wrote:
> Where will the website content data come together in this message?
>
> That's a problem indeed. Because in the specification of protobuf, it is
> stated:
> "Protocol Buffers are not d
Perfect! I will check your changes this evening and if there are any problem
with the code I will let you know ;)
Sent from my iPod
On 27/mag/2011, at 05:21, Tiago Serra wrote:
> I just push to the remote branchs the versions of each audit ready with
> doctest and pcap files.
>
> I think is
21 matches
Mail list logo
