On Thu, 2009-10-15 at 10:43 +0100, Graham Cobb wrote: > On Thursday 15 October 2009 09:10:44 Simon Pickering wrote: > > Replying to myself, another option (which is the same one that Android > > Scan/CompareEverywhere uses) would be to move the "scraping" to a > > server. This might let me use a single key for all the queries (though > > it may still break the terms and conditions, I'd have to look) and would > > also reduce on-device processing and the amount of data that needs to be > > transferred. > > While you are tolerating discussion of enhancements!...
lol :) > If you do use a server, it would be great if you implemented an "offline" > mode > where I could scan barcodes all day without network connectivity and, later, > process them when I am online. Some of the places one might want to scan > barcodes (barcodes on display adverts, on buildings like in Westergasfabriek, > or in warehouses) might not have great network connectivity. Most > professional barcode readers which I know of seem to do the scanning offline > and process the barcodes once they are plugged into their docking/charging > station. Yes, in any case I was planning on allowing the raw data to be saved if a lookup is not possible (for e.g. isbns and also for web urls, etc.), I currently assume an internet connection (which should apparently be fine for Fremantle ;)), but I need to get the code to ask for one and/or have an offline scanning setting (oh dear more gui elements - a menu!) > This brings up a slightly larger question of how modular is your current > implementation? It feels like it would be good to have a library (accessible > from C and Python) which would have an API like "scan the barcode the user is > currently pointing the camera at and give me back something that tells me > what sort of barcode it was and the data it contains" (maybe with some sort > of callbacks to allow some user interaction if needed to give them > help/feedback with the scanning). > > The subsequent processing (database, lookup, etc, etc.) is the sort of > thing > that various people might create separate applications for, although it might > be useful to expose some useful APIs there as well: "lookup this barcode > number on Amazon", "save this barcode in barcode database called 'My Books'", > etc. > > Is that how it works at the moment or something you are looking in to? Yes this is indeed a good idea. At the moment it's not modular as everything is mixed in, however the code is structured such that it won't take long to separate out the processing from the video taking from the gui etc. The question is then how many separate layers? I guess a wrapper/lib to process a barcode from an image buffer. An extra optional layer that can be placed ontop of this to allow the user to see what they are pointing at and to click "Scan!" (which we may do away with once the camera app is opened up, then we can add the bottom-most layer as a plugin to optionally analyse stuff taken with the main camera app). On top of these/using these one can do the other stuff such as web-lookups, databases, etc. The web-lookups should possibly also be part of the bottom-most layer though, or perhaps separated off into their own package as they will generally be needed no matter the app. Someone mentioned sending the barcodes out over DBUS, is this of interest? Any use cases? So I'm more than happy to do this (after I look at libgdigicam to work out how to focus the N900's camera and turn the LED on), as long as people want to use it, I don't want to waste time chopping things up if no-one wants to use it afterwards. Cheers, Simon _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
