KDEML workshop at aKademy 2005

[Frans Englich]

On Thursday 05 May 2005 07:16, Frans Englich wrote:
> On Thursday 05 May 2005 07:20, Eric Laffoon wrote:
> > On Wednesday 04 May 2005 09:36, Frans Englich wrote:
> > > On Wednesday 04 May 2005 15:39, Leo Savernik wrote:
> > > > Am Mittwoch, 4. Mai 2005 16:21 schrieb Allan Sandfeld Jensen:
[...]

> > At many points we have had to make design decisions based upon what is
> > available and what our objectives are. Often there are some very cool
> > things being developed in KDE that we would like to use, but we find that
> > the scope is not wide enough or there is some small factor indicating the
> > need to develop a tool or library ourselves. I realize there will be
> > factors where our developing some things completely may be indicated, but
> > in the area of the XML features you're talking about it would be vastly
> > preferable if we could insure that we could interact and use the great
> > tools being developed by other KDE developers.
> >
> > Because a lot of what we do is to work with both DOM and underlying
> > scripting some complications can be involved in our needs. However I'd
> > like to not only have our development teams meet at aKademy, I'd like to
> > have ongoing communication in these areas.
>
> [...]
>
> Then I say I can't agree more: full speed ahead.
>
> IIRC, the KDOM developers once thought about a "kxml-devel" mailing list to
> solve the problem that occur when generic XML-discussions takes place on
> ksvg-devel: only a few people notice it. However, IIRC, it was concluded it
> was not the right time..
>
> But now it is, perhaps?
>
> What I in more concrete terms suggests, is the creation of a new
> mailinglist "kxml-devel" whose scope is:
>
> * KDE & XML. While kfm-devel is for topics /only/ relevant for
> khtml/Konqueror, and quanta-devel only applies for Quanta(same for
> ksvg-devel), kxml-devel is for topics relevant for any project somehow
> involved in XML. Hence, a post on kxml-devel applies for KSVG2, KHTML, and
> Quanta, and so forth.
>
> * Compared to for instance kfm-devel and kde-core-devel, the roof is a bit
> higher in terms of on-topicness. That appears to be what's needed, and I
> also think the people involved can handle it..
>
> I think the list makes sense. The problems to be addressed are broad and
> vague; hence, the scope is equally undefined.
>
> What do people think?

Then I hope people will try to synchronize our development teams in other 
ways.


Cheers,

		Frans