What would be the correct way?

You have a constantly changing slide show of 30 images - and you don't want to upload new images into the Xibo Library, you want some other method?

Id say that if you want the client to show them nicely (precached, etc) then the only way to achieve this is to upload them in the library and change the layout. Sounds to me like you want to have this done automatically, perhaps with a PHP script that uploads new media and updates the layouts for you.

Or maybe a new media item called "slide show" which takes a selection of images based on their tag... you could then alter what was shown by changing the tags...

Not sure to be honest, it doesnt really fit with what we have... ill think on it!

At this time, the most what would fit, is the Ticker. But this in only limited to the Title, Date and Description. The adding of enclosure could help (if this would be pre-loaded and cached because this also in most cased is an url to fetch the enclosed image/audio fragment)

My current solution is to have the client in offline mode and have a (php) script that generates rf.xml, schedule.xml and needed *.xlf files and store it somewhere in the /media tree. and also rsyncs it to other (offline)clients.
The drawback of this solution is that no layout can be edited in the admin interface. The layout is hardcoded into the (php) scripts.

Why don't you turn that on its head and update the server interface via a PHP script instead?

In fact, you might be able to do it "properly" and use the XiboAPI (info on the wikk), the API is a work in progress but might contain enough methods for your needs.

I still wonder if a slideshow module would be more suitable, but I think we will still have the same problem of uploading the new content.

The XiboAPI is work in progress. The first attempt to use the XiboApi, resulted in a "Not implemented.". And that was on one of the first examples of the wiki ( services.php?service=rest&method=version ) . So give a little bit up on that.

Instead of using the XiboApi, i could directly connect to the database and insert the necessary tables rows and scp/rsync the images to the library folder. But for this i hoped that xibo would use more of a rational database approach to store the layouts and not directly the (complete) xml data inside mysql.

For now i have a script few scripts that will securely copy the images to the xibo server. Call a script on the xibo server that will import the images to the library and modify the xml data of the layout (dynamically so that i still can make changes to the layout by the xibo web interface).

That is odd, version was the first method i implemented and im pretty sure it should be in each version.... I admit it is a little lacking at the moment, I ran out of time.

Our test suites allow us to upload files and create layouts through the API, so the basics are there.

If you are interested you could list out the methods you think you'd need to call and I can see if I can put them in for you.

As for the database design - it might not be completely relational, but it certainly is rational :-) Layouts are stored that way because:
 - We didnt want to go through the expensive process of generating some XML each time a client wanted a MD5 or XLF for a layout
- Each media node can potentially have a different XML structure, and we didn't want to introduce any confusion by having a table per media item.

Sure, we could have done it and worked around it (layout based media could have its own table... and XML could be generated and cached each time a change was made or requested). Fact is that if the API was working it wouldnt matter as there are methods for manipulating media on layouts, region ordering, etc already written - makes it quite easy if you know what to include.

in service.php there is a switch (line 44), In this switch only "case 'soap'" is still be used. The others "oauth" and "rest" are there as comment (line 63 -151) with the comment on line 63: /* DISABLED IN 1.1.
This is why the version check which i mentioned before fails. The REST request goes to the default...
    153 default:
    154 $serviceResponse->ErrorServerError('Not implemented.');

With this in mind, the documentation (http://wiki.xibo.org.uk/wiki/XiboAPI) is a bit out-dated.. not the most pleasant way to start when new to an API ;)

As Dan said its a work in progress. We've never released it as a complete polished feature. The documentation you refer to is largely correct and there is a test suite for it. Cut us a little slack or wait for it to be officially released!

I should have mentioned that it wasn't released yet, sorry. It is in 1.3.3 if you want to try (again its still not released, you would be the first person to try it).

Depending on my time i will go and test a 1.3.3 solution from next week.
As i said, for now i have a working version with 1.2.2 which will be used this weekend...