May 2010 - Bluetooth-dev - lists.apple.com

Re: Framework for synchronizing data between multiple Macs
by Matthias Ringwald 24 May '10

24 May '10

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com Hi Josh thanks for letting us know. As an off-topic comment: how do you decide which information is the newest and should be pushed towards other stations. I've spend some time working on a friend's and mine nmSync (http://nmsync.sf.net) which doesn't assume direct connection between peers but the use of disposable media (USB sticks, CD-R,...) that one carrys around, which makes the problem even harder. For direct connections, I can highly recommend the work on vector time pairs by Cox and Williams http://dspace.mit.edu/handle/1721.1/30527 as it was the base for your project. Best Matthias On 24.05.2010, at 01:24, Josh Freeman wrote: > Hi, > > I'm developing a free, open-source framework that might be interesting to some here. It enables multiple nearby Macs to wirelessly synchronize shared data over Bluetooth - this can be useful for creating local-area multiuser apps, like social networking, collaboration apps, chatrooms, etc. > > I'm also developing an app for Mac meetups that uses the framework to automatically share simple profile info among attendees. > > For more info, please go to: > http://twilightedge.com/mac/bluepool/ (framework) > http://twilightedge.com/mac/bluebook/ (profile-sharing app) > > Cheers, > > Josh Freeman > Twilight Edge Software > http://www.twilightedge.com > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/bluetooth-dev/mringwal%40inf.ethz.ch > > This email sent to mringwal(a)inf.ethz.ch _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Framework for synchronizing data between multiple Macs
by Josh Freeman 23 May '10

23 May '10

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com Hi, For more info, please go to: http://twilightedge.com/mac/bluepool/ (framework) http://twilightedge.com/mac/bluebook/ (profile-sharing app) Cheers, Josh Freeman Twilight Edge Software http://www.twilightedge.com I'm developing a free, open-source framework that might be interesting to some here. It enables multiple nearby Macs to wirelessly synchronize shared data over Bluetooth - this can be useful for creating local-area multiuser apps, like social networking, collaboration apps, chatrooms, etc. I'm also developing an app for Mac meetups that uses the framework to automatically share simple profile info among attendees. _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Bluetooth-dev Digest, Vol 7, Issue 13
by Matthias Ringwald 02 May '10

02 May '10

site_archiver(a)lists.apple.com Delivered-To: Bluetooth-dev(a)lists.apple.com Hi David On 29.04.2010, at 16:14, dsjove .mac wrote: > > I am writing for the desktop using Cocoa's BT objects. I would love to get this app on the iPhone but jailbreaking appears to be the only option. > > My model over BT is remote procedure calls. That is why I need a dedicated thread for acquiring and signaling results. > > "Blocking" is an ambiguous term. If an event on the main thread calls a function, it is blocking. The low level private implementation detail of a function interacting with BT is irrelevant to the fact that the main run loop calls a getter on a model object. I have policies built in for timeouts. > > Some of these getters are computed from the results of multiple BT remote procedure calls. The main thread calls the procedural getters. In one connection implementation, BT, it uses another thread to sync the results. Ah. So you (want to) provide synchronous RPC over BT. We did provide synchronous BT calls in BTnut (btnode.ethz.ch), but so far I don't plan on adding such a feature to BTstack. > > I would recomend allowing the client of your library to select the thread. Auto injection into global state is a limiting side-effect. RPC becomes very difficult. Thanks for the suggestion. Not convinced yet, but I guess we should this discuss this over at the BTstack-dev mailing list :) > > So back to CocoaTouch - can your code go into an AppStore product? Let's say it is not impossible. An application that uses BTstack can run inside the usual Sandbox. The client library currently is a dylib but there is no reason to not just link it statically. However, to work, BTdaemon (which implements the Bluetooth stack) needs to be installed and running, which is only possible with jailbreak. So, I in theory an app in the AppStore could use BTstack, but only on a jailbroken device, which might make the AppStore review a bit awkward. ... See you on the BTstack list :) Best Matthias _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0