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

List:       kde-devel
Subject:    Re: Storing data
From:       Vishesh Handa <handa.vish () gmail ! com>
Date:       2011-06-24 13:53:16
Message-ID: BANLkTi=z4qNOmnD4_zZzEX1XvrKM1Q=Sgg () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Fri, Jun 24, 2011 at 7:07 PM, Nathan Bradshaw
<nathanlbradshaw@gmail.com>wrote:

> On Thu, Jun 23, 2011 at 5:51 PM, Thomas Lübking <thomas.luebking@gmail.com
> > wrote:
>
>> Am Thursday 23 June 2011 schrieb Steven Sroka:
>> > What is the best way for a KDE program to store data? Not passwords or
>> > anything sensitive, but data a user had typed into text fields.
>> >
>> > Some sort of database. Something along the lines of KConfig or KConfig
>> > XT but for raw data not configuartion data for programs.
>> Depends on the type of data and what you want to do with it.
>>
>> If you want to "dump memory", you need to serialize the data.
>> Have a look at QDataStream.
>>
>> KSharedDataCache helps to to access information from several processes at
>> the
>> same time (like eg. the icons) and save memory.
>>
>> Also you can write it to some xml or an kconfig/qsettings ini-a-like file
>> with
>> the advance of "less" access ;-)
>>
>
> Is RDF through Soprano an option here?
>

Yes. But you don't really want to another another virtuoso instance. You
could use another backend though.

If you can structure the data properly, you could store it in Nepomuk's
virtuoso repository.


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


-- 
Vishesh Handa

[Attachment #5 (text/html)]

<br><br><div class="gmail_quote">On Fri, Jun 24, 2011 at 7:07 PM, Nathan Bradshaw \
<span dir="ltr">&lt;<a \
href="mailto:nathanlbradshaw@gmail.com">nathanlbradshaw@gmail.com</a>&gt;</span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> <div class="im"><div class="gmail_quote">On Thu, Jun \
23, 2011 at 5:51 PM, Thomas Lübking <span dir="ltr">&lt;<a \
href="mailto:thomas.luebking@gmail.com" \
target="_blank">thomas.luebking@gmail.com</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">

Am Thursday 23 June 2011 schrieb Steven Sroka:<br>
<div>&gt; What is the best way for a KDE program to store data? Not passwords or<br>
&gt; anything sensitive, but data a user had typed into text fields.<br>
&gt;<br>
&gt; Some sort of database. Something along the lines of KConfig or KConfig<br>
&gt; XT but for raw data not configuartion data for programs.<br>
</div>Depends on the type of data and what you want to do with it.<br>
<br>
If you want to &quot;dump memory&quot;, you need to serialize the data.<br>
Have a look at QDataStream.<br>
<br>
KSharedDataCache helps to to access information from several processes at the<br>
same time (like eg. the icons) and save memory.<br>
<br>
Also you can write it to some xml or an kconfig/qsettings ini-a-like file with<br>
the advance of &quot;less&quot; access ;-)<br></blockquote></div><br></div>Is RDF \
through Soprano an option here?<br></blockquote><div><br>Yes. But you don&#39;t \
really want to another another virtuoso instance. You could use another backend \
though.<br> <br>If you can structure the data properly, you could store it in \
Nepomuk&#39;s virtuoso repository.<br><br></div><blockquote class="gmail_quote" \
style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); \
padding-left: 1ex;"> <br>
<br><br>
&gt;&gt; Visit <a href="http://mail.kde.org/mailman/listinfo/kde-devel#unsub" \
target="_blank">http://mail.kde.org/mailman/listinfo/kde-devel#unsub</a> to \
unsubscribe &lt;&lt;<br> <br></blockquote></div><br><br clear="all"><br>-- <br><font \
color="#999999">Vishesh Handa</font><br>



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


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

Configure | About | News | Add a list | Sponsored by KoreLogic