community Digest, Vol 45, Issue 26

[Francesco Pistillo]

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, community-request at lists.openmoko.org
<community-request at lists.openmoko.org>:
> Send community mailing list submissions to
>         community at lists.openmoko.org
>
> 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
>         community-request at lists.openmoko.org
>
> You can reach the person managing the list at
>         community-owner at lists.openmoko.org
>
> 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" <cayco at poczta.cayco.pl>
> To: "List for OpenMoko community discussion" <community at lists.openmoko.org>
> Date: Sat, 22 Sep 2007 12:49:33 +0200
> Subject: Re: GPS accuracy
> 2007/9/22, Richard Bennett <richard.bennett at skynet.be>:
> > On Fri, 21 Sep 2007 21:43:45 +0200, Krzysztof Kajkowski
> > <cayco at poczta.cayco.pl> 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 <sean at openmoko.com>
> To: List for OpenMoko community discussion <community at lists.openmoko.org>, announce at lists.openmoko.org
> 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 coreteam at lists.openmoko.org 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 <joshua at willowisp.net>
> To: sean at openmoko.com, List for OpenMoko community discussion <community at lists.openmoko.org>
> 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 coreteam at lists.openmoko.org 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
> > community at lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/community
>
>
>
>
>
> ---------- Messaggio inoltrato ----------
> From: Ted Lemon <mellon at fugue.com>
> To: List for OpenMoko community discussion <community at lists.openmoko.org>
> 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 <OpenMoko at mauve.plus.com>
> To: List for OpenMoko community discussion <community at lists.openmoko.org>
> 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 <mellon at fugue.com>
> To: List for OpenMoko community discussion <community at lists.openmoko.org>
> 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 <giles.jones at zen.co.uk>
> To: List for OpenMoko community discussion <community at lists.openmoko.org>
> 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 <sean at openmoko.com>
> To: Bertrand Juglas <b at juglas.name>
> 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 coreteam at lists.openmoko.org 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 coreteam at openmoko.org (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 <ttzweb at gmail.com>
> To: List for OpenMoko community discussion <community at lists.openmoko.org>
> 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
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
>