Hi,
Yes , I agree with that, because Remoting is a fairly high level namespace/functionality of the.Net framework and therefore had to depend on alot of the parts below it.
Mono at that time was in version 0.26, and surely anything in the level of Remoting or even lower should have been changed to use the better/modified parts of.Net.
Anyway, all we need to conclude is
a) No decompilation was carried out
b) The initial code that was written wasn't "useless" and surely helped whoever changed/modified it.
Hussein
Hi,
I agree with what Ahmad Tantawy and Ahmad Kadry have mentioned. I would like to add the following:
1- We consulted Rotor code for the Http client channel only, that was ambiguous at that time and we needed more information to understand how URLs are dealt with. This is the only part where we looked into Rotor.
If anybody has the chance to look into our code and the Rotor code, will definately find differences, specially on the server channel side.
2- Miguel mentioned , that the code has been mostly changed and the remaining is broken. Well, I would expect so, for many reasons, one of them, is because that we didn't not do deep exception handling which we did admit so. Simply because, we anticipated that alot will be changed as the mono framework becomes more mature.
On top of that, Mono V1.0 wasn't released yet, and therefore you could imagine the bugs and incomplete classes and namespances that were not implemented at that time. So for us to implement most of the functionality, we had to use the best out of what was available but at the same time is not good enough to stay forever and has to be changed when the framework is mostly completed.
An example was the Socket class and how you had to loop until all the data you want to send is actually sent; which contradicts the standard.Net Socket class.
I believe that contributing to mono was a great experience, and it was so only because we did not copy code from somewhere else!!
Hussein
Slashdot Mirror
Hi, Yes , I agree with that, because Remoting is a fairly high level namespace/functionality of the .Net framework and therefore had to depend on alot of the parts below it.
Mono at that time was in version 0.26, and surely anything in the level of Remoting or even lower should have been changed to use the better/modified parts of .Net.
Anyway, all we need to conclude is
a) No decompilation was carried out
b) The initial code that was written wasn't "useless" and surely helped whoever changed/modified it.
Hussein
Hi, I agree with what Ahmad Tantawy and Ahmad Kadry have mentioned. I would like to add the following: 1- We consulted Rotor code for the Http client channel only, that was ambiguous at that time and we needed more information to understand how URLs are dealt with. This is the only part where we looked into Rotor. If anybody has the chance to look into our code and the Rotor code, will definately find differences, specially on the server channel side. 2- Miguel mentioned , that the code has been mostly changed and the remaining is broken. Well, I would expect so, for many reasons, one of them, is because that we didn't not do deep exception handling which we did admit so. Simply because, we anticipated that alot will be changed as the mono framework becomes more mature. On top of that, Mono V1.0 wasn't released yet, and therefore you could imagine the bugs and incomplete classes and namespances that were not implemented at that time. So for us to implement most of the functionality, we had to use the best out of what was available but at the same time is not good enough to stay forever and has to be changed when the framework is mostly completed. An example was the Socket class and how you had to loop until all the data you want to send is actually sent; which contradicts the standard .Net Socket class.
I believe that contributing to mono was a great experience, and it was so only because we did not copy code from somewhere else!!
Hussein