I am currently working on a proposal on switching from their own COM implementation to XPCOM
and I could really do with some advice from some of you experienced guys.
nice! I hope this goes well.
First of all what are your thoughts on switching such a large code base to XPCOM is it to big a task?
it is probably a big task, but some clever perl could probably take you quite a long way. Does the implementation use something similar to nsCOMPtr? Is there an equivalent to XPCOM's Component Manager? to nsresult and NS_SUCCEEDED()/NS_FAILED()? I'll bet that if you can figure out the obvious mappings, you could do the bulk of the conversion in an automated fashion with perl.
I know that the C implementation of XPCOM has only been discussed and no real code came out of it but
is it still feasible to do it?
it is probably a lot of work.. it would involve making C stub code out of he IDL, and matching headers. (which means hacking up the xpidl compiler to add a C front end) Personally I'd try to avoid that if possible and write your own C++/IDL interfaces to existing C APIs.
Is it very bad policy to use [notxpcom] in interfaces??
in general sure, but you could start by making things [notxpcom] and then transition stuff over to standard XPCOM on an as-needed basis. functionally all notxpcom loses is scriptability. semantically you lose well defined rules about object ownership and such.
Would it be possible to port XPCOM to Symbian (just the basics, no xptcall)?
I don't know much about Symbian but I'll bet it would be very easy. Most of XPCOM is totally cross platform. You might need some minor work in nsLocalFile implementations, and would probably need to port NSPR if someone hasn't already.
Alec
