[Rpm-maint] FSM hooks for rpm plugin
Reshetova, Elena
elena.reshetova at intel.com
Tue Feb 5 10:59:09 UTC 2013
Hi,
Here is the new version attached. The reason I didn't attach it in the last
email was because I couldn't rearrange the " this particular jungle " in any
reasonable way and was still wondering what to do with it :)
But I will wait for you now to brush it first!
I am leaving this peace untouched from previous version, but other places are
adjusted as discussed.
Best Regards,
Elena
-----Original Message-----
From: Panu Matilainen [mailto:pmatilai at laiskiainen.org]
Sent: Monday, February 04, 2013 3:42 PM
To: Reshetova, Elena
Cc: rpm-maint at lists.rpm.org
Subject: Re: [Rpm-maint] FSM hooks for rpm plugin
On 02/04/2013 02:18 PM, Reshetova, Elena wrote:
> Hi,
>
>
>> I've started to wonder about the hook names though: "open" and "close"
>> seem out of place especially here (and to lesser degree elsewhere).
>> Perhaps these hooks should simply follow the pre/post pattern even in
>> the names, ie FILE_PRE and FILE_POST. I think it'd be more
>> descriptive wrt what they actually do, and leave open and close free
>> for possible later use for the cases where a kind of open+close
>> (files from payload
>> stream) is actually occurring.
>
> Sure, this is an easy change and I just did it. But the one below has
> made me a headache :(
>
>> This gets quite ugly indeed, better refactor the surrounding code
>> (which is ugly in itself) to allow for nice clean pairing. Oh and
>> btw, this version of the patch introduces a new asymmetry case: if
>> the open-hook fails, close-hook wont get called. It'll need something
>> like open-hook just flagging postpone
>>> without terminating the loop, and adjusting the rest of the code to
>>> deal
>> with it. I'll have a look at this, how hard can it be ;)
>
> I have written and rewritten now this part and still it looks ugly or
> even worse :( Flagging postpone is actually easy as well as not
> breaking out of loop in the beginning, but the early return is a small
> nightmare. If you introduce a variable tracking this, smth like
> "hardbreak" and setting it at that point, then you have a number of
> stupid if() causes, which make the whole constructions completely
> unreadable in addition to handling postpone and rc status (I have to
> walk thought this with pen and big white sheet to track the cases).
> Other option is "goto xyz" to bypass this.... but I am not sure this is any
> better, but might be easier to read. What do you think is better?
I meant that I'll have a look at streamlining this particular jungle first in
a way that (hopefully) makes adding the hooks easy or at least easier. There
are all sorts of suspicious spots in there...
> I have also fixed the other two issues you pointed in the other email.
Ok, good... but the patch seems to be missing from your mail :)
- Panu -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Adding-FSM-file-hooks.patch
Type: application/octet-stream
Size: 11175 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20130205/f9e621ed/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7220 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20130205/f9e621ed/attachment-0001.p7s>
More information about the Rpm-maint
mailing list