On 1/18/07, Hendrik Sattler <[EMAIL PROTECTED]> wrote:
>
> Is that really necessary as special case? An empty EOB header should result in
> a body of length 0. You create() a file, write() 0 bytes and close() it. This
> is a normal put, isn't it?
> Removing any checks about length==0 should let that through. The application
> author needs no special knowledge, then.
Yes, an empty EOB header does have a Body of length 0 -- but an
omission of the EOB header (i.e. a Delete request) would also result
in a body of length 0. So the flags check is to distinguish between a
Delete and a Create (i.e. between having a length==0 and having no
data at all).
Or, maybe what you mean is that you only need to figure out if it's a
Delete, and you don't need to worry about distinguishing between a
Create and a normal Put. I'd agree with that -- I only make this
distinction because the specs specifically define a "Create" operation
as opposed to an ordinary Put operation. But yeah, it doesn't seem
particularly useful for an actual application.
> Something equal goes for the a DELETE. Handling this in OBEX_EV_REQ is much
> too late if you use the streaming mechanism. There, you open the file in
> OBEX_EV_REQCHECK (that's where the other headers appear), so your flag must
> be present at that time, already.
> But if you do that, you could use a new OBEX_CMD_DELETE instead and thus avoid
> any new methods.
I totally agree that it's very late to check for a DELETE in the
OBEX_EV_REQCHECK, and it would be great to have a new command
OBEX_CMD_DELETE. However, the problem is that there is no way of
knowing that a Put operation is actually a "Delete" operation until
the request header data has been processed (i.e. you have determined
there are no Body or EOB headers).
So, when a server receives a Delete request, it will immediately see
the PUT command and pass OBEX_CMD_PUT to the programmer as the command
for the REQHINT event. It can then process the header data and
determine that it is actually a Delete, but it seems strange for the
server to pass OBEX_CMD_PUT as the command for the initial
OBEX_EV_REQHINT and then change to passing an OBEX_CMD_PUT for the
later OBEX_EV_REQCHECK and OBEX_EV_REQ events.
Also, if the client takes more than one packet to send all its
headers, the server cannot tell whether it is a Delete operation until
all request packets have been received (i.e. until OBEX_EV_REQ) and it
can determine that no Body or EOB headers have been received.
> naming the flag to what it means (not what it represents) is usually better,
> thus OBEX_FL_PUT_DELETE. I would still vote for an OBEX_CMD_DELETE, though,
> and omitting the OBEX_CMD_PUT, if possible.
>
That's true, a OBEX_FL_PUT_DELETE flag would be better, since the
programmer's probably more interested in the fact that there's a
Delete operation than the fact that particular headers are empty or
missing. I was assuming that this information might be useful during
the middle packets (when it hasn't been determined whether it's a
delete operation) but it's probably not that useful to the programmer,
really.
So, what if the patch allows for something like this instead, in the
user event callback function?
case OBEX_EV_REQ:
if (obex_cmd == OBEX_CMD_PUT) {
int putFlags = OBEX_ObjectGetPutFlags(obj);
if (putFlags & OBEX_FL_PUT_DELETE) {
// it's a delete
} else {
// it's an ordinary put request, or a "create" if no
body data has been received
}
}
Perhaps OBEX_ObjectGetPutFlags() should be
OBEX_ObjectGetRequestFlags() instead, so that it's more generic in
case other request flags are added in the future.
Regards,
Bea
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Openobex-users mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/openobex-users
