[interfacekit] Re: BSession(NG)


Hi!

[Axel, Marcus, Ingo, Marc, DW, Stefano, you don't have anything to say?]
Erik, Gabe?


Pahtz wrote:
Also, never split the message into two port calls.
No. I'm sorry, I will never agree with you on this one! 
If you don't split the message you don't need the packetlist BList structure, 
and the code is much
simpler because you don't need to re-assemble the message or use multiple 
buffers.

        Ufff... you are killing me! :-)
        Have you seen an older version of PortLink?

In BSessionNG::WriteData(), the call is not re-startable because the client 
doesn't know how much
data was sent or left behind.

        This is easy doable:
        status_t EndWriteMessage(ssize_t *bytesWritten = NULL);

I prefer atomic API calls - either it worked completely, or it
didn't at all.
The return value of EndWriteMessage() says that.

But it really doesn't matter since we would abandon the session completely. 
        Interesting... maybe we should provide a
        ::SetPorts(sendPort, rcvPort) method.

However, if the client decides to abort during building the message there is no 
going back because
the half built message may have already been sent. BSessionNG called 
PrivateSync() behind our
back.
So what? It's his fault if this happens. There are lot of systems which depend on the Begin() End() paradigm.

On the receiving end, StartReadMessage() calls EnsureComplete() so there is no 
advantage in
sending half the beginning of a message because it still waits for the complete 
message. Infact,
it would mean two read_port() calls instead of one.
YES, it is! It returns B_OK if the message is complete. If it's complete you can be sure no errors will occur when calling ReadData() - of course if you are reading what you should. This means that in principle you can do ReadData() without checking for errors, a bless if you ask me for app_server development.
Have you seen main.cpp for a "tutorial" on how to be used?

There is something that it should be added: a GetRcvStatus() which will be of much help if a message was badly handled. yes...

Also the user of the class has to try and decide what is the optimal buffer 
size to avoid
excessive fragmentation but not waste memory. This is hard to guess.

        Wasn't hard for us! 1024 for BSession, 4096 for PortLink.
        With proper documentation this isn't hard at all.

There is the advantage of not having a maximum message size limited by the 
kernel port
implementation, but we were actually optimizing for small messages. Also on 
receiving,
EnsureCompleteMessage() allocates memory for the full message so limits should 
be enforced
somewhere.
I do not agree.

ReadData() and WriteData() would have been simple pointer maths and a memcpy(), 
but now it's a
while loop with 'slot' management or write_port() inside. I was just going to 
steal the code from
PortMessage/PortLink.
I think you need to read a debate that took place on this list about variable PortLink message length! Go to FreeList's archives.
[ variable message length requires a lot of malloc/free operations ]

If you consider adding DetachCurrent(PortMesssage *) or DetachCurrent(BMessage 
*) you will realise
you again it would be simpler without multiple buffer slots to memcpy() or 
Unflatten() from.
Be more specific.

One way around it is to declare the size of the complete incoming multipart 
message so you can
pre-allocate a right-sized buffer. But with partial messages being 
PrivateSync()'ed out before
EndWriteMessage() you can't.
But then the "dynamic" part would be on the 'send' side. At least in this case, on a side (send) a buffer is allocated only once.

BMessage was never on my "supported features list". I see no reason to add 
BMessage support.
I must repeat myself: This is not a general purpose messaging system! This is 
used internaly by


the Interface Kit. It covers our needs. I *do not* want to make this a BIG 
messaging system for
everyone to use it; BMessage/BLooper system is EXCELENT! I want to keep 
BSessionNG at its
simpliest form with all necesities that app_server team needs to have its work 
done.


I agree, no bloat. However, I don't understand how BMessage::ConvertToMessage() will be used.
Where have you seen that method? :-|

There is a lot of SESSION to BMessage conversion in the interfacekit.
:-)) No no no... BWindow::ConvertToMessage() will be left empty. I know you are confused. When I wrote BWindow I was in my beginnings with my app_server/BWindow talents. :-)) I made a mistake with that method, and because I didn't need it lately(half year or more) I haven't modified it. I will, very soon, because *very* soon I will start making BWindow's methods work. app_server has come a long way and there are lots of things working, now the client side needs a touch. :-)
Now, back to our problem... :-)
BWindow looper *only* receives BMessages! BSession(NG) is/will be used *only* to send data to app_server( and receive replies when data is needed - sync). So you see... BLooper/BMessage and BSession(NG) don't have anything to do with each other.

So I'm wondering can we
reduce it?
:-) Sure! We can nullify it! :-DD

Perhaps at some point we want to send a BMessage over the same port? Or forward 
a
BMessage? I don't know yet.

        You can't Flatten() send, receive and Unflatten()? :-)
        But as I said the two serve different purposes.


Adi.



---------------------------------------------------------------
Lucram pentru tine. Analizam. Cautam zilnic.
Alegem ceea ce te intereseaza. Te anuntam.
http://www.REDUCERI.ro/


Other related posts: