Re: Help Request for our Webshop
On Sep 23, 2007, at 10:09 PM, Dr. H. Nikolaus Schaller wrote: Why haven't you said that initially? It would have saved me to even mention oscommerce and you the discussion about it. 'cuz he's a big meany! No, wait, that can't be it! Maybe he figured anyone who was qualified would already know what a steaming heap oscommerce is (zencart is a futile attempt to make oscommerce cleaner and more featureful). More likely, though, he just didn't think of it! :') ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM Camera - a new angle
Then comes the part which really pisses me off: Panasonic has crippled the camera so that you can't use zoom or focus functions while recording video. Now, I know this is not a camcorder. I don't expect it to record good quality video - just something casual once in a while. However, maybe I'm gullible, but I do not fucking expect Panasonic to maliciously lock me out of basic camera controls when recording. They lock you out because the results would look terrible if they didn't. So I guess it's a marketing reason, but it's a good one. The optics on cheap zoom digicams move in a jerky and noisy fashion. Optics that aren't are significantly larger and/or more expensive. It's a significant marketing bullet point when they do allow you to zoom during video on a digicam. Of the current Canon digicam's, only the S5 IS has smooth optics to provide that capability. Bryan ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Help Request for our Webshop
2007/9/23, Dr. H. Nikolaus Schaller <[EMAIL PROTECTED]>: The "standard" Open Source Web Shop is OSCommerce (http:// www.oscommerce.com/). in fact we had developed a web shop even before the gta01 sales started and in the end put it into a deep, black hole. yes it was based on oscommerce, but as soon as you tried to get it maintainable or even secure, every competent person does run away or is not ready to take any responsibility. this mail should de-motivate anybody. but i think it is important that we already took a punch at it and got a bloody nose. we really know what we want and what we don't, now. so please spare us further mails with 'why no oscommerce' 'why no php' Why haven't you said that initially? It would have saved me to even mention oscommerce and you the discussion about it. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: glibc-2.5-r7 package build failed with localedef error
I found a way to get around with the build failure, it's actually the failure from the binary locale generation. Here is what I had to do: - I found out that I first have to install ipkg-build script which I didn't have somehow(the Wiki seemed to have removed the reference) # wget http://www.openembedded.org/repo/org.openembedded.packaged-staging/contrib/scripts/ipkg-build - I need to first run # unsetenv LD_LIBRARY_PATH # make openmoko-devel-image - wait till it fails while building glibc-2.5-r7, seen something like ... NOTE: package glibc-2.5: started NOTE: package glibc-2.5-r7: task do_package: started NOTE: preparing tree for binary locale generation ... and it will fail soon afterwards. - edit build/conf/local.conf and add the following ENABLE_BINARY_LOCALE_GENERATION = "0" - # make clean-package-glibc-2.5-r7 && make rebuild-package-glibc-2.5-r7 - that should pass and then remove the ENABLE_BINARY_LOCALE_GENERATION = "0" line from build/conf/local.conf - run the build again # make openmoko-devel-image Not a pretty hack but it took me further though I got hit by another build error in gettext-0.14.1-r5 that I will seek help with in another thread. It had been a quite a struggle with the build on Fedora, not sure it is Fedora specific or I just didn't do all the things right, likely both. Tom On 22/09/07 22:21 -0500, TTZ W wrote: > 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@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Help Request for our Webshop
sorry.. this of course should read Joachim Steiger wrote: > this mail should NOT > de-motivate anybody. but i think it is important that > we already took a punch at it and got a bloody nose. > we really know what we want and what we don't, now. first caffeine, then mail ;) -- roh ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: interface design suggestions
On 9/23/07, Dani Anon <[EMAIL PROTECTED]> wrote: > > I find exactly the same flaws I'm talking about in what you call the new > interface. Maybe we are not looking to the same thing? Could you provide > an screenshot of the new interface or tell me how my suggestions aren't > relevant anymore? > > And the header thing is obviously something I didn't do along the > missing things I mentioned but I forgot to mention that particular > detail. As I said, it's work in progress, but I wanted to discuss this > beforehand cause I don't have much time for something that isn't going > to be used. > > Dani > > I doubt any one design will please the majority, but iirc it should be themable so people can either make their own or find one they prefer. The general consensus though is that 2007.2 is leaps and bounds ahead of 2007.1. It's definitely a lot more polished. Take a look at http://scap.linuxtogo.org for screenshots of the new interface in action. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: interface design suggestions
I really like what you have done with the bar at the top. I, too, hate the gradient, and the coloured logo is a fine alternative. Excellent thinking with the keyboard, too. A lot of the other trouble has been addressed in the redesign, but you have a good eye for this stuff. I look forward to seeing you pull apart 2007.2! Bye, -Dylan McCall On 9/23/07, Dani Anon <[EMAIL PROTECTED]> wrote: > > Hi > > I was thinking on getting an openmoko when it's done and probably > developing a couple of apps but before that I think there is a big > problem with the current graphic design so I thought I'd contribute a > mockup and some thoughts. If such contributions are welcome I'd be > willing to mockup the remaining interface elements under CC free for > any usage. Note that I don't have an openmoko yet so I just took an > screenshot of the website (the one I found to be more complete > widget-wise) and remade it. You can see both here in this png I've > uploaded to imageshack: > It's work in progress, I didn't bother to do the full reflection > treatment to the icons, and the little ideograms are pretty poorly > done, a lot of other things also need to be fixed, but it's enough to > get us started: > > http://img442.imageshack.us/img442/4728/ommockupexportaf2.png > > Now some comments about the differences: > > - The current design has too many different styles all over the > interface, there are a lot of different backgrounds, styles of > buttons, sliders, etc. In my proposal there's only one background > (that gray gradient bitmap) that is used in every "input area". For > background as the "content area" I use simply white, and the only > exception is the black status area on top with the notification icons. > Using less bitmaps not only gives you a better looking design but it > simplifies development and theming, this is very important. > > - You are using non-white colors for background of the content areas, > which gives you a text contrast of 80%. This is no good, as a mobile > device is commonly used outside and visibility (contrast) is no good > to start with, so we shouldn't have anything less than 100% contrast > for variable content, i.e: black over white or white over black. > Things that the user is familiar with like symbols and titles of > programs and headers are ok not having 100% contrast since the user > already knows the captions. > > - I understand that you are using the same non-gray color through the > interface (orange) to get some coherence. This can be a good idea to > avoid making bad color choices but we can do better and get: > a) better usability. using different colors for different categories > of things is a universal and accepted way of improving usability > (think of traffic lights and signals). You shouldn't avoid this > resource. > b) better experience. The same color all over the interface can get > boring quickly! > > - Keyboard layout. You are wasting space right know, the same keyboard > can be arranged to take advantage of 100% of the width of the screen. > The new layout gives you 20% more horizontal space resulting in more > accuracy. I'm not sure at all about having backspace and enter in that > place, that particular detail is just the first thing I came up with. > > - You have a lot of padding and margin where you don't need it. As a > result of removing those unnecessary details I have saved a lot of > space. Yes, padding and margin is good wherever we have an interactive > button that would need to be pushed, to avoid errors, but we really > don't need it for non interactive items if we design properly. > > - My key buttons are now language agnostic, "del" has been replaced by > just the backspace symbol and "enter" has been replaced by the enter > symbol. The color of the buttons provide another clue about the > function. This way the same bitmaps can be used in any language > configuration. > > - (strictly design problem) I didn't like the horizontal gradient on > top, really took my attention toward the left, I felt it was a > problem. > > - The proposed layout of the keyboard is more similar to a real > keyboard, in the current design Z is right on top of S for example. > There is space at the right of L that could be used for an ntilde (Ñ) > for spanish speakers or a cedilla (Ç) for french speakers depending on > the configuration. > > - You didn't need to surround the clock on top by a border, the format > XX:XX is easily recognizable already as an independent item, and by > removing the border you can have a bigger font size that makes it easy > to read. > > - Speaking of font sizes notice how by removing unnecessary elements > now I have bigger font sizes everywhere that make everything easier to > read. > > - The orange glow to indicate selection of an item: it's a cool idea, > but unfortunately there's little contrast between orange and white > (remember this is a cellphone so we need a lot of contrast). Contrast > between yellow and black is 65%, contrast
Re: Help Request for our Webshop
Krzysztof Kajkowski wrote: > 2007/9/23, Dr. H. Nikolaus Schaller <[EMAIL PROTECTED]>: >> The "standard" Open Source Web Shop is OSCommerce (http:// >> www.oscommerce.com/). >> >> The only requirements it does not solve are >> * it is witten in PHP >> * it has its own database model > > Hi! Recently I'm running a one-person project on oscommerce and the > deeper I get inside the code the more I see what a piece of ugly > written software this is... Each file is a mixture of HTML, PHP and > even SQL. There are no templates, no MVC nor other model, code is > buggy, unmaintened and uses PHP classes like tables. It's a software > that stuck in time five years ago... I would never do anything in > oscommerce again. > > regards > > cayco thanks for that abstract. i couldn't say it better. in fact we had developed a web shop even before the gta01 sales started and in the end put it into a deep, black hole. yes it was based on oscommerce, but as soon as you tried to get it maintainable or even secure, every competent person does run away or is not ready to take any responsibility. for example: oscommerce does not run with register globals off. everybody with even a glimpse of clue about php should now know that this is totally unacceptable to run and use when you have respect for your users and feel some kind of responsible not to put their cc data into an sql-db which gets read out from obviously unmaintainable php. so please spare us further mails with 'why no oscommerce' 'why no php' there are 4 major important facts for you to know: - it has to be secure by concept. not only by clean work. - it has to be maintainable code. which means less is sometimes more (we do not believe in paying by lines of code) - it has to perform. which does not mean we rule out scripting languages - the code has to and will be audited before put into use by a professional team who knows all the stuff a usual webcoder gives them.. so beware ;) this mail should de-motivate anybody. but i think it is important that we already took a punch at it and got a bloody nose. we really know what we want and what we don't, now. -- roh ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: interface design suggestions
On 23 Sep 2007, at 23:06, Dani Anon wrote: I find exactly the same flaws I'm talking about in what you call the new interface. Maybe we are not looking to the same thing? Could you provide an screenshot of the new interface or tell me how my suggestions aren't relevant anymore? And the header thing is obviously something I didn't do along the missing things I mentioned but I forgot to mention that particular detail. As I said, it's work in progress, but I wanted to discuss this beforehand cause I don't have much time for something that isn't going to be used. Dani See the bottom screenshot on this page: http://blogs.gnome.org/thos/2007/08/21/openmoko-20072/ You might try and get a Linux box and QEMU so you can run the software to have play. Personally I think the graphic design isn't important, people will easily fix any issues as it's easy to create icons and good looking images. The hardest thing to fix and get right is the way the interface works and behaves. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: interface design suggestions
I find exactly the same flaws I'm talking about in what you call the new interface. Maybe we are not looking to the same thing? Could you provide an screenshot of the new interface or tell me how my suggestions aren't relevant anymore? And the header thing is obviously something I didn't do along the missing things I mentioned but I forgot to mention that particular detail. As I said, it's work in progress, but I wanted to discuss this beforehand cause I don't have much time for something that isn't going to be used. Dani On 9/23/07, Giles Jones <[EMAIL PROTECTED]> wrote: > > On 23 Sep 2007, at 22:17, Dani Anon wrote: > > > Hi > > > > I was thinking on getting an openmoko when it's done and probably > > developing a couple of apps but before that I think there is a big > > problem with the current graphic design so I thought I'd contribute a > > mockup and some thoughts. > > I think you should look at the latest version of the interface, the > interface you have altered isn't present in the new release now. > > Also, I think the colour scheme you have chosen isn't any better. Too > many colours and making the dropdowns appear the same as the headings > (instead of having them in 3d relief) is confusing, when something is > clickable it should appear different to something that is not. > > > ___ > OpenMoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: interface design suggestions
On 23 Sep 2007, at 22:17, Dani Anon wrote: Hi I was thinking on getting an openmoko when it's done and probably developing a couple of apps but before that I think there is a big problem with the current graphic design so I thought I'd contribute a mockup and some thoughts. I think you should look at the latest version of the interface, the interface you have altered isn't present in the new release now. Also, I think the colour scheme you have chosen isn't any better. Too many colours and making the dropdowns appear the same as the headings (instead of having them in 3d relief) is confusing, when something is clickable it should appear different to something that is not. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
interface design suggestions
Hi I was thinking on getting an openmoko when it's done and probably developing a couple of apps but before that I think there is a big problem with the current graphic design so I thought I'd contribute a mockup and some thoughts. If such contributions are welcome I'd be willing to mockup the remaining interface elements under CC free for any usage. Note that I don't have an openmoko yet so I just took an screenshot of the website (the one I found to be more complete widget-wise) and remade it. You can see both here in this png I've uploaded to imageshack: It's work in progress, I didn't bother to do the full reflection treatment to the icons, and the little ideograms are pretty poorly done, a lot of other things also need to be fixed, but it's enough to get us started: http://img442.imageshack.us/img442/4728/ommockupexportaf2.png Now some comments about the differences: - The current design has too many different styles all over the interface, there are a lot of different backgrounds, styles of buttons, sliders, etc. In my proposal there's only one background (that gray gradient bitmap) that is used in every "input area". For background as the "content area" I use simply white, and the only exception is the black status area on top with the notification icons. Using less bitmaps not only gives you a better looking design but it simplifies development and theming, this is very important. - You are using non-white colors for background of the content areas, which gives you a text contrast of 80%. This is no good, as a mobile device is commonly used outside and visibility (contrast) is no good to start with, so we shouldn't have anything less than 100% contrast for variable content, i.e: black over white or white over black. Things that the user is familiar with like symbols and titles of programs and headers are ok not having 100% contrast since the user already knows the captions. - I understand that you are using the same non-gray color through the interface (orange) to get some coherence. This can be a good idea to avoid making bad color choices but we can do better and get: a) better usability. using different colors for different categories of things is a universal and accepted way of improving usability (think of traffic lights and signals). You shouldn't avoid this resource. b) better experience. The same color all over the interface can get boring quickly! - Keyboard layout. You are wasting space right know, the same keyboard can be arranged to take advantage of 100% of the width of the screen. The new layout gives you 20% more horizontal space resulting in more accuracy. I'm not sure at all about having backspace and enter in that place, that particular detail is just the first thing I came up with. - You have a lot of padding and margin where you don't need it. As a result of removing those unnecessary details I have saved a lot of space. Yes, padding and margin is good wherever we have an interactive button that would need to be pushed, to avoid errors, but we really don't need it for non interactive items if we design properly. - My key buttons are now language agnostic, "del" has been replaced by just the backspace symbol and "enter" has been replaced by the enter symbol. The color of the buttons provide another clue about the function. This way the same bitmaps can be used in any language configuration. - (strictly design problem) I didn't like the horizontal gradient on top, really took my attention toward the left, I felt it was a problem. - The proposed layout of the keyboard is more similar to a real keyboard, in the current design Z is right on top of S for example. There is space at the right of L that could be used for an ntilde (Ñ) for spanish speakers or a cedilla (Ç) for french speakers depending on the configuration. - You didn't need to surround the clock on top by a border, the format XX:XX is easily recognizable already as an independent item, and by removing the border you can have a bigger font size that makes it easy to read. - Speaking of font sizes notice how by removing unnecessary elements now I have bigger font sizes everywhere that make everything easier to read. - The orange glow to indicate selection of an item: it's a cool idea, but unfortunately there's little contrast between orange and white (remember this is a cellphone so we need a lot of contrast). Contrast between yellow and black is 65%, contrast between the current orange and white is 43%. Contrast between a selected cell and the cells above and below also helps, that's why I've removed the glow. A plus about yellow is that it is intuitively recognized as the most used color to highlight stuff. Contrast figures are approximate since I don't know the gamma values of the device in question. - Since I don't have an openmoko yet I didnt know what the area on the bottom of the screen (I think it must be a read only buffer) is for so I haven't mockuped it. - Also I don't know what's the thing at
Re: Help Request for our Webshop
On 9/23/07 Dr. H. Nikolaus Schaller wrote: [snip] > > 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 ) > I 100% agree on that... The "standard" Open Source Web Shop is OSCommerce (http://www.oscommerce.com/). No offense at all to those guys, but this didn't meet our needs. We've already spend over two months trying to rework that and figured that writing something from scratch would be easier in the long run. We really have an _extremely_ complex global logistics model that needs to be implemented. FIC has distribution hubs all around the world. They just do business to business transactions now. So we need to develop something that can ship direct to our customers (and retailers and even factories) from those hubs. The only requirements it does not solve are * it is witten in PHP * it has its own database model Let me add another (stupid) question: Why do you need your own web shop with CC processing? Do you want to keep the "ship worldwide from California model"? Hehe...that was just to get us through phase 1. It was never a long term plan ;-) I got the impression that the community would prefer to have more local resellers. So you would be able to completely outsource the issue of certified and secure CC payment processing if your business relation is with resellers only (and not with end-users). Most Taiwanese companies require to have T/T or L/C and deliver FOB. Oh man, if only it were that easy. The system that we want to build will also support resellers. But this is (yet) another logistics problem. Whether we're shipping direct to end users or retailers there must be a system that automates this process. Seriously, we've done our homework here. Writing something tailored to our needs is best. -Sean ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Help Request for our Webshop
If you make use of a PHP framework then it is perfectly possible to use a clear MVC concept. Yes, it *is* possible, but that is not the point here to discuss possibilities. The topic is about which Webshop technology sould be used by OpenMoko. It appears that oscommerce doesn't use MVC in PHP (because it was apparently not started with MVC in mind several years ago). And therefore it appears to be quite difficult to maintain. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Help Request for our Webshop
On 23 Sep 2007, at 16:20, Vincent wrote: I didn't, but it is an option I presume. Things like the amount of security auditing, speed of notification of security risks and fix times are important. Most web applications are open source by the very nature that they are usually written in scripting languages. No, but having him repay the damages isn't what I'd find comforting either. And anyway, as Ian said: most third parties will have a disclaimer and open source projects are mostly delivered "as is, without warranty of any kind", so you won't have someone to sue anyway. Mistakes happen. What I think will be difficult is writing a new site engine without repeating all the security issues identified over the years in other projects. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Help Request for our Webshop
On 23/09/2007, Giles Jones <[EMAIL PROTECTED]> wrote: > > > On 23 Sep 2007, at 15:35, Vincent wrote: > > > > > > And surely, you mean "someone to hold responsible" instead of > > "someone to sue"? Especially if we're talking about an open source > > project... > > > > Who says you should use open source? I didn't, but it is an option I presume. It's great when it comes to > doing free development and community stuff. But when it comes to > making money you have to look for the safest, cheapest and highest > performing product. > > If you get defrauded of thousands then a simple "I'm sorry" from an > open source developer isn't enough. > No, but having him repay the damages isn't what I'd find comforting either. And anyway, as Ian said: most third parties will have a disclaimer and open source projects are mostly delivered "as is, without warranty of any kind", so you won't have someone to sue anyway. Mistakes happen. -- Vincent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Help Request for our Webshop
On 23 Sep 2007, at 15:35, Vincent wrote: And surely, you mean "someone to hold responsible" instead of "someone to sue"? Especially if we're talking about an open source project... Who says you should use open source? It's great when it comes to doing free development and community stuff. But when it comes to making money you have to look for the safest, cheapest and highest performing product. If you get defrauded of thousands then a simple "I'm sorry" from an open source developer isn't enough. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Help Request for our Webshop
Giles Jones wrote: If you use an existing engine and you get hacked then you have > someone to sue if they were incompetent. I would think many third-party solutions have some sort of disclaimer in their documentation against this. But then, that's the beauty of open source -- if you find a bug or security hole, you can patch it yourself. -id ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Help Request for our Webshop
On 23/09/2007, Giles Jones <[EMAIL PROTECTED]> wrote: > > > On 23 Sep 2007, at 15:02, Vincent wrote: > > > > > > I guess that is the reason why Sean asked for something new > > preferably without PHP. > > In PHP it is much easier to mix everything than to use a clear MVC > > concept (although > > someone could argue that a single PHP script contains all M=MySQL, > > V=HTML, C=PHP)... > > > > If you make use of a PHP framework then it is perfectly possible to > > use a clear MVC concept. > > > > Let's hope they find a solution that is better and does not draw too > > much from the > > development budget and time they have. Developing something new from > > scratch would > > IMHO also be a waste of resources and does not guarantee that it is > > finished within > > a reasonable timeframe (e.g. October where we all await new devices > > to ship :-). > > > > > > My comments are they it's better to use an commerce engine that gets > regular security testing and patches. If you roll your own then you > need to be proactive in monitoring the system for intrusion attempts. > > Decent security testing and auditing costs money. If you use an > existing engine and you get hacked then you have someone to sue if > they were incompetent. A bit of mis-quoting, that wasn't written by me but by Dr. H. Nikolaus Schaller <[EMAIL PROTECTED]> And surely, you mean "someone to hold responsible" instead of "someone to sue"? Especially if we're talking about an open source project... > > > > ___ > OpenMoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Vincent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Help Request for our Webshop
On 23 Sep 2007, at 15:02, Vincent wrote: I guess that is the reason why Sean asked for something new preferably without PHP. In PHP it is much easier to mix everything than to use a clear MVC concept (although someone could argue that a single PHP script contains all M=MySQL, V=HTML, C=PHP)... If you make use of a PHP framework then it is perfectly possible to use a clear MVC concept. Let's hope they find a solution that is better and does not draw too much from the development budget and time they have. Developing something new from scratch would IMHO also be a waste of resources and does not guarantee that it is finished within a reasonable timeframe (e.g. October where we all await new devices to ship :-). My comments are they it's better to use an commerce engine that gets regular security testing and patches. If you roll your own then you need to be proactive in monitoring the system for intrusion attempts. Decent security testing and auditing costs money. If you use an existing engine and you get hacked then you have someone to sue if they were incompetent. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Help Request for our Webshop
On 23/09/2007, Dr. H. Nikolaus Schaller <[EMAIL PROTECTED]> wrote: > > > Am 23.09.2007 um 10:21 schrieb Krzysztof Kajkowski: > > > 2007/9/23, Dr. H. Nikolaus Schaller <[EMAIL PROTECTED]>: > >> > >> The "standard" Open Source Web Shop is OSCommerce (http:// > >> www.oscommerce.com/). > >> > >> The only requirements it does not solve are > >> * it is witten in PHP > >> * it has its own database model > > > > Hi! Recently I'm running a one-person project on oscommerce and the > > deeper I get inside the code the more I see what a piece of ugly > > written software this is... Each file is a mixture of HTML, PHP and > > even SQL. There are no templates, no MVC nor other model, code is > > buggy, unmaintened and uses PHP classes like tables. It's a software > > that stuck in time five years ago... I would never do anything in > > oscommerce again. > > I guess that is the reason why Sean asked for something new > preferably without PHP. > In PHP it is much easier to mix everything than to use a clear MVC > concept (although > someone could argue that a single PHP script contains all M=MySQL, > V=HTML, C=PHP)... If you make use of a PHP framework then it is perfectly possible to use a clear MVC concept. Let's hope they find a solution that is better and does not draw too > much from the > development budget and time they have. Developing something new from > scratch would > IMHO also be a waste of resources and does not guarantee that it is > finished within > a reasonable timeframe (e.g. October where we all await new devices > to ship :-). > > -- Vincent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Help Request for our Webshop
Am 23.09.2007 um 10:21 schrieb Krzysztof Kajkowski: 2007/9/23, Dr. H. Nikolaus Schaller <[EMAIL PROTECTED]>: The "standard" Open Source Web Shop is OSCommerce (http:// www.oscommerce.com/). The only requirements it does not solve are * it is witten in PHP * it has its own database model Hi! Recently I'm running a one-person project on oscommerce and the deeper I get inside the code the more I see what a piece of ugly written software this is... Each file is a mixture of HTML, PHP and even SQL. There are no templates, no MVC nor other model, code is buggy, unmaintened and uses PHP classes like tables. It's a software that stuck in time five years ago... I would never do anything in oscommerce again. I guess that is the reason why Sean asked for something new preferably without PHP. In PHP it is much easier to mix everything than to use a clear MVC concept (although someone could argue that a single PHP script contains all M=MySQL, V=HTML, C=PHP)... Let's hope they find a solution that is better and does not draw too much from the development budget and time they have. Developing something new from scratch would IMHO also be a waste of resources and does not guarantee that it is finished within a reasonable timeframe (e.g. October where we all await new devices to ship :-). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Help Request for our Webshop
2007/9/23, Dr. H. Nikolaus Schaller <[EMAIL PROTECTED]>: > > The "standard" Open Source Web Shop is OSCommerce (http:// > www.oscommerce.com/). > > The only requirements it does not solve are > * it is witten in PHP > * it has its own database model Hi! Recently I'm running a one-person project on oscommerce and the deeper I get inside the code the more I see what a piece of ugly written software this is... Each file is a mixture of HTML, PHP and even SQL. There are no templates, no MVC nor other model, code is buggy, unmaintened and uses PHP classes like tables. It's a software that stuck in time five years ago... I would never do anything in oscommerce again. regards cayco ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Neo 1973 certifications in Russia - 2
I think we can organize russian neo1973 community to gather people interesting in it. Maybe we can simply create page for it in the openmoko wiki? - Denis On Thu, 20 Sep 2007 13:00:08 +0400, <[EMAIL PROTECTED]> wrote: Today i got answer from Rostest: --- We don't publish information about cost of certifications, because cost depents of production, amount of tests, certification schema, and deviates in some interval. 1. If you want to import 3-10 items, you can make delivery certificate. It's cost 200$ + tax 2. If manufacturer or his representative decide to make certificate for serial manufacturing of this production (for 1 year) - 900$ + tax 3. If you want to import large amount of production - 876$ + tax I confised about cost treshold. I think that Rostest needs to test 1 item. Others phones are similar. Secondary - its looks unexpectedly easy. At this moment only money matters. I will continie to dig information. _It will be great, if i can contact with someone of FIC officials, for solving certification problems_. I am not pro in certifications. Have you any advices? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Help Request for our Webshop
Am 22.09.2007 um 19:11 schrieb Joshua Layne: Sean Moss-Pultz wrote: Dear Community, ... 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 ) I 100% agree on that... The "standard" Open Source Web Shop is OSCommerce (http:// www.oscommerce.com/). The only requirements it does not solve are * it is witten in PHP * it has its own database model Let me add another (stupid) question: Why do you need your own web shop with CC processing? Do you want to keep the "ship worldwide from California model"? I got the impression that the community would prefer to have more local resellers. So you would be able to completely outsource the issue of certified and secure CC payment processing if your business relation is with resellers only (and not with end-users). Most Taiwanese companies require to have T/T or L/C and deliver FOB. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community Digest, Vol 45, Issue 26
ops SORRY FOR SPAM! :( ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community Digest, Vol 45, Issue 26
sonal 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 > 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 > 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 > 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 > 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
Re: Help Request for our Webshop
On Sat, 22 Sep 2007 17:33:42 +0200, Sean Moss-Pultz <[EMAIL PROTECTED]> 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. I think it is great that you ask this of the community first. I was wondering just the other day why Openmoko never posted any job openings on the list, and now you did. Having people who are enthusiastic about the project working on it can only be for the better. Cheers, Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
