Re: [SailfishDevel] [Minutes] Sailfish OS Open Source Community Collaboration Meeting, 2nd June 2016

[Chris Adams]

sp/next Thursday/Thursday 23rd June.


From: devel-boun...@lists.sailfishos.org [devel-boun...@lists.sailfishos.org] 
on behalf of Chris Adams [chris.ad...@jolla.com]
Sent: Friday, June 03, 2016 10:57 AM
To: Sailfish OS Developers
Subject: Re: [SailfishDevel] [Minutes] Sailfish OS Open Source Community 
Collaboration Meeting, 2nd June 2016

Hi,

Just a quick note about the time of the next meeting - if it was decided to 
allow GMT+10 folks like me attend more easily: next Thursday night I'm going to 
a Karnivool concert at the Triffid so I won't be able to attend the SFOS OSCCM. 
 Sorry for the hassle!

Cheers,
Chris.


From: devel-boun...@lists.sailfishos.org [devel-boun...@lists.sailfishos.org] 
on behalf of James Noori [james.no...@jolla.com]
Sent: Friday, June 03, 2016 1:20 AM
To: devel@lists.sailfishos.org
Subject: [SailfishDevel] [Minutes] Sailfish OS Open Source Community 
Collaboration Meeting, 2nd June 2016

Ahoy everyone!

Thanks to all who attended today's meeting.
Meeting minutes can be found here in a variety of formats:

Minutes:   
http://merproject.org/meetings/mer-meeting/2016/mer-meeting.2016-06-02-13.30.html
Minutes (text):   
http://merproject.org/meetings/mer-meeting/2016/mer-meeting.2016-06-02-13.30.txt
Log: 
http://merproject.org/meetings/mer-meeting/2016/mer-meeting.2016-06-02-13.30.log.html

If you wish to propose a topic for the next meeting, please do so here:

https://together.jolla.com/question/54157/sailfishos-open-source-collaboration-meeting-planning/

The next meeting is scheduled for Thursday the 23rd of June 2016 at 9:00 UTC.
***Note that the time has changed***


Thanks and best regards,
James Noori (Jaymzz)
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] [Minutes] Sailfish OS Open Source Community Collaboration Meeting, 2nd June 2016

[Chris Adams]

Hi,

Just a quick note about the time of the next meeting - if it was decided to 
allow GMT+10 folks like me attend more easily: next Thursday night I'm going to 
a Karnivool concert at the Triffid so I won't be able to attend the SFOS OSCCM. 
 Sorry for the hassle!

Cheers,
Chris.


From: devel-boun...@lists.sailfishos.org [devel-boun...@lists.sailfishos.org] 
on behalf of James Noori [james.no...@jolla.com]
Sent: Friday, June 03, 2016 1:20 AM
To: devel@lists.sailfishos.org
Subject: [SailfishDevel] [Minutes] Sailfish OS Open Source Community 
Collaboration Meeting, 2nd June 2016

Ahoy everyone!

Thanks to all who attended today's meeting.
Meeting minutes can be found here in a variety of formats:

Minutes:   
http://merproject.org/meetings/mer-meeting/2016/mer-meeting.2016-06-02-13.30.html
Minutes (text):   
http://merproject.org/meetings/mer-meeting/2016/mer-meeting.2016-06-02-13.30.txt
Log: 
http://merproject.org/meetings/mer-meeting/2016/mer-meeting.2016-06-02-13.30.log.html

If you wish to propose a topic for the next meeting, please do so here:

https://together.jolla.com/question/54157/sailfishos-open-source-collaboration-meeting-planning/

The next meeting is scheduled for Thursday the 23rd of June 2016 at 9:00 UTC.
***Note that the time has changed***


Thanks and best regards,
James Noori (Jaymzz)
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] Open source in-app ad API helper for QML - please, join

[Matthias Fehring]

My experiences with donations:

Many talk about but only really few do really donate. But this few mostly 
donates more as I would charge for selling the app.

For example, I had ocNews as paid app in the Ovi Store for Meego and I think 
it was in a price range of 1,99€ for Germany (other countries differed). After 
Ovi store was closed, I changed it to donation only app (it was open source 
all the time). The few people that did a donation for it gave mostly much more 
than the 1,99€ - most were 4 -5 €. But in the sum only a few really donated. 
(maybe around 10 people, so the donations did not even cover the costs for the 
beer I consumed while writing the app... ;)

Best greetings
Buschmann

Am Donnerstag, 2. Juni 2016, 20:27:58 CEST schrieb george b:
> Some experiences from me as a former iOS Developer:
> 
> - With a good payed app, one can earn a some money
> - A free app with InApp Payment for more features leads to more revenue on
> my apps
> - iAd leads to almost no revenue. On iOS one need several thousends of App
> installations to get just a little revenue
> 
> Can someone post some experiences with donations?!
> 
> 2016-05-31 19:49 GMT+02:00 Zoltán Lutor :
> > thx, I was aware of the post - unfortunatell I cannot participate because
> > I'll be in work.
> > Anyone of you, please, feel free to bring this topics up there.
> > 
> > 2016-05-31 17:33 GMT+02:00 Coley :
> >> Check out this topic over on together:
> >> 
> >> https://together.jolla.com/question/54157/sailfishos-open-source-collabor
> >> ation-meeting-planning/>> 
> >> On 31 May 2016 at 16:18,  wrote:
> >>> Good comment.
> >>> 
> >>> 
> >>> Newbie in community development, no experience with IRC... ;-)
> >>> 
> >>> Coley írta ekkor: 2016.05.31. 16:56
> >>> Why not propose it as a topic for the IRC meeting and attend?
> >>> There are normally a few Jolla people on it - and if nobody can answer
> >>> your question maybe they can take an AI to find the answer for you.
> >>> 
> >>> -Coley.
> >>> 
> >>> On 31 May 2016 at 15:46,  wrote:
>  I've tried to contact them already - even for getting invokved with the
>  development.
>  
>  
>  No reaction so far...
>  
>  Camil Bancioiu írta ekkor: 2016.05.31. 11:55
>  Hello Zoltan,
>  
>  I hope you will find help with your SDK. Not because I like ads (I
>  don't), but because the platform is free, and everybody should
>  implement
>  what they think it's best. But first, you should talk to Jolla, because
>  they're the ones that will eventually allow apps with your ad-SDK in
>  Harbour. And, depending on their philosphy and principles regarding
>  this
>  matter (yet unkown), they may approve of your SDK, or not. If apps
>  using
>  the ad-SDK won't be admitted on Harbour, it will be hard to earn money
>  through it, I think. Also, don't forget Jolla already has plans for
>  some
>  "SuperApps" or whatever they're called, which is basically sponsored
>  content. There may be some politics involved here, regarding ads in
>  normal
>  apps.
>  
>  Bottom line: ask Jolla if they will allow apps using the ad-SDK on
>  Harbour, and how does it relate to their already-planned sponsored
>  content
>  in the OS.
>  
>  Best regards,
>  Camil
>  
>  On Tuesday 31 May 2016 10:10:42 devel-requ...@lists.sailfishos.org
>  
>  wrote:
>  > Re: Open source in-app ad API helper for QML - please, join
>  
>  ___
>  SailfishOS.org Devel mailing list
>  To unsubscribe, please send a mail to
>  devel-requ...@lists.sailfishos.org
>  
>  
>  
>  ___
>  SailfishOS.org Devel mailing list
>  To unsubscribe, please send a mail to
>  devel-unsubscr...@lists.sailfishos.org
> >>> 
> >>> ___
> >>> SailfishOS.org Devel mailing list
> >>> To unsubscribe, please send a mail to
> >>> devel-unsubscr...@lists.sailfishos.org
> >> 
> >> ___
> >> SailfishOS.org Devel mailing list
> >> To unsubscribe, please send a mail to
> >> devel-unsubscr...@lists.sailfishos.org
> > 
> > ___
> > SailfishOS.org Devel mailing list
> > To unsubscribe, please send a mail to
> > devel-unsubscr...@lists.sailfishos.org


-- 
Das Gesetz hat zum Schneckengang verdorben, was Adlerflug geworden wäre.
(Friedrich Schiller - Die Räuber)

Und der Buschfunk spielt gerade "Wir Ham Noch Lange Nicht Genug" von "Böhse 
Onkelz".

www.buschmann23.de
GPG-Key: 0x614C3258
GPG Fingerprint: B770 E0D0 69CF BFC1 5FE1 D78E 3A70 A936 614C 3258


signature.asc
Description: This is a digitally signed message part.
___
SailfishOS.org 

Re: [SailfishDevel] Open source in-app ad API helper for QML - please, join

[Dylan Van Assche]

I receive donations from 1/100 users...
I was also planning to change to inApp Payments...

Dylan


 Original Message 
Subject: Re: [SailfishDevel] Open source in-app ad API helper for QML - please, 
join
Local Time: June 2, 2016 8:27 PM
UTC Time: June 2, 2016 6:27 PM
From: scooterschors...@gmail.com
To: devel@lists.sailfishos.org






Some experiences from me as a former iOS Developer:
- With a good payed app, one can earn a some money
- A free app with InApp Payment for more features leads to more revenue on my 
apps
- iAd leads to almost no revenue. On iOS one need several thousends of App 
installations to get just a little revenue

Can someone post some experiences with donations?!



2016-05-31 19:49 GMT+02:00 Zoltán Lutor :


thx, I was aware of the post - unfortunatell I cannot participate because I'll 
be in work.
Anyone of you, please, feel free to bring this topics up there.





2016-05-31 17:33 GMT+02:00 Coley :


Check out this topic over on together:
https://together.jolla.com/question/54157/sailfishos-open-source-collaboration-meeting-planning/





On 31 May 2016 at 16:18,  wrote:



Good comment.





Newbie in community development, no experience with IRC... ;-)




