Re: MidCOM and its further adaption to new Midgard versions - AKA Midgard core quality

Dnia 08-02-2006, śro o godzinie 19:06 +0200, Jukka Zitting napisał(a):
> Hi,

Hi,

> I think a deeper issue here is the lack of any clear roadmap for 1.8
> and ahead to 2.0. Torben has already pointed out a number of issues
> related to the questions you posted, and quite often the answer to
> those issues has been either another question, a denial of the issue,
> a workaround, or a vague decision to change something. I'm not the
> least surprised that Torben is being frustrated.
>
Yes, exactly. Every new feature requires other three at least designed.
The topic like table sharing can not be summarized with OO concepts
because it doesn't explain anything.

I will write again ( with tables as example ). Such feature requires
database transaction. That we can get with libgda support which is
planned for 1.9. So automagically you can suppose that OO inheritance
with mutliple tables as storage can not be made for 1.8 and should be
implemented for 1.9 at least. But this raise up a topic like
'do we want multiple tables as object's storage?'.

I will ask a question for every question because I can not be the only
one who is responsible for midgard logic. It's not a matter if I can not
because I do not want, but there are too much traps for one man.

My vague decisions follows the fact that I want to have some release
cycle being made. I will ask a question ( again as answer for a
questions ). How many midgard developers are familiar with at least
Midgard 1.8alpha1 ? How many logical mistakes I made?

That's very good that we have more and more developers for MidCOM.
But you can not expect stable and logic core from one person. At least
not without testings.

> While there is always room for improvement in core development and
> documentation, I don't really think that this is the main issue here.
> Piotras is doing a great job given the structural constraints in
> place. The main issue is that nobody is actively taking care of the
> managerial and architectural issues in Midgard. There is no
> mentionable release plan even for 1.8, and no roadmap for things after
> that.

We still have legacy code.
Plan for 1.8 is very simple.
	* improved, faster and partially refactored core with QB
	* metadata for any midgard type
		Maybe I am the only one who heard that
		midcom's metadata is its killer?
	* Midgard Reflection
	* New Quota
	* New datatypes like ISO datetimes

And last ( but very not least). How to install midgard again?

How many midgard developers are actively interested in midgard being
installable? Keep in mind that making midgard being installed easily
and smooth requires much more time than developing new functionality
and features.

> There was great momentum for Midgard 2 a year ago when things like
> MgdSchema and the QB were being specified, but the situation has since
> deteriorated into the old pattern of programming by coincidence. For
> example, while the reflection work is definitely needed there has been
> no real spec for that nor has it been discussed how the reflection
> features fit in the big picture of Midgard 2.

Yes, first MgdSchema and QB implementation was done fast, but still keep
in mind these facts:

1.8 is going to be much better release than 1.7 because I spent enough
time to find all issues within new and old code.
I think we have old midgard pool ghost bug fixed and we made it for only
one release. Was it worth to be done?

Internal parts of QB was refactored. We didn't get new functionality but
we get faster QB.

New fatures like metadata are still not tested by developers so we can
quess only next release date.

The longer we delay 1.8 the longer we delay 1.9/2.0 development.

After 1.8 is out we can not focus on new functionalities but we have to
focus on writing database management with libgda and such small details
like database connection handler ( which should be written now ).

What we do now is not about "taking care of the managerial and
architectural issues in Midgard", it is about doing all the stuff which
is absolutely mandatory to be done.

What you would like to have if you could choose: either new OO midgard
connection handler ( even as wrapper now for midgard struct ) or some
new functionality in core?  I think that OO midgard connection handler
is the last thing left to make real midgard-java bindings. Am I right?

If I would like to make parser improvements right now , how should I do
it after style mRFC has been passed? How caching features similiar to
MMP should look like after this mRFC has been passed? Should I move it
to midgard-php or midgard-apache? How should looks like request
handling?

I asked these questions because no one focused on such "details" while
we voted for full rewrite of code in three midgard modules.

How should I know what should I propose for some new functionalities and
for any roadmap if I have no idea how basic and fundamental midgard
features should look like now?

And to sum up the roadmap for 1.8. I ( and I think I am not the only
one ) have only one target. Make midgard installable. Let's make it
first and later we can focus on other specs.

Piotras