From owner-freebsd-ports-bugs@FreeBSD.ORG Tue Jul 15 12:26:24 2014 Return-Path: Delivered-To: freebsd-ports-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F18D2B99 for ; Tue, 15 Jul 2014 12:26:24 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D90EF20F0 for ; Tue, 15 Jul 2014 12:26:24 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6FCQOkV023845 for ; Tue, 15 Jul 2014 12:26:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 191873] Network ports in category "multimedia" Date: Tue, 15 Jul 2014 12:26:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports Tree X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dreamcat4@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 12:26:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191873 --- Comment #5 from dreamcat4@gmail.com --- (In reply to Stefan Esser from comment #4) > (In reply to Kubilay Kocak from comment #3) > > I'm +1 on the primary motivator behind category selection being "Where would > > our users reasonably expect to find it?" > > > > Considering multimedia as the 'service' provided to the user as distinct > > from a softwares primary 'functional' class makes this easier to identify > > The problem is, that all DLNA servers have been in "net" for many years. Is there any chance we can ask those guys again now what they may prefer their primary category? (fuppes, minidlna, etc). If they change it, they can still be in 'net' as their secondary category. > AFAIK, the PlexMediaServer is not using UPnP/DLNA, but a protocol specific > to their devices. AFAICT you are correct that PlexMediaServer does provide media streaming over a proprietary protocol. However it ALSO provides streaming over the DLNA/uPNP protocol too. So it's both. > UPnP is not only used for media streaming, but as a universal network access > mechanism. > Those UPnP/DLNA servers, that are primarily meant to stream media > contents, should probably add multimedia as a secondary category, to make "DLNA Client" OR "DLNA Server" = 'an application' --> firmly 'application' in OSI reference terms. DLNA = almost entirely multimedia services (using / on top of uPNP). --> firmly 'application protocol layer' in OSI reference terms. uPNP = purely networking (IP multicast) --> firmly 'Network layer' in OSI reference model So that is why I believe anything 'DLNA' (be it client or server) should be multimedia as primary category, and (if applicable) with 'net' as secondary. > DLNA renderer ports do belong into the multimedia category, most do support > other access methods (including local files). UPnP/DLNA controller without > rendering functionality are media devices from a user's point of view. Ah. Earlier you said something about my new port 'universal-media-server'. It was: > multimedia/universal-media-server > > While these ports deliver or control media streams, they do not implement rendering functions, themselves. However what you may not be aware of is that starting from version 4 onwards, UMS4 now includes an HTML5 web-based media renderer too. (for mobile devices and PS4, etc). So (if imposing that rule), universal-media-server does provide rendering function too. And is entirely justified to have 'multimedia' as it's primary category. However I just don't believe that's a valid criteria in the first place! > But in fact, any other systematic assignment to categories might be OK, as > long as it follow some concept. I'd expect to find the others in the same > category if I installed one and find that it does not fit my requirements. Agreed. But I would request that you please at least just ask the fuppes, media tomb, and minidlna maintainers, if they would prefer their primary category to be either 'multimedia' or 'net'. Because it looks like they are going to be in both categories now. I also don't mind if you want to include 'universal-media-server' to 'net' as it's secondary category. But I would still very much like 'multimedia' to be it's primary category. They keep adding new features to it, so your criteria (that you are using) won't remain valid. Better to keep it in the same place than have to move it back again later on. By the same reasoning, you could also consider making 'net' a secondary category for plex media server. Since it is plex also functions as a DLNA/uPNP media server too. Ahem. Any chance you can see why i don't really believe these things should be in 'net' at all anymore? It would at least make your life a lot simpler, if anything else trying to establish what is their specific functionality, etc. -- You are receiving this mail because: You are the assignee for the bug.