Hi Malte and Kay,
i will also answer Kay's reply here, he was just asking for the amount
of work, too...
Malte Timmermann wrote:
I also prefer making binfilters completely independent from any other
OOo code.
Constrain is to keep it as small as possible.
It might be difficult to duplicate ( or better get rid of) VCL.
Right, it will not be easy.
In theory, only font and output device code should be in use if you can
really throw away everything not needed for a filter.
For a converter even that should not be needed, because there shouldn't
be any layout calculation.
But to get all of that done, you need more than one person, or a lot
more time than you estimate.
I do not think so. All estimations can only be guesses, but i would just
do a methodical approach:
(a) do not link against other C++ modules
(b) look at the unresolved externals
(c) take one block
(c1) check if it's needed at all or the usages may be stripped
(c2) reduce to the needed, add to binfilter
(d) repeat
This will allow the task to be done from someone extern who does not
know too much about the modules. We had some ressources for something
like that at that time.
Maybe there are even 'tricks' someone can use who has deep experience
with linking processes. At a minimum approach, it would also be okay to
do something like linking binfilter statically against the modules of
the release version we keep it at. This may produce something like a
binfilterstatic680mi.dll containing all the static linkages without
copying any code to binfilter. Maybe we should investigate in that
direction, we need someone with experience in that field.
Even with the first methodical approach i think a good engineer - with
build boxes like Pavel has one - may handle that task in 3-6 months.
And my suggestion would be to start with throwing away all unused code
in binfilters, to avoid unnecessary dependencies.
That's where amout of work was already put and would be goot to put
more, but since this is th task You need experienced engineers for, it
was seen as expensive, and i agree.
This is IMHO not the job for one person alone, but for one person of
each application who knows what can be removed.
Probably also someone for DrawingEngine code - hey, that IMHO would be
you ;)
Yes, if we decide to do it that way. I was already commited to do
something like that years ago to prevent those man-years of work for
others and i am still.
We just need to evaluate if there is not a methodical approach which can
be handled by someone not deeply involved. If You ask me, this is
possible. We just would need ressources to throw on it, and from my
point of view they could do it methodically (we need to define that,
though) without deep module knowledge.
Ongoing changes in the DrawingLayer OTOH REQIRE that knowledge and can
not be done methodically from someone else.
We just need to weight the costs, real and implied ones...
Malte.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
