[Ctk-developers] External projects in commontk github organization

[Sascha Zelzer]

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".

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/20110607/bd839d7b/attachment-0001.htm>