Coley írta ekkor: 2016.05.31. 16:56







Why not propose it as a topic for the IRC meeting and attend?
There are normally a few Jolla people on it - and if nobody can answer your 
question maybe they can take an AI to find the answer for you.

-Coley.



On 31 May 2016 at 15:46,  wrote:



I've tried to contact them already - even for getting invokved with the 
development.





No reaction so far...




Camil Bancioiu írta ekkor: 2016.05.31. 11:55





Hello Zoltan,


I hope you will find help with your SDK. Not because I like ads (I don't), but 
because the platform is free, and everybody should implement what they think 
it's best. But first, you should talk to Jolla, because they're the ones that 
will eventually allow apps with your ad-SDK in Harbour. And, depending on their 
philosphy and principles regarding this matter (yet unkown), they may approve 
of your SDK, or not. If apps using the ad-SDK won't be admitted on Harbour, it 
will be hard to earn money through it, I think. Also, don't forget Jolla 
already has plans for some "SuperApps" or whatever they're called, which is 
basically sponsored content. There may be some politics involved here, 
regarding ads in normal apps.


Bottom line: ask Jolla if they will allow apps using the ad-SDK on Harbour, and 
how does it relate to their already-planned sponsored content in the OS.


Best regards,
Camil


On Tuesday 31 May 2016 10:10:42 devel-requ...@lists.sailfishos.org wrote:
> Re: Open source in-app ad API helper for QML - please, join

___

SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-requ...@lists.sailfishos.org



___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org



___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org


___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org


___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] Open source in-app ad API helper for QML - please, join

[george b]

Some experiences from me as a former iOS Developer:

- With a good payed app, one can earn a some money
- A free app with InApp Payment for more features leads to more revenue on
my apps
- iAd leads to almost no revenue. On iOS one need several thousends of App
installations to get just a little revenue

Can someone post some experiences with donations?!


2016-05-31 19:49 GMT+02:00 Zoltán Lutor :

> thx, I was aware of the post - unfortunatell I cannot participate because
> I'll be in work.
> Anyone of you, please, feel free to bring this topics up there.
>
> 2016-05-31 17:33 GMT+02:00 Coley :
>
>> Check out this topic over on together:
>>
>> https://together.jolla.com/question/54157/sailfishos-open-source-collaboration-meeting-planning/
>>
>>
>> On 31 May 2016 at 16:18,  wrote:
>>
>>> Good comment.
>>>
>>>
>>> Newbie in community development, no experience with IRC... ;-)
>>>
>>> Coley írta ekkor: 2016.05.31. 16:56
>>> Why not propose it as a topic for the IRC meeting and attend?
>>> There are normally a few Jolla people on it - and if nobody can answer
>>> your question maybe they can take an AI to find the answer for you.
>>>
>>> -Coley.
>>>
>>> On 31 May 2016 at 15:46,  wrote:
>>>
 I've tried to contact them already - even for getting invokved with the
 development.


 No reaction so far...

 Camil Bancioiu írta ekkor: 2016.05.31. 11:55
 Hello Zoltan,

 I hope you will find help with your SDK. Not because I like ads (I
 don't), but because the platform is free, and everybody should implement
 what they think it's best. But first, you should talk to Jolla, because
 they're the ones that will eventually allow apps with your ad-SDK in
 Harbour. And, depending on their philosphy and principles regarding this
 matter (yet unkown), they may approve of your SDK, or not. If apps using
 the ad-SDK won't be admitted on Harbour, it will be hard to earn money
 through it, I think. Also, don't forget Jolla already has plans for some
 "SuperApps" or whatever they're called, which is basically sponsored
 content. There may be some politics involved here, regarding ads in normal
 apps.

 Bottom line: ask Jolla if they will allow apps using the ad-SDK on
 Harbour, and how does it relate to their already-planned sponsored content
 in the OS.

 Best regards,
 Camil

 On Tuesday 31 May 2016 10:10:42 devel-requ...@lists.sailfishos.org
 wrote:
 > Re: Open source in-app ad API helper for QML - please, join

 ___
 SailfishOS.org Devel mailing list
 To unsubscribe, please send a mail to
 devel-requ...@lists.sailfishos.org



 ___
 SailfishOS.org Devel mailing list
 To unsubscribe, please send a mail to
 devel-unsubscr...@lists.sailfishos.org

>>>
>>>
>>>
>>> ___
>>> SailfishOS.org Devel mailing list
>>> To unsubscribe, please send a mail to
>>> devel-unsubscr...@lists.sailfishos.org
>>>
>>
>>
>> ___
>> SailfishOS.org Devel mailing list
>> To unsubscribe, please send a mail to
>> devel-unsubscr...@lists.sailfishos.org
>>
>
>
> ___
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to
> devel-unsubscr...@lists.sailfishos.org
>
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

[SailfishDevel] [Minutes] Sailfish OS Open Source Community Collaboration Meeting, 2nd June 2016

[James Noori]

Ahoy everyone!

Thanks to all who attended today's meeting.
Meeting minutes can be found here in a variety of formats:

Minutes: 
http://merproject.org/meetings/mer-meeting/2016/mer-meeting.2016-06-02-13.30.html
Minutes (text): 
http://merproject.org/meetings/mer-meeting/2016/mer-meeting.2016-06-02-13.30.txt
Log: 
http://merproject.org/meetings/mer-meeting/2016/mer-meeting.2016-06-02-13.30.log.html


If you wish to propose a topic for the next meeting, please do so here:

https://together.jolla.com/question/54157/sailfishos-open-source-collaboration-meeting-planning/

The next meeting is scheduled for Thursday the 23rd of June 2016 at 
*9:00* UTC.

***Note that the time has changed***


Thanks and best regards,
James Noori (Jaymzz)
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] Sailfish OS Open Source Community Collaboration Meeting 2nd of June 2016

[Andrew Branson]

