You touched a nerve here actually. ORBit has some sort of client authentication built in which means it can't interoperate with any other ORB. That to me is defeating the whole purpose of CORBA. If you can't interoperate with other ORBs you might as well write your stuff in your own programming language and develop your own APIs. Besides Having read Bonobo intro it doesn't look as good as the old KParts (I hope the new DCOP based KParts are just as clean). Bonobo otoh is a COM ripoff - it uses CORBA only to do marshalling and IDL.
yes I'd definitely agree with this. The amount of exception handling code you have to do is boggling in CORBA. But it's still better than the DCOM's HRESULT value;). But what about the fact that everyone and their uncle announcing the advent of Application Service Providers? Surely if KDE was transparently distributed by nature it would make it a big player in this world woudn't it?
Thanks for clarifying that. I imagine though that most component models (including COM) don't specify how rendering of components get done. That would make them totally inflexible. Of course they would have to write a layer on the top of CCM but I imagine the same applies to DCOP.
I don't buy it. I do CORBA programming for living (and we use MICO actually) and it's ROCK SOLID. It's better than some commercial vendors so if they endured stability problems it's most unlikely that MICO is at fault.
Memory usage and performance are not any worse than any other distributed computing environment which will always have inherent marshalling overhead.
Perhaps DCOP is a better solution. I don't know DCOP. But OMG is busting its gut to add decent component model to CORBA and if KDE or another desktop environment utilised it I'm sure it would be a good test for the OMG spec. Also KDE would be completely interoperable with CORBA components that may be developed in future.
There is no official standar yet. Submissions are still being accepted. But I think it will come together very quickly. You may read this for a starter.
I don't have Kleopatra (yet) but I run the 06082000 build and it just keeps getting better. A lot of more evident bugs that were in Konfucious are gone now and the whole lot is really coming together. My only concern is the state of Konqueror which still seems too flakey for any real browsing, still looks more of a proof of concept thing. Koffice is usable now as is and I can recommend Kword to anyone frustrated with the hopeless UI of MS Word. I never used FrameMaker but this frame concept has much more appeal to me than the blooming MS Word templates that never work properly for anything beyond a two page letter.
I have a big beef with KDE though. No not the licensing silly! It's the fact that they ditched Corba as their component architecture. Why? It's not slow at all if you use in-process servers it's elegant in most languages and wiht the addition of POA it's extremely flexible. The argument that CORBA is to difficult to master for Joe sixpack developer doesn't hold anymore since the Henning Vinoski book's out. My biggest concern is that with OMG adopting the Corba Component Model all DCOPs and Bonobos will effectively become proprietary solutions. CCM will provide good intergration with JavaBeans which I'm sure all Java affectionados will appreciate too. Why oh why did they have to rid of CORBA?!
Any change outside that scene branch (i.e., window movement) never affect the client process.
Ah right. So basically the lower overhead comes from a lower granularity of server upcalls... I guess that is a logical way of doing it. Anyway I'm sure you have thought through this quite a lot. I think Berlin is looking really good now. I always thought that using CORBA would be possible and efficient in a modern windowing system so I'm really hoping for this to be the Next Big Thing. Keep it up!
The parent post is quite correct that getting new code onto the server is a question the Berlin team have not yet addressed - though if I remember correctly there are a number of approaches that might work, including adding new widgets as remote CORBA objects.
Yes. This should be easily doable with CORBA. I see no reason why they can't utilise an interface repository to register new Berlin widgets and use some CORBA service (is it trading?) to negotiate what the client requires. This is the whole purpose of the dynamic interfaces of CORBA. Perhaps there are performance issues that may be an impediment. Dunno.
This could have more serious implications for entry visa refusals.
When I applied for a Canadian visa I had a background check performed in every country that I had lived in. This is a routine procedure if you want to settle in Canada. In my case it was all clear but I can imagine the frustration of someone rejected on the grounds of a failed background check especially once they shelled out $1500CAD for their landing papers. The big problem here is that you have no control over how the Canadian government screens the immigrant wannabes. If you fail their medical or background checks they just send you a refusal note with a couple of weeks to appeal.
I wonder if they too use private companies to do this kind of job. I saw once on misc.immigration.canada a post from somebody that claimed he was erroneously failed in the background check.
I'm quite sure CORBA does create a slight performance hit when making calls to the display server
I honestly doubt it. CORBA supports in-process servers pretty much like COM/DCOM. So for a server that runs in the same address space most ORBs (including omniORB - Berlin's orb of choice) will not marshall but just use one virtual function indirection to execute the call. So the overhead is minimal by most standards. With CORBA it's a sort of pay as go scenario just like in C++. If you have distributed objects you have the overhead. But if you go for colocated clients/servers things become quite quick again.
Slashdot Mirror
You touched a nerve here actually. ORBit has some sort of client authentication built in which means it can't interoperate with any other ORB. That to me is defeating the whole purpose of CORBA. If you can't interoperate with other ORBs you might as well write your stuff in your own programming language and develop your own APIs. Besides Having read Bonobo intro it doesn't look as good as the old KParts (I hope the new DCOP based KParts are just as clean). Bonobo otoh is a COM ripoff - it uses CORBA only to do marshalling and IDL.
yes I'd definitely agree with this. The amount of exception handling code you have to do is boggling in CORBA. But it's still better than the DCOM's HRESULT value ;). But what about the fact that everyone and their uncle announcing the advent of Application Service Providers? Surely if KDE was transparently distributed by nature it would make it a big player in this world woudn't it?
Thanks for clarifying that. I imagine though that most component models (including COM) don't specify how rendering of components get done. That would make them totally inflexible. Of course they would have to write a layer on the top of CCM but I imagine the same applies to DCOP.
Memory usage and performance are not any worse than any other distributed computing environment which will always have inherent marshalling overhead.
Perhaps DCOP is a better solution. I don't know DCOP. But OMG is busting its gut to add decent component model to CORBA and if KDE or another desktop environment utilised it I'm sure it would be a good test for the OMG spec. Also KDE would be completely interoperable with CORBA components that may be developed in future.
There is no official standar yet. Submissions are still being accepted. But I think it will come together very quickly. You may read this for a starter.
I have a big beef with KDE though. No not the licensing silly! It's the fact that they ditched Corba as their component architecture. Why? It's not slow at all if you use in-process servers it's elegant in most languages and wiht the addition of POA it's extremely flexible. The argument that CORBA is to difficult to master for Joe sixpack developer doesn't hold anymore since the Henning Vinoski book's out. My biggest concern is that with OMG adopting the Corba Component Model all DCOPs and Bonobos will effectively become proprietary solutions. CCM will provide good intergration with JavaBeans which I'm sure all Java affectionados will appreciate too. Why oh why did they have to rid of CORBA?!
Ah right. So basically the lower overhead comes from a lower granularity of server upcalls... I guess that is a logical way of doing it. Anyway I'm sure you have thought through this quite a lot. I think Berlin is looking really good now. I always thought that using CORBA would be possible and efficient in a modern windowing system so I'm really hoping for this to be the Next Big Thing. Keep it up!
They ask you to supply your proof of good conduct but on the top of that they do background checking on every candidate anyway.
Yes. This should be easily doable with CORBA. I see no reason why they can't utilise an interface repository to register new Berlin widgets and use some CORBA service (is it trading?) to negotiate what the client requires. This is the whole purpose of the dynamic interfaces of CORBA. Perhaps there are performance issues that may be an impediment. Dunno.
When I applied for a Canadian visa I had a background check performed in every country that I had lived in. This is a routine procedure if you want to settle in Canada. In my case it was all clear but I can imagine the frustration of someone rejected on the grounds of a failed background check especially once they shelled out $1500CAD for their landing papers. The big problem here is that you have no control over how the Canadian government screens the immigrant wannabes. If you fail their medical or background checks they just send you a refusal note with a couple of weeks to appeal.
I wonder if they too use private companies to do this kind of job. I saw once on misc.immigration.canada a post from somebody that claimed he was erroneously failed in the background check.
I honestly doubt it. CORBA supports in-process servers pretty much like COM/DCOM. So for a server that runs in the same address space most ORBs (including omniORB - Berlin's orb of choice) will not marshall but just use one virtual function indirection to execute the call. So the overhead is minimal by most standards. With CORBA it's a sort of pay as go scenario just like in C++. If you have distributed objects you have the overhead. But if you go for colocated clients/servers things become quite quick again.