--===============1839399950== Content-Type: multipart/signed; boundary="nextPart1192026.fO8zRAzvlC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1192026.fO8zRAzvlC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Jakub Stachowski wrote: >Hello, > >For the last month I have been working on DNS based service discovery >(ZeroConf, Rendezvous) for KDE. You can get it from kdenonbeta/kdnssd. Problems with the code, as it stands now: =2D it's licensed GPL, so it can't be included in kdelibs. It has to be LGP= L=20 to be in kdelibs -- except for the ioslave and kcm. =2D classes have no d-pointers or virtual hooks =2D classes have inlined methods and member variables -- might not be a goo= d=20 idea =2D use of C-style casts. Please replace with static_cast<> or=20 reinterpret_cast<> where appropriate. Also, please check that your conversion to QStrings in=20 responder.cpp:resolve_reply are using the correct encoding (it should=20 probably be UTF-8). In the same code, are you sure the 255- and 256-byte=20 buffers will never overflow? Please don't define AllServices (servicebrowser.h) as a static const QStrin= g=20 variable. Add it to a class and move the definition to the .cpp file, or=20 make it global and move to the .cpp (don't forget the 'extern'). In ServiceBrowser::startBrowse(), can you cache the result of=20 m_domains->domains() and its end iterator? Same thing for=20 UDNSQuery::havePtr(). Actually, for UDNSQuery, I'd rather you did not use QDns at all. Please use= =20 KResolver for PTR-resolution, if that's what you need. At the very least,=20 in havePtr(), cache the QStringList and use iterators, instead of=20 QStringList::at(), which can be O(n). ServiceList is descended from QPtrList. Please make it a QValueList, since= =20 the QPtr* are going away in Qt4 anyways. This is a personal taste, but don't you use indentation or break long lines= ?=20 Your code is somewhat hard to read... Aside from that, libhowl seem to be yet another great example of code that= =20 should have been written in C++. >- good and simple API for service publishing and discovery Seems to be achieving that. However, is it really necessary to make the=20 resolutions go "_http._tcp"? I'd suggest using two parameters and automatically prepending the=20 underscore. >- compatibility with other implementations - MacOSX, GNOME 2.8, Firefox > plugin (under development). This is why I choose write module for mDNS > support instead of SLP (and trying to revive knot) - because it seems to > be quite widespread not only in operating systems and desktop > environments but also in hardware like network printers and some wireless > routers. By using SRV-based resolution? I'd agree. >- support for unicast DNS - for discovering services in larger networks > and over internet I also want to provide SRV-based resolution for normal stuff, including web= =20 browsing. >- ioslave - for easy use from file selector, konqueror and sidebar. For > now it can find ftp and http servers. Probably integration with network:/ (lisa) is desireable. >- my goal is to have kdnssd included in KDE - what do you think about it? >"useful enough to be bugfixed and included" , " try again in several > months" or "it sucks, just drop it" ? And if answer is "include", do you > think it can be done in KDE 3.4? Aside from what I pointed out above, I think we could give it a try.=20 However, as things go, you'll first need an application using it for it to= =20 move away from kdenonbeta. Then you'll need a second for it to go into=20 kdelibs. Also, can it work at all without libhowl? How difficult would it be to=20 reimplement it, if necessary? >- I consider good API as priority ( and would hate to lower high KDE >standards) - what should be improved? Mentioned above. >- there are already bits of SLP support (in krdc and kinetd) - should it > be left as is, replaced with ZeroConf or both should be supported (for > browsing, I suppose one standard has to be chosen for service publishing) I can't answer that. >There are still 3 significant improvements to be done (+ testing/bugfixing > of course): > >- IPv6 support - with unicast DNS it should be no problem, but I have yet > no idea how to do it in libhowl (form multicast DNS) I have not seen how libhowl works, but IPv6 multicasting is fairly simple -= =2D=20 much simpler than multicasting over IPv4. >- possibility to choose one network interface for service publishing - but >KNetworkInterface is still placeholder and awaits choosing real >implementation And I don't plan on doing that for KDE 3.4.=20 It seems we can rely on getifaddrs() and our replacements in order to detec= t=20 network interfaces. And it also seems to be relatively simple to implement= =20 it. However, the part relating to KMulticastSockets isn't that simple -- given= =20 the complexity of supporting IPv4 and IPv6 multicasting at the same time. In any event, I did not plan to introduce new functionality in that part of= =20 the code for KDE 3.4, keeping it in perfect sync with the 3.3.x updates.=20 That is especially because I don't have enough time to work on this till at= =20 least the end of the year. >Requirements: >- libhowl 0.9.6 . Unfortunately it crashes, patch was sent to author (also >available in kdnssd/patches). He responded that new version of libhowl is >going to be released in a week. >- Qt 3.3 - there is bug in QDns TXT record handling - it was reported and >will be fixed in next version. Patch is also available. Good news is that >this bug in not too serious and it probably can be worked around. That's two requirements I would rather not have (an extra lib required in=20 kdelibs and QDns). =2D-=20 Thiago Macieira - Registered Linux user #65028 thiago (AT) macieira (DOT) info ICQ UIN: 1967141 PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 --nextPart1192026.fO8zRAzvlC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBf/0wM/XwBW70U1gRAq8DAJ9oThKRF6vsAoHAhn9neOO3sztWWgCfSXEm XcGZVvBHPKuTPgW5nVjr+9w= =vsjs -----END PGP SIGNATURE----- --nextPart1192026.fO8zRAzvlC-- --===============1839399950== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << --===============1839399950==--