I'm not sure but think it's a triple store, so a rudimentary one. On 
Sailfish it seems to be intended for more action, as there are a couple 
of disabled stores in there...


On 02/06/2016 2:42pm, Tone Kastlunger wrote:

In a distributed fashion it may make sense;
speaking of which, doesn't tracker implement a graph db?

On Thu, Jun 2, 2016 at 3:40 PM, Andrew Branson
> wrote:

I'm missing how your contacts can be linked as a graph on your
phone. I assumed it was about which of your friends know each other,
but that isn't relevant information on the client side. I don't
think it's even easily available in the main social networks.

Andy

On 02/06/2016 2:34pm, Tone Kastlunger wrote:

On the RDBMS vs Graph DB's discussion, the point Peter is making
is a
very solid one;
the purpouse of the contacts app is to mange contacts; hence how
they
are connected;
if relying on a Graph DB provides a simpler implementation (in
terms of
raw lines of code I mean) in upper implementation levels,
whilst helping in keeping data consistency in a flawless and
hassle-free
way (which SQL can help with only up to a certain extent),
well it definitely sounds too good to be true (at least from what I
understood):
I'd agree with Neo4J on a phone being somewhat of an overkill
(same as
having Postgres for instance); I'd wonder if there are embedded
versions
of it?
I'd say especially within Jolla's Social/Address book/mail/calendar
contacts management peculiarities, plus the dual SFOS/Android
world, it
requires a
rock-solid contact management system, I'd assume.

tk


On Thu, Jun 2, 2016 at 3:22 PM, Andrew Branson

>> wrote:

 Hi!

 RDBMSes are not very good at graphs, or trees, or any other
data
 structure that requires variable traversal steps in
queries. I don't
 think we have that here though. Those social networks only have
 graphs when they're integrating your data with other
people's, but
 personally you just have your own address book and your own
 calendars. Both of those consist of many instances of the
same data
 structures which need to be indexed, which is a good use of
 relational databases.

 Your point about SQL being used out of habit is always
pertinent
 though. It's important to keep on top of the NoSQL options,
as SQL
 is definitely overused. I always find it very irritating
when SQL is
 used only for config storage, using tables with single rows
and many
 columns. Berkeley DB would be a good alternative for that.
I don't
 know if the graph DBs are ready yet though - Neo4J is very
 interesting, but I would never run a Java server in a phone.

 While we're on the subject, I think the Nemo thumbnail DB is a
 really good candidate for a NoSQL database. It's currently
a huge
 collection of tiny files that seems to take up way too much
BTRFS
 allocation, and I don't think as a collection of binary
files it
 would be a good match for SQLite.

 Andy


 On 02/06/2016 1:42pm, Peter Kovacs wrote:

 Well SQL is in my opinion good for grouping or conduct
 calculations on
 transactional data.
 Updating, or adding / sorting is not is best
discipline. It is
 medicore
 in my opinion.
 On small sets of data as used in phones medicore
performance is
 still
 quick. Phones are quite powerfull today.

 However the feature the DB should excel should be, in
my eyes
 social,
 stuff. It is a phone after all, intended to maintain my
social
 life, or?

 And Facebook, amazon, google+ does not use relational
databases.
 They
 use graph databases. So I wonder why this is not used
on phones.
 Neo4j
 claims to outperform relational databases by a factor
of 1000
 when it
 comes to relationships.

 I admit these softwares are very latest technology. And
maybe not as
 robust as sqllite.
 However I would 

Re: [SailfishDevel] Sailfish OS Open Source Community Collaboration Meeting 2nd of June 2016

[Tone Kastlunger]

In a distributed fashion it may make sense;
speaking of which, doesn't tracker implement a graph db?

On Thu, Jun 2, 2016 at 3:40 PM, Andrew Branson 
wrote:

> I'm missing how your contacts can be linked as a graph on your phone. I
> assumed it was about which of your friends know each other, but that isn't
> relevant information on the client side. I don't think it's even easily
> available in the main social networks.
>
> Andy
>
> On 02/06/2016 2:34pm, Tone Kastlunger wrote:
>
>> On the RDBMS vs Graph DB's discussion, the point Peter is making is a
>> very solid one;
>> the purpouse of the contacts app is to mange contacts; hence how they
>> are connected;
>> if relying on a Graph DB provides a simpler implementation (in terms of
>> raw lines of code I mean) in upper implementation levels,
>> whilst helping in keeping data consistency in a flawless and hassle-free
>> way (which SQL can help with only up to a certain extent),
>> well it definitely sounds too good to be true (at least from what I
>> understood):
>> I'd agree with Neo4J on a phone being somewhat of an overkill (same as
>> having Postgres for instance); I'd wonder if there are embedded versions
>> of it?
>> I'd say especially within Jolla's Social/Address book/mail/calendar
>> contacts management peculiarities, plus the dual SFOS/Android world, it
>> requires a
>> rock-solid contact management system, I'd assume.
>>
>> tk
>>
>>
>> On Thu, Jun 2, 2016 at 3:22 PM, Andrew Branson
>> > wrote:
>>
>> Hi!
>>
>> RDBMSes are not very good at graphs, or trees, or any other data
>> structure that requires variable traversal steps in queries. I don't
>> think we have that here though. Those social networks only have
>> graphs when they're integrating your data with other people's, but
>> personally you just have your own address book and your own
>> calendars. Both of those consist of many instances of the same data
>> structures which need to be indexed, which is a good use of
>> relational databases.
>>
>> Your point about SQL being used out of habit is always pertinent
>> though. It's important to keep on top of the NoSQL options, as SQL
>> is definitely overused. I always find it very irritating when SQL is
>> used only for config storage, using tables with single rows and many
>> columns. Berkeley DB would be a good alternative for that. I don't
>> know if the graph DBs are ready yet though - Neo4J is very
>> interesting, but I would never run a Java server in a phone.
>>
>> While we're on the subject, I think the Nemo thumbnail DB is a
>> really good candidate for a NoSQL database. It's currently a huge
>> collection of tiny files that seems to take up way too much BTRFS
>> allocation, and I don't think as a collection of binary files it
>> would be a good match for SQLite.
>>
>> Andy
>>
>>
>> On 02/06/2016 1:42pm, Peter Kovacs wrote:
>>
>> Well SQL is in my opinion good for grouping or conduct
>> calculations on
>> transactional data.
>> Updating, or adding / sorting is not is best discipline. It is
>> medicore
>> in my opinion.
>> On small sets of data as used in phones medicore performance is
>> still
>> quick. Phones are quite powerfull today.
>>
>> However the feature the DB should excel should be, in my eyes
>> social,
>> stuff. It is a phone after all, intended to maintain my social
>> life, or?
>>
>> And Facebook, amazon, google+ does not use relational databases.
>> They
>> use graph databases. So I wonder why this is not used on phones.
>> Neo4j
>> claims to outperform relational databases by a factor of 1000
>> when it
>> comes to relationships.
>>
>> I admit these softwares are very latest technology. And maybe not
>> as
>> robust as sqllite.
>> However I would love to have a contact app which knows that Mary
>> and Joe
>> are married live in the same place. And when I search for one of
>> the 2 I
>> get the shared information. And when I update one end the app
>> knows to
>> update the other one too.
>> Or it can store company hierarchies would help me in my business
>> life. I
>> am not good at memo these.
>>
>> Yes you can do that with sql. But I think it is easier more
>> naturally
>> done in a graph db.
>> No problem if any one does not agree. I plan to build this anyhow.
>>
>> I am quite unhappy with Google in that because they are not
>> doing this
>> for me ;)
>>
>> Btw Object DB is good at storing objects as the name suggests. It
>> is
>> even more far away from the requirements on a phone then
>> relational db
>> 

Re: [SailfishDevel] Sailfish OS Open Source Community Collaboration Meeting 2nd of June 2016

