1 Aug
2012
1 Aug
'12
1:32 p.m.
On 08/01/2012 12:41 PM, James Morris wrote:
On 01/08/12
"rosea.grammostola"<rosea.grammostola(a)gmail.com> wrote:
I don't see what you mean. You've a list of apps with NSM support. You
can use those in the NSM session. Other apps you can launch via
nsm-proxy. If you want to use Ladish l1, look at the list of apps with
ladish l1 support.
I would but linuxaudio.org seems to have gone down :-(
LASH is dead, period. The only reason not to remove LASH is that Ladish
supports it. But because Ladish will support NSM in future, it might be
no problem to completely remove LASH if you add NSM.
JackSession is also more or less dead, because of some flaws in
practical usage and because of the fact that it is more or less no
longer maintained any longer. Which is good imo, it's better to have one
session api then a lot. Ladish supports JS, but other then that there is
little reason for not replacing JS with NSM.
It might be good for Linuxaudio if the JackSession devs declare
JackSession to be dead.
Regards,
\r
On 08/01/2012 11:53 AM, James Morris wrote:
..
> LASH failed despite 26 apps supporting it:
> http://wiki.linuxaudio.org/apps/all/lash
The problem with LASH is that it has obvious (technical) flaws.
Session managers today are much better. Imo NSM has a great
technical design, with advantages compared to other session api's
and without (essential) technical flaws.
If you think that all the apps apps.linuxaudio.org will support a
session api, then you're not very realistic. That's why it's
essential that NSM support apps without NSM support and apps
without a state in a user friendly way.
I guess. But for those who need to play around with stuff before they
find what they can use to start being productive it's not good. That many
apps already have a form of session management is one of
the problems for NSM. What should a developer do when attempting to
support NSM in an application which already has Jack Session support
and LASH support? It increases the complexity of what the user
interface has to deal with.
First, it makes it far more easy to implement NSM. The time consuming
'search work' for adding session support is already done.
Second, I assume that it is possible to support more session api's in
one application.
The point I was making is supporting multiple session handlers makes
the application more complex than it necessarily needs to be and
increases the amount of code that needs to be maintained.
If LASH has so many faults and nobody is maintaining LASH itself, by
dropping support for LASH in clients we kill two birds with one
stone: 1) there's less maintenence work for devs to do - always good
and 2) it directs users to better solutions such as NSM.
But I don't actually know what user base exists for LASH. I want to
drop support for it but will revolting users castrate me for it?