Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000495 [obex-data-server] General major N/A 2010-11-01 10:11 2010-11-09 12:09
Reporter nami View Status public  
Assigned To
Priority normal Resolution open  
Status new   Product Version
Summary 0000495: Are you interested in OBEX14?
Description hi, all, since OBEX14 has released for a long time, I`d like to port it on ods. What do you think about it? If you are interested in it, I will submit a serial of OBEX patches ,including obex over l2cap and SRM.
As ods is closely related to blueman and openobex, the modification will inevitably include blueman and openobex changes. Should I submit patches in a branch? Please kindly give me your any suggestion. Thanks.
Additional Information
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0001404)
skirsdeda (administrator)
2010-11-01 15:51

Yes, of course! This would mostly involve some work with low-level stuff and should be incorporated into openobex. Any changes to ods and blueman are also very welcome.
Since this would involve quite a lot of changes, branching out would probably make more sense than sending a load of patches. openobex, ods and blueman all have their own version control in different places, it would be easier to make new branches in one place (like gitorious.org or github.com).
(0001406)
nami (reporter)
2010-11-03 08:23
edited on: 2010-11-03 08:39

I`ve created 3 repositories in github.com:
git://github.com/namili/blueman.git [^]
git://github.com/namili/obex-data-server.git [^]
git://github.com/namili/openobex.git [^]

The 3 modified projects are based on some older version. They can be built and run well.Currently support obex over l2cap and SRM.
I`ll port them on current version later.
Please kindly let me know if you have any question. Thank.

(0001407)
skirsdeda (administrator)
2010-11-05 11:44

There's one very important thing. While we are introducing new features, we should try our best not to break API (both openobex and obex-data-server). For example ods_manager_create_bluetooth_server has new arg in your repo: obex_over_l2cap. Is this the only way? Maybe we could make a well educated guess whether user wants to use obex over l2cap?
I haven't read new obex spec yet cause I don't have access to irda pages. So far my only concern is seamless compatibility...
(0001410)
nami (reporter)
2010-11-09 11:42

My brach is compatible with GOEP v1.x, which means obex over rfcomm, so I add new args in some functions. Well, I think maybe we can introduce new features by adding new functions if we request backwards compatibility. What do you think so?
Do we request backwards compatibility? If so, we need to create two sockets for every service, the obex server must listen on both rfcomm socket and l2cap socket. And we will need new property to know client is connected to which socket.
(0001411)
skirsdeda (administrator)
2010-11-09 11:46

Yes, we definitely need backwards compatibility.
(0001412)
nami (reporter)
2010-11-09 11:51

So seamless compatibility can only be achieved by adding new functions?
(0001413)
skirsdeda (administrator)
2010-11-09 12:09

Either that, or introduce new properties (see SetOption function in server object). Having sensible defaults is also very important...

- Issue History
Date Modified Username Field Change
2010-11-01 10:11 nami New Issue
2010-11-01 15:51 skirsdeda Note Added: 0001404
2010-11-03 08:23 nami Note Added: 0001406
2010-11-03 08:39 nami Note Edited: 0001406
2010-11-05 11:44 skirsdeda Note Added: 0001407
2010-11-09 11:42 nami Note Added: 0001410
2010-11-09 11:46 skirsdeda Note Added: 0001411
2010-11-09 11:51 nami Note Added: 0001412
2010-11-09 12:09 skirsdeda Note Added: 0001413


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker