would it make sense to consider integration of Fnorb with/into the Twisted framework?
From what I understand, integration of the Fnorb event loop into twisted is the biggest issue, and as far as I can guess, some other possible integration targets could be:
- integration/addition of the Fnorb type registry; Fnorb has its own Type Repository for CORBA types, and for example the twisted SOAP implementation has a similar mechanism for SOAP types, I think...?
- modification/enhancement/? of Fnorb CORBA protocols from Fnorb (GIOP, IIOP,...) so that they are usable as Twisted Protocol implementations in their own right
This would open some quite interesting possibilities, such as almost-trivial(?) creation of SOAP/XMLRPC/? <-> CORBA proxies (protocol & type translation), use of CORBA Services from Twisted, or all Twisted facilities from CORBA, etc. etc.
Am I just daydreaming or could this be done? :-)
Petri
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<i>From what I understand, integration of the Fnorb event loop into twisted is the biggest issue,</i>
Since I've never seen Twisted before, I'm not aware of any issues, large or small. Is this being discussed somewhere?
<i>would it make sense to consider integration of Fnorb with/into the Twisted framework?</i>
I don't think so, no. But then, I don't really understand what Twisted actually is at the moment.
My instinct is that we are better off staying small and lightweight, and that there aren't any real advantages in merging with some other framework at this stage.
As for a low-impact integration of Fnorb and Twisted - just enough to integrate the event loops - I would be all for it if someone wanted to donate it.
<i>This would open some quite interesting possibilities, such as almost-trivial(?) creation of SOAP/XMLRPC/? <-> CORBA proxies (protocol & type translation), use of CORBA Services from Twisted, or all Twisted facilities from CORBA, etc. etc.</i>
Can't all this be done already, where it is actually feasible (assuming that you have provided integration with the event loop)?
Why exactly can't you use the Twisted facilities from Fnorb invoked code? I don't see the problem, event loop notwithstanding.
As for automated integration of SOAP and CORBA types and creation of proxies, my feeling is that they are too different for this to be really feasible ie there is no sensible mapping between them. I think :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
defines a WSDL-to-IDL mapping which Fnorb might chose to implement. However, it is questionable whether Twisted would be of any use in implementing this specification.
specifies how SOAP can be used as a CORBA transport (essentially an IDL-to-WSDL mapping). Again, whether Twisted would be useful in implementing that specification, I don't know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for pointing these out. However just because it exists doesn't mean it's complete.
The major issue that I see, that of representing object references in SOAP, is simply dodged with some hand waving.
Then there's recursive sequences, which are simply forgotten. And finally the issue of the representation on type codes in SOAP is hand-waved around by referring to "XML Schema", with no more information. How are type codes represented in XML Schema? Who knows?
This appears to be pretty simplistic and naive (like SOAP itself I guess ;), and will never allow the automated construction of bridges for arbitrary IDL or WSDL. This sort of thing was tried once before with DCOM, and it failed, and now history repeats itself ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
would it make sense to consider integration of Fnorb with/into the Twisted framework?
From what I understand, integration of the Fnorb event loop into twisted is the biggest issue, and as far as I can guess, some other possible integration targets could be:
- integration/addition of the Fnorb type registry; Fnorb has its own Type Repository for CORBA types, and for example the twisted SOAP implementation has a similar mechanism for SOAP types, I think...?
- modification/enhancement/? of Fnorb CORBA protocols from Fnorb (GIOP, IIOP,...) so that they are usable as Twisted Protocol implementations in their own right
This would open some quite interesting possibilities, such as almost-trivial(?) creation of SOAP/XMLRPC/? <-> CORBA proxies (protocol & type translation), use of CORBA Services from Twisted, or all Twisted facilities from CORBA, etc. etc.
Am I just daydreaming or could this be done? :-)
Petri
<i>From what I understand, integration of the Fnorb event loop into twisted is the biggest issue,</i>
Since I've never seen Twisted before, I'm not aware of any issues, large or small. Is this being discussed somewhere?
<i>would it make sense to consider integration of Fnorb with/into the Twisted framework?</i>
I don't think so, no. But then, I don't really understand what Twisted actually is at the moment.
My instinct is that we are better off staying small and lightweight, and that there aren't any real advantages in merging with some other framework at this stage.
As for a low-impact integration of Fnorb and Twisted - just enough to integrate the event loops - I would be all for it if someone wanted to donate it.
<i>This would open some quite interesting possibilities, such as almost-trivial(?) creation of SOAP/XMLRPC/? <-> CORBA proxies (protocol & type translation), use of CORBA Services from Twisted, or all Twisted facilities from CORBA, etc. etc.</i>
Can't all this be done already, where it is actually feasible (assuming that you have provided integration with the event loop)?
Why exactly can't you use the Twisted facilities from Fnorb invoked code? I don't see the problem, event loop notwithstanding.
As for automated integration of SOAP and CORBA types and creation of proxies, my feeling is that they are too different for this to be really feasible ie there is no sensible mapping between them. I think :)
Actually, OMG has defined interaction between SOAP and CORBA. For example,
http://www.omg.org/docs/mars/03-03-03.pdf
defines a WSDL-to-IDL mapping which Fnorb might chose to implement. However, it is questionable whether Twisted would be of any use in implementing this specification.
In addition,
http://www.omg.org/docs/ptc/03-01-14.pdf
specifies how SOAP can be used as a CORBA transport (essentially an IDL-to-WSDL mapping). Again, whether Twisted would be useful in implementing that specification, I don't know.
Thanks for pointing these out. However just because it exists doesn't mean it's complete.
The major issue that I see, that of representing object references in SOAP, is simply dodged with some hand waving.
Then there's recursive sequences, which are simply forgotten. And finally the issue of the representation on type codes in SOAP is hand-waved around by referring to "XML Schema", with no more information. How are type codes represented in XML Schema? Who knows?
This appears to be pretty simplistic and naive (like SOAP itself I guess ;), and will never allow the automated construction of bridges for arbitrary IDL or WSDL. This sort of thing was tried once before with DCOM, and it failed, and now history repeats itself ;)