well, i live in the farest place of you all, a little place called Israel. I think we should have both a mailing list (maybe thru SF) and an IRC channel, i'm making a channel in EFNet called #openposs for now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2002-04-04
One question regarding the implementation: Don't we
also need a connection to an article database?
Are there already OpenSource solutions for handling
such a database on the market? If so, which one
should we connect to?
Furthermore, I don't think that we can access
hardware like barcode readers from Java alone. It
might be necessary, to write portions of the code
in some system-dependent way (C/C++/Access to
certain libraries).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wolfram, I've done this in Java. So it is possible. We aren't writing to the hardware itself. We are reading what the hardware sends us. If you want I can post the code somewhere here on the site.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've done a little bit of investigation, and yes we can access the serial ports using javax.comm, however this only supports Win32 and Solaris. I have seen another interface called rxtx which will also support HPUX and linux. Does anyone know of something to work on other os's like Macs, etc?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Brian, Do we really need to worry about Mac OS? Is any of this code going to run on MAC? Apache? PHP? Mysql? I'm not sure if thats an issue. Looks like RXTX is our best bet for muliplatform use.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
was there any particular reason for picking EFNet as the IRC network to use? As DALNet seems to have a better world-wide list of servers (especially here in Australia).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i don't really mind, although i'm usually connected to EFNet. but i think right now we should stick to the mailing list and open the irc channel later.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Kewl, we'll leave the IRC until later. On another matter, I have started on the SQL database creation script, and something we need to decide is will "users" have passwords and if so, how do we want to encrypt it before storing in the database.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Passwords will be an option avilbable to the admin of the system. I can forsee some applications were a store would not want to have a user using a password (a store with one or two employees for example). But since we will be using a admin driven system, we will need the ability to use passwords.
As for encryption, I've always used MySQLs built in encytion method. Don't other DBs have such features?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
While my original intention was to design a truley cross-platform system, I think we can safely assume that 99% of the systems running the server will either be some type of Linux, BSD, or Windows.
The client on the other hand "*needs*" to be truley cross platform. After all, why else would anyone want a broswer-based Point-of-Sale system? We will really need to find a way to be able to accept barcode scans on a machine running MacOS, Windows, and Linux. Do we realistilcy expect anyone to be running anything else?
Please, input is nessisary here...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Does Mac even support Serial ports? Last time I checked it was all USB. And if we found a MAC that did support serial ports its probably so old that it couldn't run any of the software required to run. My impression is that the server / client will be all on one box. Am I wrong about this? If not. Where will this server be hosted? Would it be one central server? Like openPOS hosts it? or would the customer host it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I'm now catching up on all the goss overnight (overnight for me).
1. Passwords will be enableable (forgive my english, I never liked it as school) on a system wide basis by the admin (or installer)
2. The database encryption of the passwords is based on a login to the datbase, not our system, the way I see the backend working is there will be a single login to the database which the PHP scripts will use, and we (developers) will maintain a serparate list of users in a database table which will allow us to give/revoke access to various sub-systems in openPOS. With this method, we can also allow for the manager on a larger system to do reporting on which of his staff aren't pulling their weight if they so desired.
3. I agree, using md5 from within PHP will work fine for the password encryption.
4. MacOS, I mentioned because I know of a retailer here in Aust. that uses Mac's for there system, they also run a seperate (ancient) cash register. Although I feel that if we don't make Mac's compatible in the first release, then we can run with-out it, and look at it again when time is available.
5. I recommend that we try to promote linux as the preferred OS for the server, however Windows will also work without a problem.
6. Even if the Mac's don't support serial, I have seen inexpensive units to allow connection of RS232 equipment to a USB bus, this gear also comes with software (I'm not sure which OS's) to emulate a serial port on the machine.
7. The client and server could run on one box, however the prefered config would be a dedicated server and dedicated clients.
8. further to 7, I believe that another option to look at as a feature might me some form of server to server dialup to permit updates across shopfronts, this could be used to basically sync 2 databases at remote locations primarily for reporting capabilities.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Brian, you've done a great job of summing everything up. The intention here is to build a system that will have a system running our dedicated server software (using PHP and MySQL, or any compatible db), and the registers would all be client machines on the network simply running a web-browser (kind of elegent, you know?). Linux would definitly be the OS of choice for the server, but as we build the system, we need to be sure that Windows is still supported.
But Joe does raise a good point: should we code to have the server and the browser running on the same machine? I really don't think that it is something that we need to "code" for. After all, the TCP/IP protocol stack will take care of all routing and addressing issues, even if the target is 'localhost' or '127.0.0.1'.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Chris, thanks for the compliment, and yes the code for seperate client and server will work extremely happily (and quickly) with both running on the same machine (equivalent depending on the machine of an excess of gigabit networking).
As far as windows support is concerned I will be testing all aspects that I code on a W98 box and can also test on W95, W2K, WinNT, WinME, and WinXP if you want.
Because of the structure and coding of the backend (MySQL (and others), Apache, mod_PHP) there are no OS dependant issues that aren't already solved by other vendors (namely MySQL and Apache).
I have gotten the basic DB schema already in the CVS and I have started getting some PHP code together for the backend server. I also setup emailling from the CVS repository, however there is a fault and I have logged it with the sourceforge support team as tracker ID 540103.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Have you considered a Database Abstraction Layer yet? However popular MySQL is, not everyone uses it. I think it would be great to be able to choose which DB Platform to use for openPOS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
KEEP IT SIMPLE
many or/and most POS users do need it SIMPLE
Point 1 : Why do people need POS ?
-quick working (using pre-defined keys or barcode input,ease repetetive tasks)
-quick management jobs (statistics,inevntory managenment ,cash control..)
-ticketing ,bills
Point 2 : Does everybody needs all of these 3 point her above ? NO
Point 3 : Each branche of industry has it's own needs. Start a software always SMALL !
Point 4 : Write software=> very nice and clever , but be INTERNATIONAL ! Let your software be transleted by the open community.
I could go on for pages but these points above are the bottom line for POS software.
question : already used a POS once in your life for real ? Hell, I did . And you'll learn from.
For example a lokal grocery shop has for example no need of tracking inventory list and day revenues.
They only need quick selling based on preprogrammed keys or from a barcode.
Lost and lots of this small bussiness have exactly the same needs. So please start SMALL.
All the others progs have already big time databases which are to complex and to expensive for all these small businesses.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tal, Sorry if I'm frustrating you I guess I just didn't understand what you mean.
Absolutely no probs, however, i think John got my intention (read his thread about keyborad input).
BTW, anyone think that we should make an IRC channel for the projects so we can talk in real time?
talp,
The irc channel sounds OK, although know for a fact that there is a 15Hr difference between myself and Chris.
Perhaps a mailing list might be a little wiser as you can still near-real time chat, and it also allows all of us to know what's been going on.
well, i live in the farest place of you all, a little place called Israel. I think we should have both a mailing list (maybe thru SF) and an IRC channel, i'm making a channel in EFNet called #openposs for now.
One question regarding the implementation: Don't we
also need a connection to an article database?
Are there already OpenSource solutions for handling
such a database on the market? If so, which one
should we connect to?
Furthermore, I don't think that we can access
hardware like barcode readers from Java alone. It
might be necessary, to write portions of the code
in some system-dependent way (C/C++/Access to
certain libraries).
Wolfram, I've done this in Java. So it is possible. We aren't writing to the hardware itself. We are reading what the hardware sends us. If you want I can post the code somewhere here on the site.
I've done a little bit of investigation, and yes we can access the serial ports using javax.comm, however this only supports Win32 and Solaris. I have seen another interface called rxtx which will also support HPUX and linux. Does anyone know of something to work on other os's like Macs, etc?
Brian, Do we really need to worry about Mac OS? Is any of this code going to run on MAC? Apache? PHP? Mysql? I'm not sure if thats an issue. Looks like RXTX is our best bet for muliplatform use.
was there any particular reason for picking EFNet as the IRC network to use? As DALNet seems to have a better world-wide list of servers (especially here in Australia).
i don't really mind, although i'm usually connected to EFNet. but i think right now we should stick to the mailing list and open the irc channel later.
Kewl, we'll leave the IRC until later. On another matter, I have started on the SQL database creation script, and something we need to decide is will "users" have passwords and if so, how do we want to encrypt it before storing in the database.
Passwords will be an option avilbable to the admin of the system. I can forsee some applications were a store would not want to have a user using a password (a store with one or two employees for example). But since we will be using a admin driven system, we will need the ability to use passwords.
As for encryption, I've always used MySQLs built in encytion method. Don't other DBs have such features?
I do think we should make the system based on users. This way, we can make stats for users, users groups, etc. What do you guys think?
Well if we use PHP it luckily has the md5()
While my original intention was to design a truley cross-platform system, I think we can safely assume that 99% of the systems running the server will either be some type of Linux, BSD, or Windows.
The client on the other hand "*needs*" to be truley cross platform. After all, why else would anyone want a broswer-based Point-of-Sale system? We will really need to find a way to be able to accept barcode scans on a machine running MacOS, Windows, and Linux. Do we realistilcy expect anyone to be running anything else?
Please, input is nessisary here...
Does Mac even support Serial ports? Last time I checked it was all USB. And if we found a MAC that did support serial ports its probably so old that it couldn't run any of the software required to run. My impression is that the server / client will be all on one box. Am I wrong about this? If not. Where will this server be hosted? Would it be one central server? Like openPOS hosts it? or would the customer host it?
OK, I'm now catching up on all the goss overnight (overnight for me).
1. Passwords will be enableable (forgive my english, I never liked it as school) on a system wide basis by the admin (or installer)
2. The database encryption of the passwords is based on a login to the datbase, not our system, the way I see the backend working is there will be a single login to the database which the PHP scripts will use, and we (developers) will maintain a serparate list of users in a database table which will allow us to give/revoke access to various sub-systems in openPOS. With this method, we can also allow for the manager on a larger system to do reporting on which of his staff aren't pulling their weight if they so desired.
3. I agree, using md5 from within PHP will work fine for the password encryption.
4. MacOS, I mentioned because I know of a retailer here in Aust. that uses Mac's for there system, they also run a seperate (ancient) cash register. Although I feel that if we don't make Mac's compatible in the first release, then we can run with-out it, and look at it again when time is available.
5. I recommend that we try to promote linux as the preferred OS for the server, however Windows will also work without a problem.
6. Even if the Mac's don't support serial, I have seen inexpensive units to allow connection of RS232 equipment to a USB bus, this gear also comes with software (I'm not sure which OS's) to emulate a serial port on the machine.
7. The client and server could run on one box, however the prefered config would be a dedicated server and dedicated clients.
8. further to 7, I believe that another option to look at as a feature might me some form of server to server dialup to permit updates across shopfronts, this could be used to basically sync 2 databases at remote locations primarily for reporting capabilities.
Brian, you've done a great job of summing everything up. The intention here is to build a system that will have a system running our dedicated server software (using PHP and MySQL, or any compatible db), and the registers would all be client machines on the network simply running a web-browser (kind of elegent, you know?). Linux would definitly be the OS of choice for the server, but as we build the system, we need to be sure that Windows is still supported.
But Joe does raise a good point: should we code to have the server and the browser running on the same machine? I really don't think that it is something that we need to "code" for. After all, the TCP/IP protocol stack will take care of all routing and addressing issues, even if the target is 'localhost' or '127.0.0.1'.
Chris, thanks for the compliment, and yes the code for seperate client and server will work extremely happily (and quickly) with both running on the same machine (equivalent depending on the machine of an excess of gigabit networking).
As far as windows support is concerned I will be testing all aspects that I code on a W98 box and can also test on W95, W2K, WinNT, WinME, and WinXP if you want.
Because of the structure and coding of the backend (MySQL (and others), Apache, mod_PHP) there are no OS dependant issues that aren't already solved by other vendors (namely MySQL and Apache).
I have gotten the basic DB schema already in the CVS and I have started getting some PHP code together for the backend server. I also setup emailling from the CVS repository, however there is a fault and I have logged it with the sourceforge support team as tracker ID 540103.
Have you considered a Database Abstraction Layer yet? However popular MySQL is, not everyone uses it. I think it would be great to be able to choose which DB Platform to use for openPOS.
KEEP IT SIMPLE
many or/and most POS users do need it SIMPLE
Point 1 : Why do people need POS ?
-quick working (using pre-defined keys or barcode input,ease repetetive tasks)
-quick management jobs (statistics,inevntory managenment ,cash control..)
-ticketing ,bills
Point 2 : Does everybody needs all of these 3 point her above ? NO
Point 3 : Each branche of industry has it's own needs. Start a software always SMALL !
Point 4 : Write software=> very nice and clever , but be INTERNATIONAL ! Let your software be transleted by the open community.
I could go on for pages but these points above are the bottom line for POS software.
question : already used a POS once in your life for real ? Hell, I did . And you'll learn from.
For example a lokal grocery shop has for example no need of tracking inventory list and day revenues.
They only need quick selling based on preprogrammed keys or from a barcode.
Lost and lots of this small bussiness have exactly the same needs. So please start SMALL.
All the others progs have already big time databases which are to complex and to expensive for all these small businesses.