[
http://dev.sourcefabric.org/browse/LS-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15489#action_15489
]
David Baelde commented on LS-495:
---------------------------------
You're right, Romain. The current state is just too broken, it's a good idea to
start from scratch with a better behavior, clean and uniform. It won't affect
most people, and the beta2 will be an opportunity to check that we don't miss
anything. And let's forget about a general mechanism until we find a use for it.
I agree that the namespace should be unregistered, it's too ugly otherwise.
Concerning the relationship between ID and NS, your solution seems good: it
will be surprising for users that the ID they choose may be changed, but it'll
mostly happen in situations where they made a mistake -- mostly but not always,
since it's possible that an operator takes an ID based on a filename, so that a
subsequent ID specified in the script needs to be bumped to ID.1.
So, I fully agree with your approach! Hence I'll start discussing in more
details...
I don't like the code "if ns <> [] then register ..." which you took from
(very) old code. It makes it look as if the same source object may be lead to
register a namespace twice. If this was the case, then I'd like to get the same
namespace, hence my earlier question about unregistering the namespace. But in
fact, it should never be the case that #wake_up and #sleep are called twice. I
had another idea many years ago, but today it seems that it is the case, and
should be enforced. So, the condition should at least be changed into an
assertion (assert (ns = []) ; ns <- Server.register ...) and if we feel bold we
may even remove the (ns <- []) after the unregistering, to enforce that
#wake_up in never called again after #sleep.
The ns_kind is a bit ugly. It's really meant to be constant so it'd better be
set once for all when inheriting from source. The only problem then is to find
a way to deal with start_stop. One possibility is to allow ourselves to
register commands in start_stop and set the namespace hint in another. Perhaps
we should also review the many names and kinds we have:
* the base source class has a "name" parameter, it corresponds roughly to the
name of the derived class (add, switch, input.http, etc)
* the id is more specific than that, allowing to distinguish between several
instances of add, switch, etc.
* the kind is coarser than the name, it describes an interface: all soundcard
I/O have the same interface (but they don't have the same as input.http)
It gets messy around output_kind in Output.output: it is passed as a name to
active_operator but as a kind to start_stop... Now that namespace management is
moved to the base class, it looks like the three notions, which we could call
identifier, class and interface, belong to the base source class. If you agree,
we could integrate this change in the same branch. Note that we don't need to
change so many classes: it's fine to have "unknown" as default class and
interface names. For backward compatibility, I guess "name" remains the
parameter for class name. But output_kind should be the same as class name.
Finally, the interface name (currently, ns_kind) should (when possible) be more
general than the class name, otherwise there's no point in distinguishing the
two notions.
> Deregister telnet commands on source's sleep
> --------------------------------------------
>
> Key: LS-495
> URL: http://dev.sourcefabric.org/browse/LS-495
> Project: Liquidsoap
> Issue Type: Bug
> Affects Versions: 1.0
> Reporter: Romain Beauxis
> Priority: Important
>
> Server/telnet command needs to be unregistered each time a source is shutdown
> in order to allow it to be garbage collected (and also to not polute..)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://dev.sourcefabric.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Savonet-devl mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-devl