[Andrew Branson]

I'm missing how your contacts can be linked as a graph on your phone. I 
assumed it was about which of your friends know each other, but that 
isn't relevant information on the client side. I don't think it's even 
easily available in the main social networks.


Andy

On 02/06/2016 2:34pm, Tone Kastlunger wrote:

On the RDBMS vs Graph DB's discussion, the point Peter is making is a
very solid one;
the purpouse of the contacts app is to mange contacts; hence how they
are connected;
if relying on a Graph DB provides a simpler implementation (in terms of
raw lines of code I mean) in upper implementation levels,
whilst helping in keeping data consistency in a flawless and hassle-free
way (which SQL can help with only up to a certain extent),
well it definitely sounds too good to be true (at least from what I
understood):
I'd agree with Neo4J on a phone being somewhat of an overkill (same as
having Postgres for instance); I'd wonder if there are embedded versions
of it?
I'd say especially within Jolla's Social/Address book/mail/calendar
contacts management peculiarities, plus the dual SFOS/Android world, it
requires a
rock-solid contact management system, I'd assume.

tk


On Thu, Jun 2, 2016 at 3:22 PM, Andrew Branson
> wrote:

Hi!

RDBMSes are not very good at graphs, or trees, or any other data
structure that requires variable traversal steps in queries. I don't
think we have that here though. Those social networks only have
graphs when they're integrating your data with other people's, but
personally you just have your own address book and your own
calendars. Both of those consist of many instances of the same data
structures which need to be indexed, which is a good use of
relational databases.

Your point about SQL being used out of habit is always pertinent
though. It's important to keep on top of the NoSQL options, as SQL
is definitely overused. I always find it very irritating when SQL is
used only for config storage, using tables with single rows and many
columns. Berkeley DB would be a good alternative for that. I don't
know if the graph DBs are ready yet though - Neo4J is very
interesting, but I would never run a Java server in a phone.

While we're on the subject, I think the Nemo thumbnail DB is a
really good candidate for a NoSQL database. It's currently a huge
collection of tiny files that seems to take up way too much BTRFS
allocation, and I don't think as a collection of binary files it
would be a good match for SQLite.

Andy


On 02/06/2016 1:42pm, Peter Kovacs wrote:

Well SQL is in my opinion good for grouping or conduct
calculations on
transactional data.
Updating, or adding / sorting is not is best discipline. It is
medicore
in my opinion.
On small sets of data as used in phones medicore performance is
still
quick. Phones are quite powerfull today.

However the feature the DB should excel should be, in my eyes
social,
stuff. It is a phone after all, intended to maintain my social
life, or?

And Facebook, amazon, google+ does not use relational databases.
They
use graph databases. So I wonder why this is not used on phones.
Neo4j
claims to outperform relational databases by a factor of 1000
when it
comes to relationships.

I admit these softwares are very latest technology. And maybe not as
robust as sqllite.
However I would love to have a contact app which knows that Mary
and Joe
are married live in the same place. And when I search for one of
the 2 I
get the shared information. And when I update one end the app
knows to
update the other one too.
Or it can store company hierarchies would help me in my business
life. I
am not good at memo these.

Yes you can do that with sql. But I think it is easier more
naturally
done in a graph db.
No problem if any one does not agree. I plan to build this anyhow.

I am quite unhappy with Google in that because they are not
doing this
for me ;)

Btw Object DB is good at storing objects as the name suggests. It is
even more far away from the requirements on a phone then
relational db
in my eyes.

All the Best
Peter


Tone Kastlunger 
>> schrieb am Do., 2. Juni
2016, 11:13:

 Peter;
 I'm curious, what brings you to the conclusion SQL (as in
relational
 dbs) is not ideal for transactional functionality?

 On Thu, Jun 2, 2016 at 

Re: [SailfishDevel] Sailfish OS Open Source Community Collaboration Meeting 2nd of June 2016

[Tone Kastlunger]

On the RDBMS vs Graph DB's discussion, the point Peter is making is a very
solid one;
the purpouse of the contacts app is to mange contacts; hence how they are
connected;
if relying on a Graph DB provides a simpler implementation (in terms of raw
lines of code I mean) in upper implementation levels,
whilst helping in keeping data consistency in a flawless and hassle-free
way (which SQL can help with only up to a certain extent),
well it definitely sounds too good to be true (at least from what I
understood):
I'd agree with Neo4J on a phone being somewhat of an overkill (same as
having Postgres for instance); I'd wonder if there are embedded versions of
it?
I'd say especially within Jolla's Social/Address book/mail/calendar
contacts management peculiarities, plus the dual SFOS/Android world, it
requires a
rock-solid contact management system, I'd assume.

tk


On Thu, Jun 2, 2016 at 3:22 PM, Andrew Branson 
wrote:

> Hi!
>
> RDBMSes are not very good at graphs, or trees, or any other data structure
> that requires variable traversal steps in queries. I don't think we have
> that here though. Those social networks only have graphs when they're
> integrating your data with other people's, but personally you just have
> your own address book and your own calendars. Both of those consist of many
> instances of the same data structures which need to be indexed, which is a
> good use of relational databases.
>
> Your point about SQL being used out of habit is always pertinent though.
> It's important to keep on top of the NoSQL options, as SQL is definitely
> overused. I always find it very irritating when SQL is used only for config
> storage, using tables with single rows and many columns. Berkeley DB would
> be a good alternative for that. I don't know if the graph DBs are ready yet
> though - Neo4J is very interesting, but I would never run a Java server in
> a phone.
>
> While we're on the subject, I think the Nemo thumbnail DB is a really good
> candidate for a NoSQL database. It's currently a huge collection of tiny
> files that seems to take up way too much BTRFS allocation, and I don't
> think as a collection of binary files it would be a good match for SQLite.
>
> Andy
>
>
> On 02/06/2016 1:42pm, Peter Kovacs wrote:
>
>> Well SQL is in my opinion good for grouping or conduct  calculations on
>> transactional data.
>> Updating, or adding / sorting is not is best discipline. It is medicore
>> in my opinion.
>> On small sets of data as used in phones medicore performance is still
>> quick. Phones are quite powerfull today.
>>
>> However the feature the DB should excel should be, in my eyes social,
>> stuff. It is a phone after all, intended to maintain my social life, or?
>>
>> And Facebook, amazon, google+ does not use relational databases. They
>> use graph databases. So I wonder why this is not used on phones. Neo4j
>> claims to outperform relational databases by a factor of 1000 when it
>> comes to relationships.
>>
>> I admit these softwares are very latest technology. And maybe not as
>> robust as sqllite.
>> However I would love to have a contact app which knows that Mary and Joe
>> are married live in the same place. And when I search for one of the 2 I
>> get the shared information. And when I update one end the app knows to
>> update the other one too.
>> Or it can store company hierarchies would help me in my business life. I
>> am not good at memo these.
>>
>> Yes you can do that with sql. But I think it is easier more naturally
>> done in a graph db.
>> No problem if any one does not agree. I plan to build this anyhow.
>>
>> I am quite unhappy with Google in that because they are not doing this
>> for me ;)
>>
>> Btw Object DB is good at storing objects as the name suggests. It is
>> even more far away from the requirements on a phone then relational db
>> in my eyes.
>>
>> All the Best
>> Peter
>>
>>
>> Tone Kastlunger > > schrieb am Do., 2. Juni 2016, 11:13:
>>
>> Peter;
>> I'm curious, what brings you to the conclusion SQL (as in relational
>> dbs) is not ideal for transactional functionality?
>>
>> On Thu, Jun 2, 2016 at 10:41 AM, Peter Kovacs > > wrote:
>>
>> I would actually like to know why SQL stuff.
>> Datastructure types I am think of on the Phone are relationships
>> (Facebook style) or transactional.
>> And both are not ideal to solve with relational dbs.
>>
>> I guess the Answer is because every one does it. But that is not
>> really satisfactory.  Would there be an interest to use
>> something else?
>>
>>
>> Tone Kastlunger > > schrieb am Do., 2. Juni
>> 2016, 09:33:
>>
>> Hi Chris;
>>
>>
>>  >2) API to access Calendar data.  Correct, currently we
>> 

