communication between codeigniter apps

[eluser]Pascal Kriete[/eluser]
Isn't this what XML-RPC was made for? You provide the xml-rpc server, and give your users a basic outline what requests are possible and what responses they can expect. And since CI does this natively, it should be a breeze to set up.

[eluser]Thoer[/eluser]
Yes, XML-RPC is probably the way to go. I looked at it yesterday and I thought there might be something faster since it won't have to work between domains and I can be sure it will be used by codeigniter apps only, but I guess it doesn't really matter. This may be a bit slower than my solution because of the xml translations, but it looks a lot more elegant.

Okay, application beta is about to be released this week, and the CodeIgniter community just solved another problem in practicly no time. Thank you guys!

[eluser]frenzal[/eluser]
you could always look in to webservices

[eluser]Thoer[/eluser]
[quote author="frenzal" date="1207138593"]you could always look in to webservices[/quote]
What do you mean?

[eluser]wiredesignz[/eluser]
XML-RPC is Web Services

[eluser]frenzal[/eluser]
sorry then, i always think of soap when i think webservices
xml-rpc is just "that other thing i havent used yet"

[eluser]Thoer[/eluser]
I'm a lot more familiar with xml-rpc and soap seems to be a bit heavyweight for this case, but thanks for the idea!

[eluser]BorisK[/eluser]
XML-RPC makes total sense if you plan to separate the application front and back ends on different servers. However, I don't see how XML-RPC is more elegant than a direct method/function call on the same server.

Forget the symbolic link for now, as you could go without it. You could place your library in the include path and have PHP find it.

I think if you use XML-RPC on the same server you're just wasting CPU cycles wrapping and unwrapping your calls in XML.

[eluser]Thoer[/eluser]
Yeah, it seems to be a valid point, but I'll definietly implement some XML-RPC services. It's one thing to inlude the library itself, but obviously the maillist app requires quite a few configs in order to work correctly. Just think of two apps that even uses the same library, but are using different table prefixes. It would be hard to get the config of the included app, but not only that, you would have to restore the caller config files if there's anything left to do. It's definietly possible, but quite ugly. What do you think?

[eluser]BorisK[/eluser]
Thoer, you never fully described your application needs. Originally it was just front and back end of one application. Now you're talking about multiple apps, table prefixes, config files, etc. This reminds me of some of my clients

You don't have to mix config files, tables and other components. That's what OOP is all about. Isolate your code from the rest and deal with one thing at a time. If your mailing list application has a lot of configuration options why not create a class for it, instantiate a class and set the config options via method calls. Or if a client needs to change a thing or two, use OO inheritance and overwrite certain features.