[Ctk-developers] External projects in commontk github organization
Sascha Zelzer
s.zelzer at dkfz-heidelberg.de
Wed Jun 8 05:00:26 EDT 2011
I forward the mail from Zach to ctk-developers, since it does not seem
to arrive there.
-------- Original Message --------
Subject: Re: [Ctk-developers] External projects in commontk github
organization
Date: Tue, 7 Jun 2011 16:35:28 +0200
From: Zach Mullen <zach.mullen at kitware.com>
To: Zelzer, Sascha <s.zelzer at Dkfz-Heidelberg.de>
CC: Julien Finet <julien.finet at kitware.com>, Jean-Christophe
Fillion-Robin <jchris.fillionr at kitware.com>,
"ctk-developers at commontk.org" <ctk-developers at commontk.org>
On Tue, Jun 7, 2011 at 10:05 AM, Sascha Zelzer
<s.zelzer at dkfz-heidelberg.de <mailto:s.zelzer at dkfz-heidelberg.de>> wrote:
Hi,
naming issues aside, I tend to agree with Julien here.
Generally, I am of course in favor of extending CTK with useful
functionality. However, here is a short anecdote: Ivo and I recently
got a request from German group if we think their project would be a
good fit for CTK. Although it looked very promising, well
engineered, and was in the scope of CTK, we expressed our concerns
because the project was not Qt-ified at all and would somehow break
the consistent code style we have now in CTK. I see the same issue
with the current MIDAS code. In the past, I would have voted for
including MIDAScpp as an external project, as we did with all
existing projects we wanted to use but did not comply with the CTK
style.
I do not want to slow people down or to damp their enthusiasm. I am
just concerned that CTK becomes a Zoo of libraries with inconsistent
"Look and Feel".
Hi Sascha,
Part of the original motivation for moving MIDAScpp into CTK was to
bring it up to the standards of organization and style that CTK uses. I
will be heavily maintaining this part of the project, and the effort to
make MIDAScpp conform to CTK standards will be ongoing.
For now, I will work to remove the KWSys and expat dependencies and
replace them with Qt functionality before we merge this code. I will
also look into replacing curl with the QtNetwork module.
-Zach
Maybe an open discussion about integrating larger pieces of software
*in advance* of starting the effort would be helpful in the future.
I am still thinking about your naming suggestions... ;-)
Best,
Sascha
On 06/07/2011 03:25 PM, Julien Finet wrote:
> For the naming convention, is "MIDAScpp" mandatory? couldn't it be
> just MIDAS (and be externally refered as CTK MIDAS).
> By having MIDAS into CTK, we infer it is C++ and Qt based.
> My 2 cts,
> Julien.
>
> On Tue, Jun 7, 2011 at 9:19 AM, Jean-Christophe Fillion-Robin
> <jchris.fillionr at kitware.com <mailto:jchris.fillionr at kitware.com>>
> wrote:
>
> Hi Sasha,
>
> You bring a very good point !
>
> The work related to these projects has just been published and
> is open to review.
> See
> https://github.com/zachmullen/CTK/commit/1051813f5046bb08835b73a12138a672c9c48c82
>
> Expat, KWSys, Sqlite and libcurl were initially shipped with
> MIDAScpp library ... I advocates to externalize and CMake-ifie
> properly these libraries as a first step. That way the code
> checked in CTK would "really" corresponds to the library itself.
>
> Having an other perspective is always fruitful :) You are
> right, since MIDAScpp would be part of CTK, it makes sens to
> not depend on these external project and rely on Qt directly.
> Qt is a mandatory dependency after all.
>
> I am cc'ing Zach in the email and I am sure I will be able to
> provide more comments.
>
> Zach> Instead of using expat, libcurl, sqlite and kwsys, would
> it make sens to depends on Qt ?
>
> In the mean time, I have the following questions:
>
> - Currently the library is named "CTKMIDAScppCore" and
> CTKMIDAScppWidgets", I was thinking we could have something
> like CTKDataManagementMIDAScppCore and
> CTKDataManagementMIDAScppWidgets.
> What do you think ? Doing so would leave room to library like
> "CTKDataManagementHadoopCore" ...
>
> - Does introducing a "DataManagement" hierachy of libraries
> make sens ? As far as I am concerned, I think it's important
> to provide both functionality to process, store and retrieve
> the data.
>
> Thanks
> Jc
>
>
>
> On Tue, Jun 7, 2011 at 1:48 AM, Sascha Zelzer
> <s.zelzer at dkfz-heidelberg.de
> <mailto:s.zelzer at dkfz-heidelberg.de>> wrote:
>
> Hi guys,
>
> Recently, I observed an explosion in the number of
> repositories containing external repositories in the
> CommonTK organization of github. Could we discuss the need
> of some of them, and maybe have these discussions in the
> future in advance of pushing those projects?
>
> I am looking especially at the projects below, where Qt
> might already offer enough functionality. Of course I
> could be wrong, so thank you for your feedback!
>
> - sqlite (why not use the Qt sqlite wrapper?)
> - KWSys (where is it needed? I did not find any reference
> to it in CTK)
> - libexpat (Qt also provides a streaming XML API, also not
> used anywhere)
> - libcurl (there is also no reference to libcurl in CTK)
>
>
> Thanks,
>
> Sascha
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> <mailto:Ctk-developers at commontk.org>
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>
>
>
> --
> +1 919 869 8849 <tel:%2B1%20919%20869%208849>
>
>
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org <mailto:Ctk-developers at commontk.org>
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20110608/0de51c9e/attachment.html>
More information about the Ctk-developers
mailing list