will there be a way in the upcoming releases to integrate campcaster and campsite to run a radio station with campcaster and create automatic posts in campsite?
> will there be a way in the upcoming releases to integrate campcaster
> and campsite to run a radio station with campcaster and create automatic
> posts in campsite?
>
I've previously discussed the idea of having a Campsite module which
displays metadata from the Campcaster schedule. This enables the
broadcaster to have an automated public website which shows what's
playing today at what time, what was played last Tuesday etc. It also
encourages Campcaster users to adopt Campsite, because of the wonderful
integration features :-)
If the metadata is rich enough, you can have a text description for each
programme, a still image, and (for programmes in the past) a
stream-on-demand or download-on-demand link. The BBC has something like
this with iPlayer:
This would fit neatly with the 'show' time slot concept that Paul and
Naomi are considering for a future release. A 'show' would be a
high-level item that occupies a certain time slot in the schedule, and
belongs to a certain user (i.e. other users cannot alter your show,
unless they have admin rights). The show can be a blank placeholder for
programme planning, and later it can contain files and/or playlists as
the time slot approaches.
For a live but pre-recorded show, a recording can be dropped into the
show time slot for scheduling. For a live non-pre-recorded show, a
recording can be dropped into the slot afterwards, for archive/repeat
purposes.
So the metadata displayed by the Campsite module would be grabbed from
the Campcaster show metadata for each time slot. This is convenient for
displaying schedules, because it's impractical and excessively verbose
to display every single playlist and file that the station is going to
playout today in a public web page.
For a live non-pre-recorded show this is impossible to display in
advance anyway - we only know that a certain presenter is on the air at
a certain time, looks like *x* photo and plays *y* kind of music for *z*
type of person.
Posts: 389Member, Administrator, Sourcefabric Team
I would suggest that we would have an API where anyone can develop a
Campcaster widget for their page. It shouldnt require any integration with
Campsite other than including the widget in the front end templates.
Also, the old Campsite/Campcaster integration wont work for 1.6 as the
database/file storage/API design has be significantly changed.
Paul Baranowski
Chief Technology Officer, Sourcefabric
>
> Hi Sava,
>
>
> > What do you mean by automatic posts?
>
> I've previously discussed the idea of having a Campsite module which
> displays metadata from the Campcaster schedule. This enables the
> broadcaster to have an automated public website which shows what's
> playing today at what time, what was played last Tuesday etc. It also
> encourages Campcaster users to adopt Campsite, because of the wonderful
> integration features :-)
>
> If the metadata is rich enough, you can have a text description for each
> programme, a still image, and (for programmes in the past) a
> stream-on-demand or download-on-demand link. The BBC has something like
> this with iPlayer:
>
> http://www.bbc.co.uk/iplayer/radio
>
> This would fit neatly with the 'show' time slot concept that Paul and
> Naomi are considering for a future release. A 'show' would be a
> high-level item that occupies a certain time slot in the schedule, and
> belongs to a certain user (i.e. other users cannot alter your show,
> unless they have admin rights). The show can be a blank placeholder for
> programme planning, and later it can contain files and/or playlists as
> the time slot approaches.
>
> For a live but pre-recorded show, a recording can be dropped into the
> show time slot for scheduling. For a live non-pre-recorded show, a
> recording can be dropped into the slot afterwards, for archive/repeat
> purposes.
>
> So the metadata displayed by the Campsite module would be grabbed from
> the Campcaster show metadata for each time slot. This is convenient for
> displaying schedules, because it's impractical and excessively verbose
> to display every single playlist and file that the station is going to
> playout today in a public web page.
>
> For a live non-pre-recorded show this is impossible to display in
> advance anyway - we only know that a certain presenter is on the air at
> a certain time, looks like *x* photo and plays *y* kind of music for *z*
> type of person.
>
> Cheers!
>
> Daniel
>
>
Posts: 113Member, Administrator, Sourcefabric Team
On Monday, November 08, 2010 15:47:38 Paul Baranowski wrote:
> I would suggest that we would have an API where anyone can develop a
> Campcaster widget for their page. It shouldnt require any integration with
> Campsite other than including the widget in the front end templates.
Agree. But we sould should ship a sample widget for this.
> Also, the old Campsite/Campcaster integration wont work for 1.6 as the
> database/file storage/API design has be significantly changed.
We need to restore this as soon as possible. Let's plan for it.
> I would suggest that we would have an API where anyone can develop a
> Campcaster widget for their page. It shouldnt require any integration with
> Campsite other than including the widget in the front end templates.
>
> Also, the old Campsite/Campcaster integration wont work for 1.6 as the
> database/file storage/API design has be significantly changed.
>
> Paul Baranowski
> Chief Technology Officer, Sourcefabric
>
> paul.baranowski@sourcefabric.org
> +1 (416) 832-6436 (Cell)
> Toronto, ON, Canada
>
> http://sourcefabric.org
> Skype: paulbaranowski
>
>
> On Mon, Nov 8, 2010 at 5:52 AM, Daniel James <
>
> campsite-dev@lists.sourcefabric.org> wrote:
>
> >
> > Hi Sava,
> >
> >
> > > What do you mean by automatic posts?
> >
> > I've previously discussed the idea of having a Campsite module which
> > displays metadata from the Campcaster schedule. This enables the
> > broadcaster to have an automated public website which shows what's
> > playing today at what time, what was played last Tuesday etc. It also
> > encourages Campcaster users to adopt Campsite, because of the wonderful
> > integration features :-)
> >
> > If the metadata is rich enough, you can have a text description for each
> > programme, a still image, and (for programmes in the past) a
> > stream-on-demand or download-on-demand link. The BBC has something like
> > this with iPlayer:
> >
> > http://www.bbc.co.uk/iplayer/radio
> >
> > This would fit neatly with the 'show' time slot concept that Paul and
> > Naomi are considering for a future release. A 'show' would be a
> > high-level item that occupies a certain time slot in the schedule, and
> > belongs to a certain user (i.e. other users cannot alter your show,
> > unless they have admin rights). The show can be a blank placeholder for
> > programme planning, and later it can contain files and/or playlists as
> > the time slot approaches.
> >
> > For a live but pre-recorded show, a recording can be dropped into the
> > show time slot for scheduling. For a live non-pre-recorded show, a
> > recording can be dropped into the slot afterwards, for archive/repeat
> > purposes.
> >
> > So the metadata displayed by the Campsite module would be grabbed from
> > the Campcaster show metadata for each time slot. This is convenient for
> > displaying schedules, because it's impractical and excessively verbose
> > to display every single playlist and file that the station is going to
> > playout today in a public web page.
> >
> > For a live non-pre-recorded show this is impossible to display in
> > advance anyway - we only know that a certain presenter is on the air at
> > a certain time, looks like *x* photo and plays *y* kind of music for *z*
> > type of person.
> >
> > Cheers!
> >
> > Daniel
> >
> >
>
>
>
> The XML-RPC API should be quite safe from database structure changes.
> Did
> you change it too?
>
> Mugur Rus
> Senior Software Developer, Sourcefabric
> mugur.rus@sourcefabric.org
>
> Cluj-Napoca, Romania
> +40 (0)720 528408
> Skype: mugur_rus
>
> http://www.sourcefabric.org
> http://www.twitter.com/Sourcefabric
>
>
>
> On Mon, Nov 8, 2010 at 4:47 PM, Paul Baranowski <
> campsite-dev@lists.sourcefabric.org> wrote:
>
> > I would suggest that we would have an API where anyone can develop a
> > Campcaster widget for their page. It shouldnt require any integration
> with
> > Campsite other than including the widget in the front end templates.
> >
> > Also, the old Campsite/Campcaster integration wont work for 1.6 as the
> > database/file storage/API design has be significantly changed.
> >
> > Paul Baranowski
> > Chief Technology Officer, Sourcefabric
> >
> > paul.baranowski@sourcefabric.org
> > +1 (416) 832-6436 (Cell)
> > Toronto, ON, Canada
> >
> > http://sourcefabric.org
> > Skype: paulbaranowski
> >
> >
> > On Mon, Nov 8, 2010 at 5:52 AM, Daniel James <
> >
> > campsite-dev@lists.sourcefabric.org> wrote:
> >
> > >
> > > Hi Sava,
> > >
> > >
> > > > What do you mean by automatic posts?
> > >
> > > I've previously discussed the idea of having a Campsite module which
> > > displays metadata from the Campcaster schedule. This enables the
> > > broadcaster to have an automated public website which shows what's
> > > playing today at what time, what was played last Tuesday etc. It also
> > > encourages Campcaster users to adopt Campsite, because of the wonderful
> > > integration features :-)
> > >
> > > If the metadata is rich enough, you can have a text description for
> each
> > > programme, a still image, and (for programmes in the past) a
> > > stream-on-demand or download-on-demand link. The BBC has something like
> > > this with iPlayer:
> > >
> > > http://www.bbc.co.uk/iplayer/radio
> > >
> > > This would fit neatly with the 'show' time slot concept that Paul and
> > > Naomi are considering for a future release. A 'show' would be a
> > > high-level item that occupies a certain time slot in the schedule, and
> > > belongs to a certain user (i.e. other users cannot alter your show,
> > > unless they have admin rights). The show can be a blank placeholder for
> > > programme planning, and later it can contain files and/or playlists as
> > > the time slot approaches.
> > >
> > > For a live but pre-recorded show, a recording can be dropped into the
> > > show time slot for scheduling. For a live non-pre-recorded show, a
> > > recording can be dropped into the slot afterwards, for archive/repeat
> > > purposes.
> > >
> > > So the metadata displayed by the Campsite module would be grabbed from
> > > the Campcaster show metadata for each time slot. This is convenient for
> > > displaying schedules, because it's impractical and excessively verbose
> > > to display every single playlist and file that the station is going to
> > > playout today in a public web page.
> > >
> > > For a live non-pre-recorded show this is impossible to display in
> > > advance anyway - we only know that a certain presenter is on the air at
> > > a certain time, looks like *x* photo and plays *y* kind of music for
> *z*
> > > type of person.
> > >
> > > Cheers!
> > >
> > > Daniel
> > >
> > >
> >
> >
> >
>
>
>
> I would suggest that we would have an API where anyone can develop a
> Campcaster widget for their page.
Is it feasible to use the existing XML-RPC API for this? Are there any
major CMS's that don't support XML-RPC in some form? It may be just an
issue of publicising this feature more.
I suppose that if you implement the 'show' item with metadata then the
API would need to be extended a little to accommodate that. For instance:
* List all show titles and times for tomorrow
or...
* Return the title, presenter, description, thumbnail image filename,
and direct download (and/or stream) link filename for the show yesterday
at 6pm UTC.
>
> Hi Sava,
>
>
> > Which means we need to make those in-studio news/script reading
> > templates...
>
> If a text script is linked to an audio clip, that means the audio
> content is indexable and searchable - potentially a killer feature.
>
> Cheers!
>
> Daniel
>
>
> "If a text script is linked to an audio clip"
> What do you mean by this? There is no such feature in Campsite.
I mean that a Campsite article containing the script of a radio
programme can be linked to a Campcaster audio clip of that programme,
therefore making the content of the radio programme searchable in a way
that it would not be as pure audio content.
Posts: 113Member, Administrator, Sourcefabric Team
It would actually mean mapping a Campsite article field or fields to metadata stored in Campcaster, if the search is going to happen within Campcaster.
Things would get really interesting if we could get this search from Campsite as well (as far as I remember, and Radio Package was eons ago) we were already able to search the Campcaster storage from within the Campsite admin interface (presumably using Campcaster's search engine). Holman should know more about it.
What you currently can do is to attach Campcaster's audioclips to a Campsite article. It works exactly the same as attaching an image. Everything happens in the article edit screen:
- You can add one ore more new audioclips (one at a time), which is not stored in Campsite but in Campcaster's storage.
- You can add one or more existing audioclips by searching the Campcaster's archive.
- Everytime you modify audioclip metadata in Campsite, metadata is updated in Campcaster database.
- I don't remember correctly now, but I think we also store audiclip metadata in Campsite database, so that we can perform some operations faster than via XML-RPC and, also important, to display metadata for audioclips attached to articles even though the Campcaster is not reachable at a given time.
- Metadata is synced but I don't remember how I implemented this.
So, in theory it is already possible to have what you described: Articles containing program scripts and audioclips from Campcaster linked to it.
Searching is available now as Sava said, only for searching Campcaster's storage via XML-RPC. Searching of scripts would be done automatically if the article field is checked as a content field.
> - Everytime you modify audioclip metadata in Campsite, metadata is
> updated in Campcaster database.
Thanks for explaining, I didn't realise it worked in both directions.
> - I don't remember correctly now, but I think we also store audiclip
> metadata in Campsite database, so that we can perform some operations
> faster than via XML-RPC and, also important, to display metadata for
> audioclips attached to articles even though the Campcaster is not
> reachable at a given time.
That's a good redundancy feature - I guess the audioclips could also be
cached locally to the Campsite server, in theory.
"- I don't remember correctly now, but I think we also store audiclip
metadata in Campsite database, so that we can perform some operations faster
than via XML-RPC and, also important, to display metadata for audioclips
attached to articles even though the Campcaster is not reachable at a given
time."
Metadata is stored locally and synced on Campcaster when one changes it in
Campsite. But the reverse is not true. The local metadata is also used for
filtering the audio clips listed on the frontend.
"- Metadata is synced but I don't remember how I implemented this."
There is a wrapper class that uses classes specific for local and remote
storage. Again this sync happens one way only: Campsite->Campcaster. So if
somebody updates the metadata in Campcaster and another person updates the
metadata later in Campsite the changes done in Campcaster are lost.
> Hi Daniel,
>
> What you currently can do is to attach Campcaster's audioclips to a
> Campsite article. It works exactly the same as attaching an image.
> Everything happens in the article edit screen:
>
> - You can add one ore more new audioclips (one at a time), which is not
> stored in Campsite but in Campcaster's storage.
>
> - You can add one or more existing audioclips by searching the Campcaster's
> archive.
>
> - Everytime you modify audioclip metadata in Campsite, metadata is updated
> in Campcaster database.
>
> - I don't remember correctly now, but I think we also store audiclip
> metadata in Campsite database, so that we can perform some operations faster
> than via XML-RPC and, also important, to display metadata for audioclips
> attached to articles even though the Campcaster is not reachable at a given
> time.
>
> - Metadata is synced but I don't remember how I implemented this.
>
> So, in theory it is already possible to have what you described: Articles
> containing program scripts and audioclips from Campcaster linked to it.
>
> Searching is available now as Sava said, only for searching Campcaster's
> storage via XML-RPC. Searching of scripts would be done automatically if the
> article field is checked as a content field.
>
>