Re: [SailfishDevel] Sailfish OS Open Source Community Collaboration Meeting 2nd of June 2016

[Andrew Branson]

Hi!

RDBMSes are not very good at graphs, or trees, or any other data 
structure that requires variable traversal steps in queries. I don't 
think we have that here though. Those social networks only have graphs 
when they're integrating your data with other people's, but personally 
you just have your own address book and your own calendars. Both of 
those consist of many instances of the same data structures which need 
to be indexed, which is a good use of relational databases.


Your point about SQL being used out of habit is always pertinent though. 
It's important to keep on top of the NoSQL options, as SQL is definitely 
overused. I always find it very irritating when SQL is used only for 
config storage, using tables with single rows and many columns. Berkeley 
DB would be a good alternative for that. I don't know if the graph DBs 
are ready yet though - Neo4J is very interesting, but I would never run 
a Java server in a phone.


While we're on the subject, I think the Nemo thumbnail DB is a really 
good candidate for a NoSQL database. It's currently a huge collection of 
tiny files that seems to take up way too much BTRFS allocation, and I 
don't think as a collection of binary files it would be a good match for 
SQLite.


Andy

On 02/06/2016 1:42pm, Peter Kovacs wrote:

Well SQL is in my opinion good for grouping or conduct  calculations on
transactional data.
Updating, or adding / sorting is not is best discipline. It is medicore
in my opinion.
On small sets of data as used in phones medicore performance is still
quick. Phones are quite powerfull today.

However the feature the DB should excel should be, in my eyes social,
stuff. It is a phone after all, intended to maintain my social life, or?

And Facebook, amazon, google+ does not use relational databases. They
use graph databases. So I wonder why this is not used on phones. Neo4j
claims to outperform relational databases by a factor of 1000 when it
comes to relationships.

I admit these softwares are very latest technology. And maybe not as
robust as sqllite.
However I would love to have a contact app which knows that Mary and Joe
are married live in the same place. And when I search for one of the 2 I
get the shared information. And when I update one end the app knows to
update the other one too.
Or it can store company hierarchies would help me in my business life. I
am not good at memo these.

Yes you can do that with sql. But I think it is easier more naturally
done in a graph db.
No problem if any one does not agree. I plan to build this anyhow.

I am quite unhappy with Google in that because they are not doing this
for me ;)

Btw Object DB is good at storing objects as the name suggests. It is
even more far away from the requirements on a phone then relational db
in my eyes.

All the Best
Peter


Tone Kastlunger > schrieb am Do., 2. Juni 2016, 11:13:

Peter;
I'm curious, what brings you to the conclusion SQL (as in relational
dbs) is not ideal for transactional functionality?

On Thu, Jun 2, 2016 at 10:41 AM, Peter Kovacs > wrote:

I would actually like to know why SQL stuff.
Datastructure types I am think of on the Phone are relationships
(Facebook style) or transactional.
And both are not ideal to solve with relational dbs.

I guess the Answer is because every one does it. But that is not
really satisfactory.  Would there be an interest to use
something else?


Tone Kastlunger > schrieb am Do., 2. Juni
2016, 09:33:

Hi Chris;


 >2) API to access Calendar data.  Correct, currently we
don't provide access to calendar API in Harbour.  The reason
is that we want to use QtOrganizer as the public API, but to
do that we need to write a QtOrganizer engine backend >for
mkcal (note that one already existed in QtMobility days,
which is open source, so we can potentially adapt that one
with relatively little effort.  Help with that effort would
be greatly appreciated).  Eventually, I'd like to develop a
 >QtOrganizer backend directly in sqlite, for performance
and maintainability reasons (mkcal has several design and
implementation problems, in my opinion), at which point
QtOrganizer can become the platform API (not just the 3rd
 >party API).


I guess the worload to push it all the way to QtOrganizer
requires scratching the existing backend / rewriting a big
part of the cal app?

On Thu, Jun 2, 2016 at 5:06 AM, Chris Adams
> wrote:

Hi everyone,

I will try to be at the 

Re: [SailfishDevel] Sailfish OS Open Source Community Collaboration Meeting 2nd of June 2016

[Peter Kovacs]

Well SQL is in my opinion good for grouping or conduct  calculations on
transactional data.
Updating, or adding / sorting is not is best discipline. It is medicore in
my opinion.
On small sets of data as used in phones medicore performance is still
quick. Phones are quite powerfull today.

However the feature the DB should excel should be, in my eyes social,
stuff. It is a phone after all, intended to maintain my social life, or?

And Facebook, amazon, google+ does not use relational databases. They use
graph databases. So I wonder why this is not used on phones. Neo4j claims
to outperform relational databases by a factor of 1000 when it comes to
relationships.

I admit these softwares are very latest technology. And maybe not as robust
as sqllite.
However I would love to have a contact app which knows that Mary and Joe
are married live in the same place. And when I search for one of the 2 I
get the shared information. And when I update one end the app knows to
update the other one too.
Or it can store company hierarchies would help me in my business life. I am
not good at memo these.

Yes you can do that with sql. But I think it is easier more naturally done
in a graph db.
No problem if any one does not agree. I plan to build this anyhow.

I am quite unhappy with Google in that because they are not doing this for
me ;)

Btw Object DB is good at storing objects as the name suggests. It is even
more far away from the requirements on a phone then relational db in my
eyes.

All the Best
Peter

Tone Kastlunger  schrieb am Do., 2. Juni 2016,
11:13:

