These discussions should really occur in public, especially as nextgens is your mentor, not me! :) So I've CC'ed devl.
On Sunday 16 Jun 2013 18:53:26 Nitesh Bharadwaj wrote: > On Sun, Jun 9, 2013 at 12:51 AM, Matthew Toseland <[email protected] > > > > > > The github link for android port under development and related testing is > > > https://github.com/NiteshBharadwaj/Fred-Staging-Android > > > > IMHO it would be best if we could have a common source code, and just have > > different scripts to build Freenet on different platforms. Whereas the > > above is definitely not forked from the main fred repository. Also it > > includes binaries in the repo, which is usually a bad thing. > > > Yes. I have changed the code structure with fred-staging as submodule. I > have a question. By common source code do you mean - > a) We have abc.java and abc_android.java for the files that are needed to > be changed. And the ant script chooses the files depending on platform. > b) abc.java contains code of all platforms. This is turning to be difficult > as we don't have compile time conditionals in java. #ifdef #ifndef etc. > c) If you mean point a) then that is same as having different source codes > at different locations?? I'd probably go for (a), yes. How much of the code actually needs a different version for Android? I mean, Android includes 99% of the Java 6 API, apart from the GUI stuff. Only one or two files use GUI stuff, so it should be possible to exclude that (it's only used by web pushing anyway)? > > > > With respect to QR, I have cloned Operheim's implementation of > > > NoderefQRCode which is a plugin to freenet and can convert node > > references > > > into QR code and decode them back. > > > https://github.com/Thynix/NoderefQRCode > > > > > > Since, this part is already implemented by Operheim, I have just run a > > few > > > tests. > > > I tried to scan the generated QR using popular applications available on > > > google app store. It could decode correctly 7 out of 10 times while 3 > > times > > > it decoded a random number! > > > Using the original decoder (in NoderefQR), it gave similar results except > > > that instead of random number it ran into check sum exception once or > > twice. > > > > > > The basic problem I noticed is bigger the size of the string to be > > decoded, > > > the longer it takes (quite irritating) and more the chances of a wrong > > > decode. > > > > > > During the planning stage, we thought about using QR codes only to > > > establish Wi-Fi Direct connection between two mobiles. The actual node > > > references are exchanged via Wi-Fi direct. This seems a better option > > > compared to encoding whole nodereference in QR (We could provide multiple > > > options anyway). The high band-width during such transfer can also be > > > utilized for sneakernet support later on. > > > > Yes, or you will have to do some work on shrinking noderefs first. Let me > > know if this is a serious option, we have lots of ideas about it, but > > really IMHO exchanging via wifi direct is probably best. That can use NFC > > or Bluetooth for short range key exchange, or you could use QR codes to > > exchange a password to be used for wifi encryption. > > > > > > Specific Questions: > > > > > > 1) (Related to darknet support) On the main freenet node, should I let > > this > > > be an optional plugin or directly add options to fred-staging to > > > synchronize peers with its mobile node. > > > > I'm not sure. Probably best to make it part of fred. Certainly it needs to > > be integrated closely, e.g. we may want something on the Add a Friend page. > > > Ok. > > > > > > > 2) (Related to android port) db4o offers a package Db4OEmbedded and had > > > several positive reviews online. So, is it still necessary to rip out > > db4o > > > from fred? > > > > db4o will be removed from fred soon. So don't worry about it one way or > > the other. > > > > > > Suggestions and Comments are most welcome. > > > > > > Thanks for reading through! > > > > > > For more details related to project, please visit > > > http://niteshgsoc2013.blogspot.in/ > > > > > Thanks! > > > I will be focusing on making the required changes to fred on Add a Friend > page and work on the connection between mobile node and fixed node this > week. > > I think providing multiple options would be beneficial so that users can > choose depending on hardware > > Option1: > > A Wi-Fi direct (softAP on mobile node - stays active only until the noderef > is transferred to save battery) to legacy Wi-Fi connection (on fixed node - > assuming fixed node doesn't support Wi-Fi Direct although Windows 8 devices > now support) > 1) A way to transfer the WPS pass key auto generated by mobile node to > fixed node. > a) Typing in the passkey on fixed node > b) QR (assuming fixed node has webcam) Do it the other way around. Generate a QR on the fixed node and take a picture with the phone. > 2) I observed that one mobile node always generates the same pass key for > its softAP (Wi-Fi Direct) > a) Advantage: Transfer the pass key only once per mobile node it is synced > up with and remember for all future noderef sync ups. > b) Disadvantage: Security?? Some handshake to make sure that we are > communicating with right node or some crypto?? Hmmm, is that intended? You should talk to nextgens. > > Option2: > > A bluetooth connection between mobile node and fixed node to sync up node > references Some home nodes won't have BT. > > Option3: > > Only QR - Using the plugin implemented by Operheim to generate QR on fixed > node In which case you're just downloading the noderef as a QR? You would still need to be able to verify it. Anyway you'll need to be able to transfer data back to the node to finish setting up connections. So IMHO you need a wifi or BT link, no?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
