--===============8656920855703672295== Content-Type: multipart/alternative; boundary=001a11c3f924d4f4c704f127f12a --001a11c3f924d4f4c704f127f12a Content-Type: text/plain; charset=ISO-8859-1 Hi David, Thank you :) On Wed, Jan 29, 2014 at 7:21 PM, David Narvaez wrote: > On Tue, Jan 28, 2014 at 9:21 PM, Vijay Dhameliya > wrote: > > Hi Albert, > > > > Replacing file system by database not only reduce loading time and files > > from source code but it will provide scope to feature like adding, > editing, > > and removing DSOs (deep sky objects) and other similar sky-objects. > > I haven't used KStars but I don't see how is editing impossible using > the right set of widgets. After all, regardless of whether you load > the data from a file or a DB, you end up with a model and I guess you > can put whatever visualization is needed on top of that to have an > editor. > Actually when we store different data-field of skyobject in file, the code become messy for editing and deleting this data from file. But if we have database then select, update and remove query makes our job simple. Of-course this is not adequate reason to replace whole file system with database ;-) > > > And if we have database system in KStars then maintaining user's logs and > > storing downloaded images will become more reliable and systematic. > > > > And KStars allows user to add their own catalog which may contain any > number > > of DSOs (i.e. raws for database or line in file). So when talking about > such > > large data, loading time will be reduced significantly. > > I guess Albert's question is if you have numbes to back that claim. > "Significantly" doesn't have much meaning if you want others to buy in > to your suggested change. One way of getting those numbers is to > implement your changes in a separate branch and then use profilingn > tools that will show exactly how much time is reduced, etc. If you go > down that path I would recommed getting a hold of Milian Wolff who has > done a lot of profiling for KDevelop[0] and other KDE projects. Otoh, > not everything is measured in bytes and seconds, and if these changes > improve code quality, that is another dimension to consider, but > again, that is easier to see once the changes are implemented in their > own branch. > Thank you very much for giving idea to measure the change that database implementation can bring. I shall soon get my hands on the same. > > David E. Narvaez > > [0] http://milianw.de/blog/katekdevelop-sprint-vienna-2012-take-1 > _______________________________________________ > kde-edu mailing list > kde-edu@mail.kde.org > https://mail.kde.org/mailman/listinfo/kde-edu > --001a11c3f924d4f4c704f127f12a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi David,

Thank you :)

<= div class=3D"gmail_quote">On Wed, Jan 29, 2014 at 7:21 PM, David Narvaez <david.narvaez@computer.org> wrote:
On Tue, Jan 28, 2014 at 9:= 21 PM, Vijay Dhameliya
<vijay.atwork13@gmail.com> wrote:
> Hi Albert,
>
> Replacing file system by database not only reduce loading time and fil= es
> from source code but it will provide scope to feature like adding, edi= ting,
> and removing DSOs (deep sky objects) and other similar sky-objects.
I haven't used KStars but I don't see how is editing impossib= le using
the right set of widgets. After all, regardless of whether you load
the data from a file or a DB, you end up with a model and I guess you
can put whatever visualization is needed on top of that to have an
editor.


> And if we have database system in KStars then maintaining user's l= ogs and
> storing downloaded images will become more reliable and systematic. >
> And KStars allows user to add their own catalog which may contain any = number
> of DSOs (i.e. raws for database or line in file). So when talking abou= t such
> large data, loading time will be reduced significantly.

I guess Albert's question is if you have numbes to back that clai= m.
"Significantly" doesn't have much meaning if you want others = to buy in
to your suggested change. One way of getting those numbers is to
implement your changes in a separate branch and then use profilingn
tools that will show exactly how much time is reduced, etc. If you go
down that path I would recommed getting a hold of Milian Wolff who has
done a lot of profiling for KDevelop[0] and other KDE projects. Otoh,
not everything is measured in bytes and seconds, and if these changes
improve code quality, that is another dimension to consider, but
again, that is easier to see once the changes are implemented in their
own branch.

Thank you very much for giv= ing idea to measure the change that database implementation can bring. I sh= all soon get my hands on the same.

David E. Narvaez

[0] http://milianw.de/blog/katekdevelop-sprint-vienna-2012= -take-1
___________________________________= ____________
kde-edu mailing list
kde-edu@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-edu

--001a11c3f924d4f4c704f127f12a-- --===============8656920855703672295== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kde-edu mailing list kde-edu@mail.kde.org https://mail.kde.org/mailman/listinfo/kde-edu --===============8656920855703672295==--