Douglas.Arellanes@mdlf.org wrote:
> I've put up new use cases for items likely to make the 1.1 release on
> the Developers' Wiki at
> http://code.campware.org/projects/livesupport/wiki/UseCases.

excellent?

some formal remarks: can't we follow the table-like format put in by
Ferenc at http://code.campware.org/projects/livesupport/wiki/UC-1

in general, the use cases are lacking a precondition and a postcondition
section: what is expected from the system prior to executing the use
case, what is expected afterwards

no login / access control details are written in the use cases (I'd
assume that the user at least has to log in first before doing anything...)

some specific remarks:

> Network mirroring/backup

please elaborate on the parameters (what does 'data range' or 'files
with creator' mean, for example?)

the naming of the use case 'network backup' is quite unintuitive, as
it's actually doing non-networked transfer

is the import procedure for such a backup described on a separate use
case? can you provide a reference to that use case?

> Schedule export

is there timeframe option for the export?

please provide a reference to the corresponding use case (Schedule import)

> Schedule import

I'm pretty much missing the post-condition of all previously scheduled
items will be erased (one can guess by the warning message described,
but still..)

but: is the scheduler really wiped out? including the past schedules?

please provide a reference to the corresponding use case (Schedule export)

> Playlist export

the use case mentions unique file names: there are unique ids, but there
is no unique file name in the storage

the numbering scheme for the flow of the use case is missing here quite
a lot (there are two possibilities after the first user response)

please provide a reference to the corresponding Playlist import use case

> Playlist import

matching import files is ambigous: all files have a globally unique ID,
so overwriting is a shaky issue to begin with, and search / browse is
pretty much out of the question...

> Admin palette
> - Sound card config

this looks OK, except for one question: is the configuration written to
the system-wide config file (/etc/scheduler.xml or
/etc/gLiveSupport.xml), or to the user-specific config file
(~/.livesupport/scheduler.xml and ~/.livesupport/gLiveSupport.xml)? in
the first case, the user needs root priviliges, for example... as for
the GUI, it might actually be a user preference...

> - Scheduler start/stop

how about forced stop (kill)?

> - Mass import
> - Database backup/restore

on restore: what do you mean exactly by 'compare the current database
with the one in this file'?

> - File parameter restrictions

Creative Commons License (vs. CC copyright)


> Of these, many are GUIfications of functions that are available already
> in the command line. This is based on clear feedback we received by
> users; the command line tools should continue to exist as well.
>
> Anyway, they're up, so now it's a matter of getting them finalized so
> that the developers can get to work.

thanks! great work!


Akos

j.p.drawneek@durham.ac.uk wrote:
> K requirement from student radio.
>
> We need the gLivesupport to be able to playout on at least two stereo
> channels.
>
> We been using DJplay software but it does not provide the suite that
> livesupport does. The only feature holding it back for student
> radio, at least in the uk, is the ability to allow mixing of two
> tracks by the dj.

nice idea. could you open a ticket with the above description here:
http://code.campware.org/projects/livesupport/ , marked with severity
'feature', and for milestone 1.1 ?
>
> I may put in some hours on this dev work since i suggested, we bit i
> am a bit busy with setting up the station. So it could be after xmas.

wow that would be great!


> Also could the ls-station be made easier to install - i mean really
> easy like all the other php apps. I think that by producing it total
> in something like php would make it so much easier to install on
> existing systems. Again this is something i will attempt after xmas
> because we got a solaris web infrastructure, and it should not be as
> hard as it is to get it installed. Also i have seen this sort of
> request on the forums before, why should you have to install the
> whole suite on a web faceing server when your not using debian,
> because there is nothing in the documentation which tells you how
> just to install ls-station. But it does tell you that ls-station and
> ls-studio are seperate.

yes, good point, we were already planning to separate the components
into independenlty installble parts...


Akos