[SailfishDevel] SyncML topic revived (further down the rabbit hole)

Tone Kastlunger users.giulietta at gmail.com
Mon Aug 5 16:35:33 UTC 2019


>These might be useful for another applications that may be using dbus, but
>not for the syncml code that relies solely on filedescriptors outside dbus.

Strictly speaking, I don't see any problem with this - from a syncml client
/ server
perspective; was the socket owned by the bluetooth manager also for bluez4
as well?
If so,  in this regard, there should be no change in responsibility for the
syncmlclient/server.

About the KF5BluezQt, I totally agree - hoarding abstractions won't make
problems disappear;
I believe the extent of changes should be the driving force for the final
choice (i.e. the least complex
solution which requires the least changes). Less is more ;)

Just my 2 cents.


On Sun, Aug 4, 2019 at 11:31 PM deloptes <deloptes at gmail.com> wrote:

> Chris Adams wrote:
>
> > Hi,
> >
> > (Sorry for top posting, OWA doesn't quote properly...)
> >
> > That old PR is actually mine, if you're referring to
> > https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1
> >
> > I think it had some issues (e.g. didn't do UUID matching properly between
> > client and server, so it was more of an "import" rather than a true
> "sync"
> > IIRC), which is why it wasn't merged.  Subsequent syncs might cause
> > duplication, or changes might not be propagated properly, in one
> direction
> > or the other.  I don't recall precisely.
> >
> > Going forward: my personal opinion is that if you can make the required
> > changes to the stack to get everything working, we'd definitely like to
> > integrate those changes, as it would ensure that we have more parts of
> our
> > stack up-to-date, and less dead-code.
> >
> > That said, at this stage I don't believe that it's high priority
> > internally, so not sure how much time/effort sailors will be able to
> spend
> > helping with this effort, unfortunately.  Definitely can review and test,
> > but may not be able to help with active development day to day.  But am
> > always happy to discuss etc (ping chriadam on freenode IRC in .au
> > timezone, or perhaps flypig or pvuorela in .fi timezone).
> >
> > Best regards,
> > Chris.
> >
>
>
> Hi, so I finished updating and testing, but I feel miserable, because
> KF5BluezQt was looking very promissing in the beginning and at the end it
> turned out to be of no big advantage to pure Qt5 DBus.
> I am not sure if I should not remove KF5BluezQt and write everything only
> with Qt5 - despite @blam advocating how good KF5BluezQt is.
>
> The biggest advantage perhaps is that it initializes when the adapter setup
> is completed, but - there seems to be always a but and here come the
> disadvantages.
> The first disadvantage is that in the background bluetooth is going through
> all known devices and registering services that are known to have been
> supported to each device.
> So at the time I can access the adapter I still do not know if I have to
> register the service or not. So if I restart msyncd while BT is on it
> crashes like "BUG: scheduling while atomic: kworker/0:1/12981/0x00000002".
> There is no issue, when msyncd is restarted if BT is off, because the
> application is down - nothing on DBus.
>
> The second big disadvantage of KF5BluezQt is the profile handling. It does
> support many profiles, but not the syncml server and client and creating
> own profile turned to be very hard, because the profile should handle a
> socket/file descriptor, which turns out problematic because of using
> QDBusUnixFileDescriptor and QSharedPointer<QLocalSocket> in combination.
> These might be useful for another applications that may be using dbus, but
> not for the syncml code that relies solely on filedescriptors outside dbus.
>
> For the moment the solution works fine, but in the area of the above I see
> it as a work around over KF5BluezQt limitations.
> It might be also me misinterpreting documentation or limited skills.
>
> The fact is I don't know what to do now. The time window I had for working
> on this closes. The results are not bad - I can sync two most important -
> contacts and calendar+todo like I was doing on the N9, but I wish I would
> have the time to try Qt Bluetooth or go it directly via DBus.
>
> The question is to push or not to push :)
>
> Sorry for the long message, but I am not sure what to do next. I'll update
> the PoC with what I have on the PC now.
>
> Ideas?
>
> regards
>
> _______________________________________________
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to
> devel-unsubscribe at lists.sailfishos.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20190805/434c5c63/attachment.html>


More information about the Devel mailing list