apis

Moved to official ideas list: http://drupal.org/node/237907

I want to propose a project for building a module that pulls news content from a global news service called Daylife (http://daylife.com)

Daylife is a global news aggregation service that offers an Open API platform called DayPI (http://developer.daylife.com) for any developer, blogger, news service to pull stories and photos about any topic in the world. The API returns data in XML, JSON and PHP serialized formats. You can read the Daylife About page at http://www.daylife.com/page/about to learn more about the company. All platform documentation is on http://developer.daylife.com/docs

.

.

As some of you know, I've recently taken over maintenance of Inline and Image Assist, and initiated the Wysiwyg project. That was not only caused by personal interest, but also to take the necessary steps to realize the long awaited Inline API. You might ask yourself, what those three modules have in common or to do with each other at all: They deal with user input, allow to embed complex contents into a content, and provide an interactive GUI for that. If you already had the chance to work with them, you already know that there is a rather hidden, non-obvious hard-dependency between them.

Although I'd really like to discuss both topics (Inline and Wysiwyg support) separately, the gained experience on these topics enforces us to discuss them concurrently. The following mockup hopefully explains why: (see attachment to view in full size)

Myself and a few developers are about to make some rather big changes to the userpoints module API which would force all contributed modules (contribed to the userpoints module that is) to change. We'd like to get as much feedback on these changes as possible.

If you use userpoints and/or any of the userpoints contributed modules please take a minute to comment on these two threads
http://drupal.org/node/153626
http://drupal.org/node/151037

Thanks!

Per snelson's (creator of these amazing sites) description of the Services module:

Here's the low-down on the upcoming.org integration module:

Per the developers description: The upcoming.org module enables you to import events and venues from upcoming.org and display them in a calendar using the event module. Upcoming.org is a website that helps you share and keep track of your events. Synchronizing (using upcoming.org as the master repository) is also supported. Additionally, this module exposes the upcoming.org REST API, making clients written to use it interoperable with Drupal. This makes it possible to build a whole network of websites sharing their events, all using a defined API.

One of the major VotingAPI improvements that's been in the pipeline for a while is an overhaul of integration with the Actions module. At present, the voting_actions module is used to set up specific vote results that will trigger things like promoting a node to the front page, or unpublishing it. There are some problems with the approach, though. First, there was no way for module authors to provide 'built-in' voting actions. Everything had to be set up by users. Second, there was no way to make decisions about action execution based on the content rather than the vote. In other words, polls need 10 votes to be promoted, but stories need 15. Third, there's really no reason that the functionality should be in a separate module -- actions integration should be exposed as an API for module writers, and should be tweakable by users who want more customization. It's a bit like the Views module philosophy: modules can expose default bviews, but users can make their own or override the defaults. To that end, the new VotingAPI actions system has been re-written. All the core code IS present, though the end-user UI for creating and overriding actions is still being written.