I'm agree with Joshua Layne! There are a lot of opensource framework to manage payment (credit card, paypal...),ship,magazine and so on! And these with a personal little modification work fine!
We are opensource and we use opensource! Francesco 2007/9/23, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > Send community mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openmoko.org/mailman/listinfo/community > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of community digest..." > > Today's Topics: > > 1. Re: GPS accuracy (Krzysztof Kajkowski) > 2. Help Request for our Webshop (Sean Moss-Pultz) > 3. Re: Help Request for our Webshop (Joshua Layne) > 4. Re: Help Request for our Webshop (Ted Lemon) > 5. Re: Help Request for our Webshop (Ian Stirling) > 6. Re: Help Request for our Webshop (Ted Lemon) > 7. Re: Help Request for our Webshop (Giles Jones) > 8. Re: [openmoko-announce] Help Request for our Webshop > (Sean Moss-Pultz) > 9. glibc-2.5-r7 package build failed with localedef error (TTZ W) > > > ---------- Messaggio inoltrato ---------- > From: "Krzysztof Kajkowski" <[EMAIL PROTECTED]> > To: "List for OpenMoko community discussion" <[email protected]> > Date: Sat, 22 Sep 2007 12:49:33 +0200 > Subject: Re: GPS accuracy > 2007/9/22, Richard Bennett <[EMAIL PROTECTED]>: > > On Fri, 21 Sep 2007 21:43:45 +0200, Krzysztof Kajkowski > > <[EMAIL PROTECTED]> wrote: > > > > > Hi! Check out picture in this article: http://www.openmoko.org.pl/node/41 > > > I had my Neo on the buttom of my back pack while riding a bike. > > > Accuracy was up to about 2m. It was realy good. > > > > Hi, > > Do you mean your phone was inside your backpack and it could reliably save > > a position every 3 seconds? Or was it stuck to the outside of your > > backpack? > > It ws on the buttom of my back back - I had laptop there, some clothes > and Neo was in the middle of it. I was realy surprised too when I > found out about accuracy of the device. > > > And you were not using the 'assistive' part of a-gps, i.e. not > > communicating with a server to provide positioning info? > > No, I think at that time there was no GPRS available on Neo (or I > didn't know how to turn it on). > > > I'm surprised as I heard reports from other devices of people having to go > > up on a hill and wait for 10 minutes before they got a position fix... > > Well, It catches fix after about 1 min if there's clear sky above. > > As you can see on the picture accuracy was good - Neo recorded my > exact route - I rode a bike on parking lot, once I drove in a circle, > once I didn't use road and drove on the sidewalk - everything is there > :) I think accuracy is comparable to my Garmin device. > > > BTW, I think you have a small error in the title "Qtopia on Neo1973 > > unrevealed!". If you meant to say they have hidden something that was > > previously revealed it is correct, otherwise you'd want to use 'Qtopia on > > Neo1973 revealed' or 'Qtopia on Neo1973 unveiled' > > Thx, I gonna correct that! > > cayco > > > > > ---------- Messaggio inoltrato ---------- > From: Sean Moss-Pultz <[EMAIL PROTECTED]> > To: List for OpenMoko community discussion <[email protected]>, > [EMAIL PROTECTED] > Date: Sat, 22 Sep 2007 23:33:42 +0800 > Subject: Help Request for our Webshop > Dear Community, > > We have a specification and database model in place for our new webshop > but we can't find the resources needed to implement this in the near > future. > > We are looking for something as follows: > > * Accept numerous online and offline payment processing options > * Add/Edit/Remove products, distributors, retailers, and customers > * Support of inventory and RMA > * Support for spare part ordering, stocking and shipment > * Support multiple carriers / shipping methods > * Automatic generation of invoices and shipping information > * Secure transactions with SSL -- we need to have the highest possible > level of security and privacy > * Clean, maintainable code which will be audited before being put into > full production. > > Preferable this webshop should not be written in PHP. Either Perl, > Python or Ruby would be fine by us. > > If anyone is interested in developing this webshop, (for pay of course) > please email [EMAIL PROTECTED] with the following information: > > 1) A summary of your qualifications > 2) How much time you could spend on this project > > We will select from these emails a few especially qualified applicants > and ask them to sign our NDA and then provide them with the complete > specification and database model. There are too many confidential > business details to just post this all publicly now. > > Thanks! > > Sean > > > > > ---------- Messaggio inoltrato ---------- > From: Joshua Layne <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], List for OpenMoko community discussion > <[email protected]> > Date: Sat, 22 Sep 2007 10:11:56 -0700 > Subject: Re: Help Request for our Webshop > Sean Moss-Pultz wrote: > > Dear Community, > > > > We have a specification and database model in place for our new webshop > > but we can't find the resources needed to implement this in the near > > future. > > > > We are looking for something as follows: > > > > * Accept numerous online and offline payment processing options > > * Add/Edit/Remove products, distributors, retailers, and customers > > * Support of inventory and RMA > > * Support for spare part ordering, stocking and shipment > > * Support multiple carriers / shipping methods > > * Automatic generation of invoices and shipping information > > * Secure transactions with SSL -- we need to have the highest possible > > level of security and privacy > > * Clean, maintainable code which will be audited before being put into > > full production. > > > > Preferable this webshop should not be written in PHP. Either Perl, > > Python or Ruby would be fine by us. > > > Hi Sean, > This may be a stupid comment (and feel free to ignore it if it is), but > why build your own? > Having worked on ecom sites in the past and seen how convoluted > individual requirements can make a site, I've come to the conclusion > that there are significant advantages in doing just what everybody else > does. > > a brief googling * turned up 'substruct' - open source, based on ruby > on rails - meets a subset of your requirements, but may be extensible > enough that you don't have to reinvent the entire wheel, only the shiny > new spin-rims. > > * Based on about a minute and a half of investigation - there are > probably more appropriate projects out there, this is just an example. > > And your requirements may really be complex enough that the pre-built > OSS stack isn't viable. In that case, I would take a closer look at the > requirements and see if you can drop any for release 1. > > Build when all else fails (unless it is your core competency, like > say.... a linux phone distribution :P ) > > my $0.02 > josh > > If anyone is interested in developing this webshop, (for pay of course) > > please email [EMAIL PROTECTED] with the following information: > > > > 1) A summary of your qualifications > > 2) How much time you could spend on this project > > > > We will select from these emails a few especially qualified applicants > > and ask them to sign our NDA and then provide them with the complete > > specification and database model. There are too many confidential > > business details to just post this all publicly now. > > > > Thanks! > > > > Sean > > > > _______________________________________________ > > OpenMoko community mailing list > > [email protected] > > http://lists.openmoko.org/mailman/listinfo/community > > > > > > ---------- Messaggio inoltrato ---------- > From: Ted Lemon <[EMAIL PROTECTED]> > To: List for OpenMoko community discussion <[email protected]> > Date: Sat, 22 Sep 2007 10:44:59 -0700 > Subject: Re: Help Request for our Webshop > On Sep 22, 2007, at 10:11 AM, Joshua Layne wrote: > > a brief googling * turned up 'substruct' - open source, based on > > ruby on rails - meets a subset of your requirements, but may be > > extensible enough that you don't have to reinvent the entire wheel, > > only the shiny new spin-rims. > > The carts I've played with generally have no concept of credit card > security. I did a project with zencart a while back, and had to > retrofit my own credit card security model into the system because it > just stored credit card information in the database, where an SQL > injection attack would reveal everything. > > I haven't looked closely at substruct - maybe they do something > smarter. My personal model for credit card security is to never > store the credit card information on a customer-facing machine, and > indeed only keep that information as long as it's needed, even on a > back office machine. This way, even if you screw up the security on > your customer-facing machine, the worst risk is that some info will > be exposed until you detect the security compromise - there's no risk > that everybody who ever ordered anything from you will have to get a > new credit card. > > > > > > ---------- Messaggio inoltrato ---------- > From: Ian Stirling <[EMAIL PROTECTED]> > To: List for OpenMoko community discussion <[email protected]> > Date: Sat, 22 Sep 2007 21:22:17 +0100 > Subject: Re: Help Request for our Webshop > Ted Lemon wrote: > > On Sep 22, 2007, at 10:11 AM, Joshua Layne wrote: > > > >> a brief googling * turned up 'substruct' - open source, based on > >> ruby on rails - meets a subset of your requirements, but may be > >> extensible enough that you don't have to reinvent the entire wheel, > >> only the shiny new spin-rims. > > > > > > The carts I've played with generally have no concept of credit card > > security. I did a project with zencart a while back, and had to > > retrofit my own credit card security model into the system because it > > just stored credit card information in the database, where an SQL > > injection attack would reveal everything. > > Or you completely offload the problem. > Paypal means that you never see the CC info at all. > Ebay has perfectly functional web-stores. > > >>50% of your buyers won't even need to do more than click 'buy now', > and then click through to paypal and pay in seconds. > There are many, many canned applications to print labels for packaging, > and to compute shipping. > > Adding new stock is utterly trivial. > > > > > ---------- Messaggio inoltrato ---------- > From: Ted Lemon <[EMAIL PROTECTED]> > To: List for OpenMoko community discussion <[email protected]> > Date: Sat, 22 Sep 2007 15:37:12 -0700 > Subject: Re: Help Request for our Webshop > On Sep 22, 2007, at 1:22 PM, Ian Stirling wrote: > > Paypal means that you never see the CC info at all. > > This is called throwing the baby out with the bathwater... > > > > > > ---------- Messaggio inoltrato ---------- > From: Giles Jones <[EMAIL PROTECTED]> > To: List for OpenMoko community discussion <[email protected]> > Date: Sun, 23 Sep 2007 01:26:39 +0100 > Subject: Re: Help Request for our Webshop > > On 22 Sep 2007, at 23:37, Ted Lemon wrote: > > > On Sep 22, 2007, at 1:22 PM, Ian Stirling wrote: > >> Paypal means that you never see the CC info at all. > > > > This is called throwing the baby out with the bathwater... > > > > Indeed, you don't want to have to deal with PayPal and Ebay if you > can help it. Even if you suspect you are about to be ripped off, you > still have to complete the sale or else they get shirty. > > There's no way I'm going to post an item to a unconfirmed address > with a CC name that doesn't match the buyer, but I got warned about > not completing the sale. > > Best not to build a business around PayPal/Ebay without knowing the > ropes. > > > > > > ---------- Messaggio inoltrato ---------- > From: Sean Moss-Pultz <[EMAIL PROTECTED]> > To: Bertrand Juglas <[EMAIL PROTECTED]> > Date: Sun, 23 Sep 2007 09:38:38 +0800 > Subject: Re: [openmoko-announce] Help Request for our Webshop > On 9/23/07 Bertrand Juglas wrote: > > I've tried to send my answer to [EMAIL PROTECTED] but i've > > received an administrative email reply informing me about an "unknown > > user" error so i'm sending you below my answer so you can forward it > > to the good email. > > Oh wow this was my mistake. The email is [EMAIL PROTECTED] (remove > the lists. part). > > Sorry guys! > > Also, please give us a few more days to filter the emails. I'm going to > have some fun these next two days in southern Taiwan: > > http://en.wikipedia.org/wiki/Mid-Autumn_Festival > > We're all off work ;-) > > -Sean > > > > > > ---------- Messaggio inoltrato ---------- > From: TTZ W <[EMAIL PROTECTED]> > To: List for OpenMoko community discussion <[email protected]> > Date: Sat, 22 Sep 2007 22:21:46 -0500 > Subject: glibc-2.5-r7 package build failed with localedef error > It seems that I keep hitting build errors on random places(I had not > tried the suggestion made by a fellow member here to my last > problem with the webkit-gtk, as I reinstalled my box with the FC7, > probably not a smart thing to do). The latest is during building > glibc-2.5-r7 package: > > NOTE: preparing tree for binary locale generation > NOTE: generating locale es_NI (UTF-8) > NOTE: Task failed: localedef returned an error (command was..... > > The build was made on a scratch FedoraCore7 installation(as I mentioned, > which I probably shouldn't have done) and I am following the > OpenMokoMakefile build instructions: > > Attached at the end is some more build log info.. I'd read some net > posts regarding using the "/usr/share/i18n" instead of the > "build-tree/usr/share/i18n", so I even made a sym link of the > "/usr/share/i18n" that points to the "build-tree/usr/share/i18n", but > that doesn't seem to help. > > Had anyone else encountered the similar problem? I am building > another Debian Etch box and will try the build there to see if the > build there could pass. > > Any hint on how to resolve this is much appreciated, > > Tom > > > OE Build Configuration: > BB_VERSION = "1.8.8" > OE_REVISION = "5150c80af670db94e4e8f4cd404cc461f4a9a84e" > TARGET_ARCH = "arm" > TARGET_OS = "linux-gnueabi" > MACHINE = "fic-gta01" > DISTRO = "openmoko" > DISTRO_VERSION = "P1-September-Snapshot-20070923" > TARGET_FPU = "soft" > > .... > > NOTE: preparing tree for binary locale generation > NOTE: generating locale es_NI (UTF-8) > NOTE: Task failed: localedef returned an error (command was > PATH="/media/sdc1/mo > ko/build/tmp/staging/i686-linux/bin/arm-angstrom-linux-gnueabi:/media/sdc1/moko/ > build/tmp/staging/i686-linux/bin:/media/sdc1/moko/build/tmp/cross/bin:/media/sdc > 1/moko/bitbake/bin:.:/home/tzheng/bin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/o > pt/arm/bin:/opt/axis2c/bin:/opt/gsoap/bin:/opt/java/ant/bin:/opt/java/j2se/jdk/b > in:/opt/rar/:/opt/cbrowser:/opt/cscope/bin:/opt/firefox:/opt/netscape:/opt/expat > /bin:/opt/perl5/bin:/opt/rar:/opt/local/bin:/bin:/etc:/usr/bin/X11" > I18NPATH="/m > edia/sdc1/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/glibc-2.5-r7/locale- > tree//usr/share/i18n" qemu-arm -r 2.6.16 -L > /media/sdc1/moko/build/tmp/work/armv > 4t-angstrom-linux-gnueabi/glibc-2.5-r7/locale-tree > /media/sdc1/moko/build/tmp/wo > rk/armv4t-angstrom-linux-gnueabi/glibc-2.5-r7/locale-tree/bin/localedef > --force > --old-style --no-archive > --prefix=/media/sdc1/moko/build/tmp/work/armv4t-angstro > m-linux-gnueabi/glibc-2.5-r7/locale-tree > --inputfile=/usr/share/i18n/locales/es_ > NI --charmap=UTF-8 es_NI). > NOTE: package glibc-2.5-r7: task do_package: failed > ERROR: TaskFailed event exception, aborting > NOTE: package glibc-2.5: failed > ERROR: Build of /media/sdc1/moko/openembedded/packages/glibc/glibc_2.5.bb > do_package failed > > > > > _______________________________________________ > OpenMoko community mailing list > [email protected] > http://lists.openmoko.org/mailman/listinfo/community > > _______________________________________________ OpenMoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
