[haiku-development] Re: Final Set*UIColor Patch, Version 3e

  • From: looncraz <looncraz@xxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 6 Dec 2015 17:32:24 -0600

On 12/6/2015 10:30, Axel Dörfler wrote:

1. Is DelayedMessage acceptable given my previous explanations?

I would say it's acceptable, but I don't think it should stay around, at least if we don't find some more use for it.

Okay, perfectly reasonable. I'll leave it, and I do suspect that there will be more use cases in the future. If not, then removing would probably make more sense and I'll ensure I am available to do that task should that decision be made.

The merge logic doesn't really belong where it is now, anyway, and I also don't really see where it would be needed.

Well, the alternative would involve callbacks, which I think is less elegant than an enum and uint32, but is probably the only route I could use on the client side. Right now, though, the only two modes I think that are now used are the simple-to-handle cancellation mode and the not-as-simple duplication mode, which is a unique situation which allows conflicting messages to both exist and be scheduled. The other alternative, which I don't think I am still using, is the replacement mode, where the new data replaces the existing data in the pending message.

There are only four logical types of merging:
DM_NO_MERGE
I don't care if there is a message with my code, schedule me anyway.

DM_MERGE_REPLACE
If another message with my code is pending, use my data instead of its data, but send at its original time.

DM_MERGE_CANCEL
I am not about to step on anyone's toes, so long as I get called, I don't care, so cancel me.

DM_MERGE_DUPLICATES
You can cancel me IF I exactly match the pending message, otherwise we both need to be sent.

The callback would need to expose the pending message data so it can be modified. On the client side, this would just be a BMessage, on the server-side this is a list of data attachments.

So, on the client side, we could have a callback with form such as:

bool MessageConflictCallback(BMessage& scheduled, const BMessage& conflicting);

Returning true will have the new message scheduled, false will have it canceled. This is not as efficient as DelayedMessage, but is probably the only route that would work on the client side safely beyond duplicating the very system you dislike so much ;-)

This would absolutely be required for DelayedInvalidate to work properly, for example, otherwise we'll end up with messaging feedback storms.


3. Should BColorMap remain?
4. If not, what is the alternative? I see few worthwhile options (see $6)
5. If BColorMap should remain, should it remain a part of the public API?
6. Should BMessage get Add/SetColor(color_which, rgb_color) methods?

Depends on how much time you want to spend on your patch before committing it ;-)

Well, answers that ;-). BColorMap should certainly be private. Making that change isn't entirely trivial, but it is certainly much less trivial than getting rid of it entirely.


8. If I were to implement client-side delayed messaging, what form would
be best?
- BMessenger::SendAtTime(), seems reasonable, but what about merging
messages?

If you *really* need merging, I would totally understand it, if you wouldn't use a system provided mechanism for that :-)

To me, obviously, it seems like something the system itself should be able to handle. There are only four possible scenarios as to how the conflict could be handled.


Sorry, I can understand your frustration, but I only have so much time, too. And we already wasted a lot of time with stupid fights.


Thanks for taking the time to respond, it's the fact that I've actually had to do quite a bit of guessing at what you actually wanted that is frustrating, and I don't always guess right which causes me to have to do redo or undo things I've done. Your responses in this message makes it quite clear what I need to change in this patch, and I appreciate that immensely.

I have a todo list now, and it looks like I'll have more than enough time to finish that list this week, so I'll probably spend some time experimenting with client side delayed messaging that doesn't rely on any server (will have to use the BApplication looper).

--The loon

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 12-2015