> As for Put-Delete, it may be possible to realize that as event
> OBEX_EV_BODYMISSING or command OBEX_CMD_DELETE.

The OBEX_CMD_DELETE seems more useful. However, since all packets would need to be read before the operation can be determined to be a Put-Delete, I assume this would be a special command that is only sent for OBEX_EV_REQ and OBEX_EV_REQDONE events, and would appear as an OBEX_CMD_PUT when the OBEX_EV_REQHINT and OBEX_EV_REQCHECK events arrive. This change in commands could be quite confusing.

If there were flags that were set during the parsing of the headers, the programmer could check these flags at the end of the Put operation. For example, there could be flags like this:

    #define OBEX_FL_PUT_NO_BODY
    #define OBEX_FL_PUT_EMPTY_BODY        /* not really necessary, just for consistency */
    #define OBEX_FL_PUT_NO_BODY_END
    #define OBEX_FL_PUT_EMPTY_BODY_END

And when an OBEX_EV_REQ is received for a Put operation, the programmer can check the flags that have been or'd together by calling OBEX_ObjectGetPutFlags(). I think this would be more specific and easier to handle than handling extra events such as OBEX_EV_BODYMISSING.


> That makes the Create-Empty pretty easy to implement on both client and server
> without any(?) changes (don't check the length, though).

Do you mean it can be implemented by checking that a Put did not contain any body data? I understand it can be implemented that way, but if the body data is of zero length, I can't distinguish between an operation that did not contain any body headers (Delete) and an operation that had an empty end-of-body header and no body header (Create).

Bea