> Peter;
> I'm curious, what brings you to the conclusion SQL (as in relational dbs)
> is not ideal for transactional functionality?
>
> On Thu, Jun 2, 2016 at 10:41 AM, Peter Kovacs  wrote:
>
>> I would actually like to know why SQL stuff.
>> Datastructure types I am think of on the Phone are relationships
>> (Facebook style) or transactional.
>> And both are not ideal to solve with relational dbs.
>>
>> I guess the Answer is because every one does it. But that is not really
>> satisfactory.  Would there be an interest to use something else?
>>
>> Tone Kastlunger  schrieb am Do., 2. Juni
>> 2016, 09:33:
>>
>>> Hi Chris;
>>>
>>>
>>> >2) API to access Calendar data.  Correct, currently we don't provide
>>> access to calendar API in Harbour.  The reason is that we want to use
>>> QtOrganizer as the public API, but to do that we need to write a
>>> QtOrganizer engine backend >for mkcal (note that one already existed in
>>> QtMobility days, which is open source, so we can potentially adapt that one
>>> with relatively little effort.  Help with that effort would be greatly
>>> appreciated).  Eventually, I'd like to develop a >QtOrganizer backend
>>> directly in sqlite, for performance and maintainability reasons (mkcal has
>>> several design and implementation problems, in my opinion), at which point
>>> QtOrganizer can become the platform API (not just the 3rd >party API).
>>>
>>>
>>> I guess the worload to push it all the way to QtOrganizer requires
>>> scratching the existing backend / rewriting a big part of the cal app?
>>>
>>> On Thu, Jun 2, 2016 at 5:06 AM, Chris Adams 
>>> wrote:
>>>
 Hi everyone,

 I will try to be at the meeting tonight, but I cannot promise (it's
 held at 11:30 pm in my timezone).

 A couple of the questions relate to areas I am involved with, so I'll
 try to provide some information in case I don't make it to the meeting.  If
 you have any follow up questions or discussion, feel free to contact me
 directly via email or on Freenode IRC (chriadam is my nick).

 1) Contact Note details.  This is tracked internally by JB#14734.  As
 you mentioned, it's supported in the backend, but not in the People app
 UI.  It was on going to be part of the apps overhaul which was planned
 prior to the financial difficulties last year, and since then this has
 fallen off the radar.  It requires design input, because you can have
 multiple Note details in a single contact.  I've just pinged our lead
 designer in the bug report again, in case he can fit it in sometime soon.

 2) API to access Calendar data.  Correct, currently we don't provide
 access to calendar API in Harbour.  The reason is that we want to use
 QtOrganizer as the public API, but to do that we need to write a
 QtOrganizer engine backend for mkcal (note that one already existed in
 QtMobility days, which is open source, so we can potentially adapt that one
 with relatively little effort.  Help with that effort would be greatly
 appreciated).  Eventually, I'd like to develop a QtOrganizer backend
 directly in sqlite, for performance and maintainability reasons (mkcal has
 several design and implementation problems, in my opinion), at which point
 QtOrganizer can become the platform API (not 

Re: [SailfishDevel] Sailfish OS Open Source Community Collaboration Meeting 2nd of June 2016

[Tone Kastlunger]

Peter;
I'm curious, what brings you to the conclusion SQL (as in relational dbs)
is not ideal for transactional functionality?

On Thu, Jun 2, 2016 at 10:41 AM, Peter Kovacs  wrote:

> I would actually like to know why SQL stuff.
> Datastructure types I am think of on the Phone are relationships (Facebook
> style) or transactional.
> And both are not ideal to solve with relational dbs.
>
> I guess the Answer is because every one does it. But that is not really
> satisfactory.  Would there be an interest to use something else?
>
> Tone Kastlunger  schrieb am Do., 2. Juni 2016,
> 09:33:
>
>> Hi Chris;
>>
>>
>> >2) API to access Calendar data.  Correct, currently we don't provide
>> access to calendar API in Harbour.  The reason is that we want to use
>> QtOrganizer as the public API, but to do that we need to write a
>> QtOrganizer engine backend >for mkcal (note that one already existed in
>> QtMobility days, which is open source, so we can potentially adapt that one
>> with relatively little effort.  Help with that effort would be greatly
>> appreciated).  Eventually, I'd like to develop a >QtOrganizer backend
>> directly in sqlite, for performance and maintainability reasons (mkcal has
>> several design and implementation problems, in my opinion), at which point
>> QtOrganizer can become the platform API (not just the 3rd >party API).
>>
>>
>> I guess the worload to push it all the way to QtOrganizer requires
>> scratching the existing backend / rewriting a big part of the cal app?
>>
>> On Thu, Jun 2, 2016 at 5:06 AM, Chris Adams 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> I will try to be at the meeting tonight, but I cannot promise (it's held
>>> at 11:30 pm in my timezone).
>>>
>>> A couple of the questions relate to areas I am involved with, so I'll
>>> try to provide some information in case I don't make it to the meeting.  If
>>> you have any follow up questions or discussion, feel free to contact me
>>> directly via email or on Freenode IRC (chriadam is my nick).
>>>
>>> 1) Contact Note details.  This is tracked internally by JB#14734.  As
>>> you mentioned, it's supported in the backend, but not in the People app
>>> UI.  It was on going to be part of the apps overhaul which was planned
>>> prior to the financial difficulties last year, and since then this has
>>> fallen off the radar.  It requires design input, because you can have
>>> multiple Note details in a single contact.  I've just pinged our lead
>>> designer in the bug report again, in case he can fit it in sometime soon.
>>>
>>> 2) API to access Calendar data.  Correct, currently we don't provide
>>> access to calendar API in Harbour.  The reason is that we want to use
>>> QtOrganizer as the public API, but to do that we need to write a
>>> QtOrganizer engine backend for mkcal (note that one already existed in
>>> QtMobility days, which is open source, so we can potentially adapt that one
>>> with relatively little effort.  Help with that effort would be greatly
>>> appreciated).  Eventually, I'd like to develop a QtOrganizer backend
>>> directly in sqlite, for performance and maintainability reasons (mkcal has
>>> several design and implementation problems, in my opinion), at which point
>>> QtOrganizer can become the platform API (not just the 3rd party API).
>>>
>>> 3) Email app development.  Yes, you're absolutely right that the Email
>>> application hasn't received much development effort since Valerio
>>> unfortunately left.  Yes, I would personally like to see it (along with
>>> other apps like Clock, Notes, and Calendar) opensourced.  No, I don't know
>>> what the status of the opensourcing discussions with the Board Of Directors
>>> is, so I cannot give a roadmap for that possibility.  However, the "engine"
>>> of the email application is already open source (except for the
>>> Exchange/ActiveSync plugin) - we use QMF (Qt Messaging Framework) for email
>>> handling.  See https://git.merproject.org/mer-core/qmf and
>>> https://git.merproject.org/mer-core/messagingframework etc for that
>>> stuff.  Speak to Matt Vogt (mvogt on Freenode IRC) for code reviews etc.
>>>
>>> In general, the Sailfish OS wiki has been updated with a lot of
>>> information about the various software components which make up the
>>> Sailfish OS stack (including links to the open-source repositories), so you
>>> should be able to find most of the information you need to help develop
>>> these components, from reading
>>> https://sailfishos.org/wiki/Core_Areas_and_APIs and the drill-down
>>> links from that page.
>>>
>>> Finally, I don't know much about Bluetooth, but I know that we're
>>> looking at updating to Bluez 5 right now (development is currently ongoing
>>> to port the Qt stack across, possibly by using the KDE bluez-qt wrappers),
>>> so it's possible that the tethering issue will be addressed as part of
>>> that, with the new stack - but again, that's not my area so I might be
>>> 

Re: [SailfishDevel] Sailfish OS Open Source Community Collaboration Meeting 2nd of June 2016

[Chris Adams]

Hi Peter,

All of this is just my opinion, and not necessarily representative of the views 
of Jolla.

The reason is that SQL is simple, maintainable, and performant.
Yes, there are some edges which need to be handled carefully, but in general, 
sqlite is the perfect solution for this type of data.

Nokia tried to break out of the silos by putting all the data into 
system-ranging semantic-web style RDF-triple or object-relationship datastores 
(first Tracker and then JSONdb) and both of those projects failed in part due 
to the unmanageable complexity and poor performance they entail.  Even 
relatively simple projects which rely on Tracker (like data file metadata 
collectors) are plagued with issues which require in-depth expertise to resolve.

Relationships between identified, precisely specified data blobs can be stored 
separately, and still give 95% of the advantages, without the complexity, using 
databases and software components which any competent developer can maintain 
and improve.

Cheers,
Chris.




From: devel-boun...@lists.sailfishos.org [devel-boun...@lists.sailfishos.org] 
on behalf of Peter Kovacs [legi...@gmail.com]
Sent: Thursday, June 02, 2016 5:41 PM
To: Sailfish OS Developers
Subject: Re: [SailfishDevel] Sailfish OS Open Source Community Collaboration 
Meeting 2nd of June 2016


I would actually like to know why SQL stuff.
Datastructure types I am think of on the Phone are relationships (Facebook 
style) or transactional.
And both are not ideal to solve with relational dbs.

I guess the Answer is because every one does it. But that is not really 
satisfactory.  Would there be an interest to use something else?

Tone Kastlunger 
>
 schrieb am Do., 2. Juni 2016, 09:33:
Hi Chris;


>2) API to access Calendar data.  Correct, currently we don't provide access to 
>calendar API in Harbour.  The reason is that we want to use QtOrganizer as the 
>public API, but to do that we need to write a QtOrganizer engine backend >for 
>mkcal (note that one already existed in QtMobility days, which is open source, 
>so we can potentially adapt that one with relatively little effort.  Help with 
>that effort would be greatly appreciated).  Eventually, I'd like to develop a 
>>QtOrganizer backend directly in sqlite, for performance and maintainability 
>reasons (mkcal has several design and implementation problems, in my opinion), 
>at which point QtOrganizer can become the platform API (not just the 3rd 
>>party API).


