Personally, I find the approach of thinking of communication as RPC problematic. I think it can lead to APIs that set up data piecemeal instead of atomic calls that update an entry.

For example, your CMS might have methods like ->set_title and ->set_body for an item. I think it would be quite bad to expose these procedures to the outside world. The API should be /item/create and /item/update, both of which supply the complete information to create or update the item. That way, you prevent confusion if only one of the calls succeeds and the other fails.

But have the irons been ironed already ?

(further links)

I am not sure whether I need to go as far as writing a daemon using RPC::Any::Server for my CMS, in order for the mobile apps to use the CMS as the data and logic "hub".

This is a web based CMS, that is already written to be compatible with Apache::mod_perl, so I guess it would be unnecessary to wrap it in its own daemon, when Apache essentially does that, as well as provide much other web related functionality, such as cookie based client authentication, logging, caching, memory and performance optimizations etc.

What others said about the value of previous advice is accurate.

such as cookie based client authentication, logging, caching, memory and performance optimizations etc

Apache cannot do some of that (memory and performance) for your code and might or might not be doing other parts as expected or to best practices. This thread is a bit vague though so it's hard to give real advice or discuss individual issues.

For my part, I am almost always going to agree with anything Corion or LanX recommend. Yes to REST, never-ever to SOAP, yes to Ajax/HTML5 + whatever functionality (for persistent authentication or location services for example) the mobile device exposes through it that you need; use device agnostic JavaScript libraries. Keep up to date with security, OWASP is your best one stop shopping. nginx + uWSGI + plack harnessed apps should be preferred over apache and modperl. Always use standard packages like JSON::XS. Never roll your own. It seems easier or faster than frameworks, like Mojolicious, at first but except in the most trivial cases where you already know what you're doing, it's false economy. Take the learning hit up front instead of floundering your way to it down the road or landing in maintenance Hell.

Great post, Your Mother. Thanks.


Actually, it was me that mentioned your quoted keywords in response to a user suggesting I should modify my CMS to use RPC::Any::Server in order for it to act as a hub for the various mobile app clients.
I especially liked reading about what PSGI/Plack is.
Seeing this CMS is 100% object oriented, with most packages relying on package inheritance, making it Plack "harnessable" should not be too difficult. (famous last words)
This web CMS essentially only has a single point of entry with every web request going to its main handler, which in turn invokes the relevant CMS Perl Package to handle the GET or POST, then return its HTML as a string ref to the main handler.


Thanks for the homework
Cheers,
Konstantinos

Sundial doesn't know anything about HTML, the web, programming, frameworks, interfaces, computers. He is the worst user on the site: http://perlmonks.com/?node=Worst%20Nodes. None of his code works. Don't waste time reading the mess they spew upon this site.

😂😂😂 lol

So he's just good at trolling innocent monks trying to go about the programming business? Funny guy.