KDNSSD merge

[Kevin Ottens]

Hello,

On Sunday 02 March 2014 11:39:15 David Faure wrote:
> On Saturday 01 March 2014 10:27:08 Alex Merry wrote:
> > On 01/03/14 09:55, David Faure wrote:
> > > On Tuesday 25 February 2014 20:37:28 Alex Merry wrote:
> > >> I've had a look at the kdnssd repositoy, and it contains two related
> > >> bits of code: the zeroconf ioslave and a kded/KDirWatch module to
> > >> notify
> > >> KIO about changes to available services.
> > >> 
> > >> These two obviously belong together; the question is where?  They can
> > >> go
> > >> in kdnssd-framework, making it depend on KIO, or they can go in KIO,
> > >> making it (optionally) depend on KDNSSD.
> > > 
> > > I don't like the idea of adding yet another dependency to KIO.
> > > 
> > > How about we put the kioslave which depends on kio+kdnssd into some
> > > tier4
> > > framework? After all it's not API, it's just some integration plugin,
> > > which is exactly what defines tier4.
> > 
> > Do we want a kioslaves framework (somewhat similar to the kimageplugins
> > framework)?
> 
> I think that would make sense -- we have a whole bunch of kioslaves in
> kde-runtime that we don't know where to put (lots of "??" in the
> New_Runtime_Organization epic).
> 
> I don't think we want all of these into the kio framework, that would make
> it depend on libsmbclient, libssh and all sorts of other libs.
> 
> Kevin, do you agree on a kioslaves.git repo, tier4?

Tier3, but otherwise yes, I definitely agree with the move. We should make 
sure that during the build all the dependencies are treated optional, so that 
people getting it just for one ioslave don't have to pull plenty of 
dependencies.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140302/c81bfb2c/attachment.sig>