[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: obex project for kde
From:       Simone Gotti <simone.gotti () email ! it>
Date:       2005-06-11 12:43:48
Message-ID: 200506111443.48433.simone.gotti () email ! it
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 10 June 2005 19:10, Fred Schaettgen wrote:
> On Friday, 10. June 2005 17:00, Simone Gotti wrote:
> > In kdebluetooth we made various obex programs. Some programs uses
> > libkobex (a wrapper around libopenobex) others like the kio_obex (imho
> > the unique working graphical obex ftp for linux that I know) uses liqobex
> > (a great, at least for me :D, library made by Mathias Fröhlich, as
> > kio_obex).
> >
> > By now some programs works with both cable, irda and bluetooth and I
> > already adapted others (the obex client and the obex server) to work with
> > all the type of transports supported, dropping the deps on openobex and
> > only using libqobex.
> >
> > As all the obex stuffs aren't only bluetooth related I talked with the
> > other kdebluetooth developers and my idea was to take them out and create
> > a new projects (an idea is something like "obeks" :D ).
> > As I have a lot of new stuffs on my pc I'm asking if I can open this new
> > project (maybe in kdenonbeta) so others can test and enjoy it.
>
> Would it be sufficient to have a libqobex and libkbluetooth in
> extragear/libs, leave the obex tools in extragear/pim and move the rest of
> kdebluetooth to extragear/network? 
This will be a good idea. Are you saying that libkbluetooth and libqobex will 
be released separately and so the other projects will dinamically link to 
them. Or should the various programs have a local copy of it (like is did 
with the kde-common/admin dir)?

> Or isn't this a option because you want 
> to use it in KDE/kdepim for instance?
I don't see any problem.
The unique program for kdepim it's the irmcsync konnector, but reading the 
latest kdepim mails looks like there's an option for the f.d.o. OpenSync 
project. If this will become the standard syncing framework, probably 
kitchensync and my konnector will be dropped. So I don't care so much.


> It would be good if we can do without forking libkbluetooth. The obex tools
> also shouldn't have to move from to playground just because they support
> new transports. Or what exactly do you want to move to playground?
My idea was tout them in kdenonbeta until they're as stable as the current 
ones.
> Regarding the naming of the obex tools - why don't we simply occupy the
> generic names and call it "OBEX Client" and "OBEX Server" or similar? We
> don't have much competition in or outside of KDE anyway ;)
Yes. I was thinking to the same generic name.
> Fred

Bye!
-- 
Simone Gotti
<simone.gotti@email.it>

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]