thats where the problems started. for historical reasons, (and since it makes perfect sense in a non web services context) postnuke functions contain a lot of assumptions about the gui in its functions.
in my case, i did not need the gui part of the code, in fact it stood in the way. so i copied the functions and stripped them down to just the core logic. this turns out to be mostly about calls to the mysql database.
i would like to work on exposing a subset of postnuke functionality as xml-rpc api's. to do this, i suggest the existing code be reworked over time to split gui from backend code.
the code for posting an article, for instance, could be split into a method to display all the necessary gui elements and give user feedback, and another function that does just the database modifications.
my xml-rpc glue code would then be free to call these backend functions directly, as would other code that might, for instance, implement a different gui altogether (maybe a wml gui?)
i think such an architecture would make postnuke
even more modular, and would allow modules to more closely integrate with core code, without changing the core.
what do you think? (i hope i made my point somewhat clear. on rereading, it sounds not all that concise.. but i was in a hurry.. :)
PS: why would we want an xml-rpc interface for postnuke, you might ask? i'd say the possibilities for hooking up postnuke with other systems (cms, newsfeeds, search engines etc) are worth it.
1259