[Ctk-developers] External projects in commontk github organization
Marco Nolden
m.nolden at dkfz-heidelberg.de
Wed Jun 8 07:59:45 EDT 2011
Hi,
I think inside of the CTK repository we should focus on technologies
that are standardized, like we currently do with DICOM Q/R and
application hosting. Having a MIDAS client is probably useful for a lot
of people, but I would prefer to put most of the client implementation
in the MIDAS repository and enable it as an (optional) external project
if we have a use case. Or MIDAS could enable CTK as a "binding" (sorry I
do not know enough about MIDAS) and provide a CTK plugin that could be
used by other CTK-based systems. I think this is the general idea of
having a component based approach and a plugin framework.
Marco
On 06/08/2011 11:00 AM, Sascha Zelzer wrote:
> 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
>>
>>
>
>
>
>
>
--
----------------------------------------------------------------------
Dipl.-Inform. Med. Marco Nolden
Deutsches Krebsforschungszentrum (German Cancer Research Center)
Div. Medical & Biological Informatics Tel: (+49) 6221-42 2325
Im Neuenheimer Feld 280 Fax: (+49) 6221-42 2345
D-69120 Heidelberg eMail: M.Nolden at dkfz.de
More information about the Ctk-developers
mailing list