Closed Bug 794469 Opened 9 years ago Closed 9 years ago

[b2g-bluetooth] Basic OBEX functions and implement sending "Connect" request

Categories

(Core :: DOM: Device Interfaces, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla18
blocking-basecamp +

People

(Reporter: echou, Assigned: echou)

References

Details

(Whiteboard: [LOE:S])

Attachments

(2 files, 3 obsolete files)

Object Push Profile is based on OBEX protocol message communication. We need basic functions to construct an OBEX message and handle received messages. 

"Connect" is one of OBEX operations, we send "Connect" request to remote device trying to establish an OPP connection over RFCOMM session.
Assignee: nobody → echou
Blocks: 792823
blocking-basecamp: --- → ?
Whiteboard: [LOE:S]
In OPP, we often send known length byte stream to remote, therefore it would be more convenient for us to have a ctor like this.
Attachment #664959 - Flags: review?(kyle)
Blocks: 792683
No longer blocks: 792823
Depends on: 792823
Attachment #664964 - Flags: review?(kyle)
blocking-basecamp: ? → +
Comment on attachment 664959 [details] [diff] [review]
patch 1: add a ctor to UnixSocketRawData

Review of attachment 664959 [details] [diff] [review]:
-----------------------------------------------------------------

::: ipc/unixsocket/UnixSocket.h
@@ +54,5 @@
> +  UnixSocketRawData(const uint8_t* aData, int aSize) :
> +    mSize(aSize),
> +    mCurrentWriteOffset(0)
> +  {
> +    memcpy(mData, aData, aSize);

And if aSize > MAX_DATA_SIZE?

BTW, know that MAX_DATA_SIZE is mutable for our needs. I have /no/ idea what the packet size for file transfer should be. So if we need to change it, we can.
Attachment #664959 - Flags: review?(kyle) → review-
Comment on attachment 664960 [details] [diff] [review]
patch 2: v1: OBEX related constants, data structures and basic functions

Review of attachment 664960 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/bluetooth/ObexBase.h
@@ +103,5 @@
> +class ObexHeader {
> +public:
> +  ObexHeader(ObexHeaderId aId,
> +             int aDataLength,
> +             uint8_t* aData) : mId(aId)

Nit - : should go on the next line I think? I'm not actually sure about style here.

@@ +120,5 @@
> +  }
> +
> +  ObexHeaderId mId;
> +  int mDataLength;
> +  uint8_t* mData;

nsAutoPtr will automate the cleanup for you, but I suppose this works too.

@@ +126,5 @@
> +
> +class ObexHeaderSet {
> +public:
> +  uint8_t mOpcode;
> +  ObexHeader* mHeaders[10];

Why not nsTArray< nsAutoPtr<ObexHeader> >? Seems like that'd keep you from having to deal with cleanup, size restraints, etc...

@@ +143,5 @@
> +  }
> +
> +  void AddHeader(ObexHeader* aHeader)
> +  {
> +    mHeaders[mCount++] = aHeader;

No check for mCount > 10?
Attachment #664960 - Flags: review?(kyle) → review-
Attachment #664964 - Flags: review?(kyle) → review+
Fixed problems commented by qdot.
Attachment #664959 - Attachment is obsolete: true
Attachment #664960 - Attachment is obsolete: true
Attachment #665487 - Flags: review?(kyle)
Attachment #664964 - Attachment is obsolete: true
Attachment #665487 - Flags: review?(kyle) → review+
https://hg.mozilla.org/mozilla-central/rev/9386cf1dbde2
https://hg.mozilla.org/mozilla-central/rev/3642f3259be6
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
You need to log in before you can comment on or make changes to this bug.