I guess the worload to push it all the way to QtOrganizer requires scratching 
the existing backend / rewriting a big part of the cal app?

On Thu, Jun 2, 2016 at 5:06 AM, Chris Adams 
>
 wrote:
Hi everyone,

I will try to be at the meeting tonight, but I cannot promise (it's held at 
11:30 pm in my timezone).

A couple of the questions relate to areas I am involved with, so I'll try to 
provide some information in case I don't make it to the meeting.  If you have 
any follow up questions or discussion, feel free to contact me directly via 
email or on Freenode IRC (chriadam is my nick).

1) Contact Note details.  This is tracked internally by JB#14734.  As you 
mentioned, it's supported in the backend, but not in the People app UI.  It was 
on going to be part of the apps overhaul which was planned prior to the 
financial difficulties last year, and since then this has fallen off the radar. 
 It requires design input, because you can have multiple Note details in a 
single contact.  I've just pinged our lead designer in the bug report again, in 
case he can fit it in sometime soon.

2) API to access Calendar data.  Correct, currently we don't provide access to 
calendar API in Harbour.  The reason is that we want to use QtOrganizer as the 
public API, but to do that we need to write a QtOrganizer engine backend for 
mkcal (note that one already existed in QtMobility days, which is open source, 
so we can potentially adapt that one with relatively little effort.  Help with 
that effort would be greatly appreciated).  Eventually, I'd like to develop a 
QtOrganizer backend directly in sqlite, for performance and maintainability 
reasons (mkcal has several design and implementation problems, in my opinion), 
at which point QtOrganizer can become the platform API (not just the 3rd party 
API).

3) Email app development.  Yes, you're absolutely right that the Email 
application hasn't received much development effort since Valerio unfortunately 
left.  Yes, I would personally like to see it (along with other apps like 
Clock, Notes, and Calendar) opensourced.  No, I don't know what the status of 
the opensourcing discussions with the Board Of Directors is, so I cannot give a 
roadmap for 

Re: [SailfishDevel] Sailfish OS Open Source Community Collaboration Meeting 2nd of June 2016

[Chris Adams]

Hi Tone,

There is an intermediate stage (using an mkcal-backed QtOrganizer engine, to 
provide read/write access to the mkcal backend data via QtOrganizer apis) which 
wouldn't require any changes to the jolla-calendar application (or the various 
sync adaptors we have currently).

But if we eventually replaced the backend entirely to be a QtOrganizer sqlite 
backend, then yes, we would either need to modify the jolla-calendar 
application to use the QtOrganizer declarative API, or we would need to modify 
nemo-qml-plugin-calendar to use QtOrganizer instead of KCal API, and then we 
would also need to modify all of the sync adaptors.

Cheers,
Chris.



From: devel-boun...@lists.sailfishos.org [devel-boun...@lists.sailfishos.org] 
on behalf of Tone Kastlunger [users.giulie...@gmail.com]
Sent: Thursday, June 02, 2016 5:33 PM
To: Sailfish OS Developers
Subject: Re: [SailfishDevel] Sailfish OS Open Source Community Collaboration 
Meeting 2nd of June 2016

Hi Chris;

>2) API to access Calendar data.  Correct, currently we don't provide access to 
>calendar API in Harbour.  The reason is that we want to use QtOrganizer as the 
>public API, but to do that we need to write a QtOrganizer engine backend >for 
>mkcal (note that one already existed in QtMobility days, which is open source, 
>so we can potentially adapt that one with relatively little effort.  Help with 
>that effort would be greatly appreciated).  Eventually, I'd like to develop a 
>>QtOrganizer backend directly in sqlite, for performance and maintainability 
>reasons (mkcal has several design and implementation problems, in my opinion), 
>at which point QtOrganizer can become the platform API (not just the 3rd 
>>party API).


I guess the worload to push it all the way to QtOrganizer requires scratching 
the existing backend / rewriting a big part of the cal app?

On Thu, Jun 2, 2016 at 5:06 AM, Chris Adams 
>
 wrote:
Hi everyone,

I will try to be at the meeting tonight, but I cannot promise (it's held at 
11:30 pm in my timezone).

A couple of the questions relate to areas I am involved with, so I'll try to 
provide some information in case I don't make it to the meeting.  If you have 
any follow up questions or discussion, feel free to contact me directly via 
email or on Freenode IRC (chriadam is my nick).

1) Contact Note details.  This is tracked internally by JB#14734.  As you 
mentioned, it's supported in the backend, but not in the People app UI.  It was 
on going to be part of the apps overhaul which was planned prior to the 
financial difficulties last year, and since then this has fallen off the radar. 
 It requires design input, because you can have multiple Note details in a 
single contact.  I've just pinged our lead designer in the bug report again, in 
case he can fit it in sometime soon.

2) API to access Calendar data.  Correct, currently we don't provide access to 
calendar API in Harbour.  The reason is that we want to use QtOrganizer as the 
public API, but to do that we need to write a QtOrganizer engine backend for 
mkcal (note that one already existed in QtMobility days, which is open source, 
so we can potentially adapt that one with relatively little effort.  Help with 
that effort would be greatly appreciated).  Eventually, I'd like to develop a 
QtOrganizer backend directly in sqlite, for performance and maintainability 
reasons (mkcal has several design and implementation problems, in my opinion), 
at which point QtOrganizer can become the platform API (not just the 3rd party 
API).

3) Email app development.  Yes, you're absolutely right that the Email 
application hasn't received much development effort since Valerio unfortunately 
left.  Yes, I would personally like to see it (along with other apps like 
Clock, Notes, and Calendar) opensourced.  No, I don't know what the status of 
the opensourcing discussions with the Board Of Directors is, so I cannot give a 
roadmap for that possibility.  However, the "engine" of the email application 
is already open source (except for the Exchange/ActiveSync plugin) - we use QMF 
(Qt Messaging Framework) for email handling.  See 
https://git.merproject.org/mer-core/qmf
 and 
https://git.merproject.org/mer-core/messagingframework
 etc for that stuff.  Speak to Matt Vogt (mvogt on Freenode IRC) for code 
reviews etc.

In general, the Sailfish OS wiki has been updated with a lot of information 
about the various software components which make up the Sailfish OS stack 
(including links to the open-source repositories), so you should be able to 
find most of 

Re: [SailfishDevel] Sailfish OS Open Source Community Collaboration Meeting 2nd of June 2016

[Peter Kovacs]

I would actually like to know why SQL stuff.
Datastructure types I am think of on the Phone are relationships (Facebook
style) or transactional.
And both are not ideal to solve with relational dbs.

I guess the Answer is because every one does it. But that is not really
satisfactory.  Would there be an interest to use something else?

Tone Kastlunger  schrieb am Do., 2. Juni 2016,
09:33:

