GSoC: Obexd Ideas

GSoC: Obexd Ideas

[dmp]

Hello BlueZ Community,

My name is Michal Poczwardowski[1], 22, Poland. I am interested in
taking part in this year's Google Summer of Code.

Idea[2] to implement MAP looks challenging. I have few questions. I've
read obexd code a bit, I understand that there is plugins/mas.c that
implements Massage Access Service and probably client/map.c that
handles client. Idea is assigned to obexd but it's already ready? And
the goal is to create some kind of C client application that could
communicate with server using client's api from obexd? I'll be really
happy if you answer and point me where I'm wrong.

Second interesting idea is "OBEX file system". There is a solution
called ObexFs[3]. I've been using it for few years. As far as I know
It's based on different obex implementation and it would be nice to
prepare obexd solution. Have some initial mentors been assigned to
obexd realated ideas?


[1] http://dmpgsoc.azalayah.net/
[2] http://www.bluez.org/development/gsoc/gsoc-ideas-list-2012/
[3] http://dev.zuckschwerdt.org/openobex/wiki/ObexFs

Thanks,
Michal

dmp@freenode

Re: GSoC: Obexd Ideas

[dmp]

Hello,

I've submitted proposal [1] for "OBEX Filesystem In Userspace". I'll
be grateful if someone could give me some comments. There are still
few days to improve.

[1] http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/dmp/44002

Thanks,
Michal

On 30 March 2012 02:55, dmp <dmp0x7c5@gmail.com> wrote:
> Hello BlueZ Community,
>
> My name is Michal Poczwardowski[1], 22, Poland. I am interested in
> taking part in this year's Google Summer of Code.
>
> Idea[2] to implement MAP looks challenging. I have few questions. I've
> read obexd code a bit, I understand that there is plugins/mas.c that
> implements Massage Access Service and probably client/map.c that
> handles client. Idea is assigned to obexd but it's already ready? And
> the goal is to create some kind of C client application that could
> communicate with server using client's api from obexd? I'll be really
> happy if you answer and point me where I'm wrong.
>
> Second interesting idea is "OBEX file system". There is a solution
> called ObexFs[3]. I've been using it for few years. As far as I know
> It's based on different obex implementation and it would be nice to
> prepare obexd solution. Have some initial mentors been assigned to
> obexd realated ideas?
>
>
> [1] http://dmpgsoc.azalayah.net/
> [2] http://www.bluez.org/development/gsoc/gsoc-ideas-list-2012/
> [3] http://dev.zuckschwerdt.org/openobex/wiki/ObexFs
>
> Thanks,
> Michal
>
> dmp@freenode

Re: GSoC: Obexd Ideas

[Bastien Nocera]

On Wed, 2012-04-04 at 16:38 +0200, dmp wrote:
> Hello,
> 
> I've submitted proposal [1] for "OBEX Filesystem In Userspace". I'll
> be grateful if someone could give me some comments. There are still
> few days to improve.
> 
> [1] http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/dmp/44002

FWIW, having written the ObexFTP gvfs backend twice already, that using
a D-Bus API is a bad idea. Instead, the code should use gobex directly.
It would make the code more robust, and easier to debug.

I'm happy doing code reviews, or answer gvfs specific questions if those
crop up during the SoC project.

Cheers

Re: GSoC: Obexd Ideas

[dmp]

Thanks for response.

Previous version of my proposal presented dbus implementation. As
vcgomes suggested yesterday during IRC conversation at #bluez-gsoc
I've already fixed my proposal and now it's prepared for gobex
library.

I plan to implement fuse based solution, but your experience with gvfs
might be helpful.

Thanks,
Michal


On 4 April 2012 17:24, Bastien Nocera <hadess@hadess.net> wrote:
> On Wed, 2012-04-04 at 16:38 +0200, dmp wrote:
>> Hello,
>>
>> I've submitted proposal [1] for "OBEX Filesystem In Userspace". I'll
>> be grateful if someone could give me some comments. There are still
>> few days to improve.
>>
>> [1] http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/dmp/44002
>
> FWIW, having written the ObexFTP gvfs backend twice already, that using
> a D-Bus API is a bad idea. Instead, the code should use gobex directly.
> It would make the code more robust, and easier to debug.
>
> I'm happy doing code reviews, or answer gvfs specific questions if those
> crop up during the SoC project.
>
> Cheers
>