> Hi Chris;
>
>
> >2) API to access Calendar data.  Correct, currently we don't provide
> access to calendar API in Harbour.  The reason is that we want to use
> QtOrganizer as the public API, but to do that we need to write a
> QtOrganizer engine backend >for mkcal (note that one already existed in
> QtMobility days, which is open source, so we can potentially adapt that one
> with relatively little effort.  Help with that effort would be greatly
> appreciated).  Eventually, I'd like to develop a >QtOrganizer backend
> directly in sqlite, for performance and maintainability reasons (mkcal has
> several design and implementation problems, in my opinion), at which point
> QtOrganizer can become the platform API (not just the 3rd >party API).
>
>
> I guess the worload to push it all the way to QtOrganizer requires
> scratching the existing backend / rewriting a big part of the cal app?
>
> On Thu, Jun 2, 2016 at 5:06 AM, Chris Adams  wrote:
>
>> Hi everyone,
>>
>> I will try to be at the meeting tonight, but I cannot promise (it's held
>> at 11:30 pm in my timezone).
>>
>> A couple of the questions relate to areas I am involved with, so I'll try
>> to provide some information in case I don't make it to the meeting.  If you
>> have any follow up questions or discussion, feel free to contact me
>> directly via email or on Freenode IRC (chriadam is my nick).
>>
>> 1) Contact Note details.  This is tracked internally by JB#14734.  As you
>> mentioned, it's supported in the backend, but not in the People app UI.  It
>> was on going to be part of the apps overhaul which was planned prior to the
>> financial difficulties last year, and since then this has fallen off the
>> radar.  It requires design input, because you can have multiple Note
>> details in a single contact.  I've just pinged our lead designer in the bug
>> report again, in case he can fit it in sometime soon.
>>
>> 2) API to access Calendar data.  Correct, currently we don't provide
>> access to calendar API in Harbour.  The reason is that we want to use
>> QtOrganizer as the public API, but to do that we need to write a
>> QtOrganizer engine backend for mkcal (note that one already existed in
>> QtMobility days, which is open source, so we can potentially adapt that one
>> with relatively little effort.  Help with that effort would be greatly
>> appreciated).  Eventually, I'd like to develop a QtOrganizer backend
>> directly in sqlite, for performance and maintainability reasons (mkcal has
>> several design and implementation problems, in my opinion), at which point
>> QtOrganizer can become the platform API (not just the 3rd party API).
>>
>> 3) Email app development.  Yes, you're absolutely right that the Email
>> application hasn't received much development effort since Valerio
>> unfortunately left.  Yes, I would personally like to see it (along with
>> other apps like Clock, Notes, and Calendar) opensourced.  No, I don't know
>> what the status of the opensourcing discussions with the Board Of Directors
>> is, so I cannot give a roadmap for that possibility.  However, the "engine"
>> of the email application is already open source (except for the
>> Exchange/ActiveSync plugin) - we use QMF (Qt Messaging Framework) for email
>> handling.  See https://git.merproject.org/mer-core/qmf and
>> https://git.merproject.org/mer-core/messagingframework etc for that
>> stuff.  Speak to Matt Vogt (mvogt on Freenode IRC) for code reviews etc.
>>
>> In general, the Sailfish OS wiki has been updated with a lot of
>> information about the various software components which make up the
>> Sailfish OS stack (including links to the open-source repositories), so you
>> should be able to find most of the information you need to help develop
>> these components, from reading
>> https://sailfishos.org/wiki/Core_Areas_and_APIs and the drill-down links
>> from that page.
>>
>> Finally, I don't know much about Bluetooth, but I know that we're looking
>> at updating to Bluez 5 right now (development is currently ongoing to port
>> the Qt stack across, possibly by using the KDE bluez-qt wrappers), so it's
>> possible that the tethering issue will be addressed as part of that, with
>> the new stack - but again, that's not my area so I might be incorrect.
>>
>> Cheers,
>> Chris.
>>
>>
>> --
>> *From:* devel-boun...@lists.sailfishos.org [
>> devel-boun...@lists.sailfishos.org] on behalf of James Noori [
>> james.no...@jolla.com]
>> *Sent:* Wednesday, June 01, 2016 11:15 PM
>> *To:* devel@lists.sailfishos.org
>> 

Re: [SailfishDevel] Sailfish OS Open Source Community Collaboration Meeting 2nd of June 2016

[Tone Kastlunger]

Hi Chris;

>2) API to access Calendar data.  Correct, currently we don't provide
access to calendar API in Harbour.  The reason is that we want to use
QtOrganizer as the public API, but to do that we need to write a
QtOrganizer engine backend >for mkcal (note that one already existed in
QtMobility days, which is open source, so we can potentially adapt that one
with relatively little effort.  Help with that effort would be greatly
appreciated).  Eventually, I'd like to develop a >QtOrganizer backend
directly in sqlite, for performance and maintainability reasons (mkcal has
several design and implementation problems, in my opinion), at which point
QtOrganizer can become the platform API (not just the 3rd >party API).


I guess the worload to push it all the way to QtOrganizer requires
scratching the existing backend / rewriting a big part of the cal app?

On Thu, Jun 2, 2016 at 5:06 AM, Chris Adams  wrote:

> Hi everyone,
>
> I will try to be at the meeting tonight, but I cannot promise (it's held
> at 11:30 pm in my timezone).
>
> A couple of the questions relate to areas I am involved with, so I'll try
> to provide some information in case I don't make it to the meeting.  If you
> have any follow up questions or discussion, feel free to contact me
> directly via email or on Freenode IRC (chriadam is my nick).
>
> 1) Contact Note details.  This is tracked internally by JB#14734.  As you
> mentioned, it's supported in the backend, but not in the People app UI.  It
> was on going to be part of the apps overhaul which was planned prior to the
> financial difficulties last year, and since then this has fallen off the
> radar.  It requires design input, because you can have multiple Note
> details in a single contact.  I've just pinged our lead designer in the bug
> report again, in case he can fit it in sometime soon.
>
> 2) API to access Calendar data.  Correct, currently we don't provide
> access to calendar API in Harbour.  The reason is that we want to use
> QtOrganizer as the public API, but to do that we need to write a
> QtOrganizer engine backend for mkcal (note that one already existed in
> QtMobility days, which is open source, so we can potentially adapt that one
> with relatively little effort.  Help with that effort would be greatly
> appreciated).  Eventually, I'd like to develop a QtOrganizer backend
> directly in sqlite, for performance and maintainability reasons (mkcal has
> several design and implementation problems, in my opinion), at which point
> QtOrganizer can become the platform API (not just the 3rd party API).
>
> 3) Email app development.  Yes, you're absolutely right that the Email
> application hasn't received much development effort since Valerio
> unfortunately left.  Yes, I would personally like to see it (along with
> other apps like Clock, Notes, and Calendar) opensourced.  No, I don't know
> what the status of the opensourcing discussions with the Board Of Directors
> is, so I cannot give a roadmap for that possibility.  However, the "engine"
> of the email application is already open source (except for the
> Exchange/ActiveSync plugin) - we use QMF (Qt Messaging Framework) for email
> handling.  See https://git.merproject.org/mer-core/qmf and
> https://git.merproject.org/mer-core/messagingframework etc for that
> stuff.  Speak to Matt Vogt (mvogt on Freenode IRC) for code reviews etc.
>
> In general, the Sailfish OS wiki has been updated with a lot of
> information about the various software components which make up the
> Sailfish OS stack (including links to the open-source repositories), so you
> should be able to find most of the information you need to help develop
> these components, from reading
> https://sailfishos.org/wiki/Core_Areas_and_APIs and the drill-down links
> from that page.
>
> Finally, I don't know much about Bluetooth, but I know that we're looking
> at updating to Bluez 5 right now (development is currently ongoing to port
> the Qt stack across, possibly by using the KDE bluez-qt wrappers), so it's
> possible that the tethering issue will be addressed as part of that, with
> the new stack - but again, that's not my area so I might be incorrect.
>
> Cheers,
> Chris.
>
>
> --
> *From:* devel-boun...@lists.sailfishos.org [
> devel-boun...@lists.sailfishos.org] on behalf of James Noori [
> james.no...@jolla.com]
> *Sent:* Wednesday, June 01, 2016 11:15 PM
> *To:* devel@lists.sailfishos.org
> *Subject:* [SailfishDevel] Sailfish OS Open Source Community
> Collaboration Meeting 2nd of June 2016
>
> Hi everyone!
>
>
>
> Following up last week’s postponed Community collaboration meeting on IRC,
> this week’s meeting is going to be held at the agreed time and date,
> 2/6/2016 at 13:30 UTC.
>
> Please see this link for your local time (Redirects to timeanddate.com) :
> http://bit.ly/247PwwT
> 
>
>