You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(19) |
Aug
(62) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
---|
From: Brian <br...@br...> - 2002-07-17 08:58:28
|
Hi, just wanted to message you, that there is a new importan textfile at bddb/developer docs. I wrote some things we should pay attention. Please add/ change anything, that is in your mind !! Brian |
From: Brian <br...@br...> - 2002-07-16 21:56:09
|
Hi, i don`t want the same html page for end-user and parsing, so there`re will not occur any problem later on. Best is, to use plain text to be parsed: Here an example: Server1 wants an information from Server2, lets say about new beer mats. What server1 knows is, when he queried server2 last time. So he will http request the document: http://server2/data.php?command=showNewBeerMats&date=20020701 server2 answers with plain text: PHPBDDB START Foster||Australien Beer||345423.jpg||20020705||This is the comment|0 Anheuser||Import Beer||test.jpg||20020502||Here is the commen||Testserie PHPBDDB END If you know in which order information are provided you can fetch them to an array and insert them to your database at server1 >I agree that most firewalls and etc. require special configuration to >access server on any SQL port. If that could be possible solution it would >save us a lot of time. :( You will need a dedicated server to do this, to access the database from a host other than localhost is not provided by most of the webhosters. I want a solution that nearly everybody can use. >It means a lot of string parsing but I agree that XML could be a possible >solution. I just took a look at php manual and I think it has enough XML >parsing already built in. XML or plain text files, we need to discuss this. >If it is this way it could become pear-to-pear network. (Just an idea) >Main server could have a list of running clients and that's all. Clients >would update their pear list from server and get XML from each other. This >would cause more traffic than client-server solution but as it was >mentioned before web servers are made for that. Yeah, but this could not be done with PHP only. >I took a look at CVS and I noticed *.inc files. I suggest that we could >better use something like *_inc.php because *.inc files require special >treatment. If no configuration is done to web server they are shown in >plaintext. I have seen folks get hacked because of this.;) You`re right, we will fix this with the code rewrite. >I am kind of new to CVS. I have worked w different systems but CVS is >something I want to learn. Does anyone knows a good place to start with? Well i hope you are using WinCVS or any other GUI. You will find some docs at SF Documentation, or refer to the WinCVS Help Docs. I think it is http://www.cvsgui.org . Brian |
From: Janis P. <jan...@on...> - 2002-07-16 18:52:16
|
Hi! That is true that it is hard to tell how the project will develop and what will be requested. But also I think that planning is very important because there are things that would become unavailable if we didn't took them in account while writing the client front-end. For example if we agree to do HTML parsing in the future we should design HTML so that it would be easily parsed. I agree that most firewalls and etc. require special configuration to access server on any SQL port. If that could be possible solution it would save us a lot of time. :( What I meant w parsing was that if we are using HTML as the data format we also need an HTML parser. It means a lot of string parsing but I agree that XML could be a possible solution. I just took a look at php manual and I think it has enough XML parsing already built in. If it is this way it could become pear-to-pear network. (Just an idea) Main server could have a list of running clients and that's all. Clients would update their pear list from server and get XML from each other. This would cause more traffic than client-server solution but as it was mentioned before web servers are made for that. Now back to the real world... :) I took a look at CVS and I noticed *.inc files. I suggest that we could better use something like *_inc.php because *.inc files require special treatment. If no configuration is done to web server they are shown in plaintext. I have seen folks get hacked because of this.;) I am kind of new to CVS. I have worked w different systems but CVS is something I want to learn. Does anyone knows a good place to start with? Janis --> http://www.one.lv - your number one mobile email service! |
From: Brian <br...@br...> - 2002-07-16 17:19:15
|
TO: php...@li... SUBSCRIBE TO THE LIST IF YOU HAVEN`T DONE YET ! Hi, first i want to stress out, that i want the single server solution to be coded first. After having a release of that, we will decentralize the system, by creating one superhost, and allowing webmasters to implement our solution at their websites. Now some words to your ideas: 3) is my favourite, with some addition/ changes we can discuss later on The way how to reach communication between servers, could only be to do html parsing. This is because most webhosters do not allow to access database from a host different than `localhost` so we do not have the change to use SQL only. We need PHP to interact between the servers. Well it`s not a new protokoll but we`ll have to create a command set, that allows servers to execute database command on each other. For security reasons, this is also the best way because no server could/ need to have write access to the other, they exchange data by parsing maschine readable html sites. We could use XML, or plain textfiles. I do not agree that parsing needs much resources. The webserver does what he is used to do, offer webpages nothing more. If traffic is getting to high, we`ll could add a reload stop. Parsing itself is no intensiv calculation. However our first aim is to code the webfrontend, that we can do some experiments on the subject. I need a working release, that i could distribute this project on some websites - that it becomes more popular and we can see, where changes are needed. I will subdivide the project into smaller pieces (usermanagment, viewing/ browsing function, editing function, etc.) so that we could start coding. See my next mail for more details (which will include some more planning papers) Brian At 14:09 16.07.2002 +0300, Janis Putrams wrote: >Hi! >I am not sure if i have correctly understood but I think that I am getting >there.:) >There would be many individual servers, which deal with their own >information, but we want one "big" that has information about all of them >and keeps them up to date. We can't use just one database because each >individual server has it's privacy. Is that right? >Here are my thoughts about what could be possible solutions. >We can't make pear-to-pear connections so there is basically three solutions: >1) The central server is open to everybody and individual servers update >themselves and central database. >2) Individual servers register with the central server and grant some >(read&write) access to it. So central server from time to time checks all >registered servers and using its privileges updates all individual servers. >3) This one is basically combination of first two. The individual servers >register with the central server and get read privileges to update their >databases. Central server from time to time checks registered users and >updates central database with collected information from user individual >servers. > >The differences are in development and control. >The first one is easy to make but has basically no control of individual >servers. They may update their own databases but not the central. >Second one gives all control to the central database. Not all individual >server administrators would agree with that. >Third one is compromise between first two. Individual servers must >register to update their own information. If central server can't update >information from a registered user the read access to that user is blocked. > >I don't know the exact situation so I really can't decide which could be >the best. Also I don't like the idea of developing some special protocol >or data format for data transfer. Parsing individual server HTML could >take a lot of resources and many errors could occur. I think it would be >best if we could use the same old SQL. :) >Any comments would be great. Looks like there will be a lot of fun. :) Not >an easy one. > >Janis Putrams >p.s >Sorry for my English. Still learning.. > >--> http://www.one.lv - your number one mobile email service! > > >------------------------------------------------------- >This sf.net email is sponsored by: Jabber - The world's fastest growing >real-time communications platform! Don't just IM. Build it in! >http://www.jabber.com/osdn/xim >_______________________________________________ >Phpbddb-dev1 mailing list >Php...@li... >https://lists.sourceforge.net/lists/listinfo/phpbddb-dev1 |
From: Janis P. <jan...@on...> - 2002-07-16 10:56:30
|
Hi! I am not sure if i have correctly understood but I think that I am getting there.:) There would be many individual servers, which deal with their own information, but we want one "big" that has information about all of them and keeps them up to date. We can't use just one database because each individual server has it's privacy. Is that right? Here are my thoughts about what could be possible solutions. We can't make pear-to-pear connections so there is basically three solutions: 1) The central server is open to everybody and individual servers update themselves and central database. 2) Individual servers register with the central server and grant some (read&write) access to it. So central server from time to time checks all registered servers and using its privileges updates all individual servers. 3) This one is basically combination of first two. The individual servers register with the central server and get read privileges to update their databases. Central server from time to time checks registered users and updates central database with collected information from user individual servers. The differences are in development and control. The first one is easy to make but has basically no control of individual servers. They may update their own databases but not the central. Second one gives all control to the central database. Not all individual server administrators would agree with that. Third one is compromise between first two. Individual servers must register to update their own information. If central server can't update information from a registered user the read access to that user is blocked. I don't know the exact situation so I really can't decide which could be the best. Also I don't like the idea of developing some special protocol or data format for data transfer. Parsing individual server HTML could take a lot of resources and many errors could occur. I think it would be best if we could use the same old SQL. :) Any comments would be great. Looks like there will be a lot of fun. :) Not an easy one. Janis Putrams p.s Sorry for my English. Still learning.. --> http://www.one.lv - your number one mobile email service! |
From: Brian <br...@br...> - 2002-07-15 08:19:37
|
Hope you had a nice weekend! Well i agree, that client to client application are hard to create with PHP only. This is not what i want. I prefer the single server solution, but everyone can set up the 'phpBddb' server due this is open source. There are serveral interested websites, dealing with the subject beer mats. Let's say just two of them and i set up a server. Then i want be sure, that they update each other. This could be done by PHP. Therefore every server needs websites, which are maschine readable, like CSV tables. This pages could be fetched by another server manually, or automatically by cronjob. But as you said, our first goal must be the single point solution. Did you configured your CVS client that you can do changes to the code? I tried to tidy up a bit. Do you thing it is better to start new code, or doing changes to my test code? PS: Please subscribe to our mailinglist. Brian At 23:26 14.07.2002 -0500, you wrote: >I was looking over the diagram. I don't understand why there needs to be >more than one at this point at least. one decent server can handle a >very large number of users at once. I suppose that later on we can >create a more distributed cluster of server that all the clients can >connect to to store information on. > >I'm not sure that the idea to use only PHP/Mysql to set up the client to >client applications. PHP is not designed for that, for one it is a >serverside scripting language. it defeats the purpose of client to >client if you have to run the script through a server. > >using Mysql and PHP to build a interactive web service is cool...but I >would think that it would be difficult to run a serverside script on a >client to client basis unless each user was running there own server. >that is unless I'm mistaken... > >David |
From: Brian <br...@br...> - 2002-07-13 09:25:14
|
Moin, i posted my first idea for sitemap of the webfrontend to CVS. I hope to get some additions/ changes from you. When planning of the webfrontend and database structure is finished, we`ll start coding the webfrontend. Brian |
From: Brian <br...@br...> - 2002-07-12 22:49:03
|
>Envelope-to: br...@br... >Subject: Re: information >From: "David C. Haley" <dh...@ho...> >To: Brian <br...@br...> >X-Mailer: Ximian Evolution 1.0.8 >Date: 11 Jul 2002 13:34:54 -0500 > >I'll be access CVS later on today to take a look at all the files. I've >taken a look at the diagram that you sent me along with your last email. >Seems very interesting. It raises some questions in my mind about >structure and design. > >how do you plan on getting together to discuss plans and ideas for the >project (email, chat program like AIM, forums)? > >David > >On Thu, 2002-07-11 at 11:42, Brian wrote: > > Hello David, > > > > the PDF in this mail will provide you some additional information about > the > > phpBddb project. > > The status of the project is between planning and pre-alpha. > > > > I have added you to the developer list, so that you can browse the CVS > more > > comfortable if you like. > > First thing to do, is to discuss the code strukture, find some more > > developers and start coding. > > Up to now, there is another guy interested in helping phpBddb to breath. > > He is used to HTML only, so that i would like to have some PHP wizards in > > the team. > > > > Regards Brian > > irn-bru |
From: Brian <br...@br...> - 2002-07-12 22:49:01
|
>Date: Fri, 12 Jul 2002 10:12:42 +0200 >To: "David C. Haley" <dh...@ho...> >From: Brian <br...@br...> >Subject: Re: information >Bcc: die...@gu... > >Right, there is only one database, with >one table housing "master collection" [we may split this one if it is=20 >getting to large] >one table housing additional user specific collection data [for all users,= =20 >we may split this too] > >Have a look at sql/bddb.sql > >TABLE bddb_bd --> this is where beer mat data is stored (master= collection) >TABLE bddb_serien --> this is where beer mat sets are stored (master= =20 >collection) >TABLE bddb_brau --> this is where Brewery data is stored (master= collection) >TABLE bddb_userbd --> in here is user specific collection data=20 >stored (user collection) >TABLE bddb_trust --> had the idea that users should be able to=20 >trust other users > --> so that more than one user can maintain a=20 > users collection >TABLE bddb_rights --> user/ group rights are set here >TABLE bddb_user --> personalities, login data > >This is what i have done so far, just testing my ideas. First we should=20 >discuss needed/ unneeded tables and their structure. > > ># http://www.phpmyadmin.net/ (download page) ># ># Host: localhost ># Erstellungszeit: 12. Juli 2002 um 09:40 ># Server Version: 3.23.39 ># PHP-Version: 4.0.4pl1 ># Datenbank : `db36460009` ># -------------------------------------------------------- > ># ># Tabellenstruktur f=B3r Tabelle `bddb_bd` ># > >CREATE TABLE bddb_bd ( > ID bigint(6) unsigned zerofill NOT NULL default '000000', > link_brau int(11) NOT NULL default '0', > link_serie int(11) default NULL, > bier tinytext NOT NULL, > ausdatum year(4) default NULL, > form tinytext NOT NULL, > druck tinytext NOT NULL, > kommentar longtext, > bild mediumtext, > bild2 mediumtext, > owner tinytext NOT NULL, > PRIMARY KEY (ID), > UNIQUE KEY ID (ID) >) TYPE=3DMyISAM COMMENT=3D'Bierdeckel Details'; ># -------------------------------------------------------- > ># ># Tabellenstruktur f=B3r Tabelle `bddb_brau` ># > >CREATE TABLE bddb_brau ( > ID smallint(5) unsigned zerofill NOT NULL auto_increment, > brauerei tinytext NOT NULL, > ort tinytext, > anmerk longtext, > ad_brau tinytext, > ad_strasse tinytext, > ad_ plz int(11) default NULL, > ad_ort tinytext, > logo mediumtext, > ad_hp mediumtext, > PRIMARY KEY (ID), > UNIQUE KEY ID (ID) >) TYPE=3DMyISAM COMMENT=3D'Brauerei-Index'; ># -------------------------------------------------------- > ># ># Tabellenstruktur f=B3r Tabelle `bddb_rights` ># > >CREATE TABLE bddb_rights ( > type char(10) NOT NULL default '', > sbyid set('true','false') NOT NULL default 'false', > login set('true','false') NOT NULL default 'false', > vbrau set('true','false') NOT NULL default 'false', > nbrau set('true','false') NOT NULL default 'false', > nseri set('true','false') NOT NULL default '', > nebdl set('true','false') NOT NULL default '', > nuser set('true','false') NOT NULL default 'false', > bbyid set('true','false') NOT NULL default 'false', > PRIMARY KEY (type), > UNIQUE KEY type (type) >) TYPE=3DMyISAM COMMENT=3D'User-Rechtemanagment'; ># -------------------------------------------------------- > ># ># Tabellenstruktur f=B3r Tabelle `bddb_serien` ># > >CREATE TABLE bddb_serien ( > ID mediumint(7) unsigned zerofill NOT NULL auto_increment, > name tinytext NOT NULL, > link_brau int(11) NOT NULL default '0', > bild mediumtext NOT NULL, > beschr longtext, > PRIMARY KEY (ID), > UNIQUE KEY ID (ID) >) TYPE=3DMyISAM COMMENT=3D'Serien Index'; ># -------------------------------------------------------- > ># ># Tabellenstruktur f=B3r Tabelle `bddb_trust` ># > >CREATE TABLE bddb_trust ( > ID bigint(20) NOT NULL default '0', > wer tinytext NOT NULL, > wem tinytext NOT NULL, > PRIMARY KEY (ID) >) TYPE=3DMyISAM; ># -------------------------------------------------------- > ># ># Tabellenstruktur f=B3r Tabelle `bddb_user` ># > >CREATE TABLE bddb_user ( > ID bigint(20) NOT NULL auto_increment, > type set('admin','ops-bd','ops-us','owner','user-t','user') NOT NULL=20 > default 'user', > name tinytext NOT NULL, > vorname tinytext NOT NULL, > email tinytext NOT NULL, > strasse tinytext, > plz varchar(5) default NULL, > ort tinytext, > tel tinytext, > seit timestamp(14) NOT NULL, > nick varchar(10) NOT NULL default '', > pass tinytext NOT NULL, > PRIMARY KEY (ID), > UNIQUE KEY ID (ID), > UNIQUE KEY nick (nick) >) TYPE=3DMyISAM COMMENT=3D'User-Tabelle mit Trustrelationship'; ># -------------------------------------------------------- > ># ># Tabellenstruktur f=B3r Tabelle `bddb_userbd` ># > >CREATE TABLE bddb_userbd ( > ID bigint(6) unsigned zerofill NOT NULL default '000000', > link_brau int(11) NOT NULL default '0', > link_serie int(11) default NULL, > link_bd int(11) NOT NULL default '0', > kommentar longtext, > anzahl mediumint(8) unsigned NOT NULL default '0', > preis decimal(10,0) unsigned default '0', > sort mediumblob, > owner tinytext NOT NULL, > PRIMARY KEY (ID), > UNIQUE KEY ID (ID) >) TYPE=3DMyISAM COMMENT=3D'Useroptionen je BD'; > > >Brian > > > >At 20:54 11.07.2002 -0500, you wrote: >>I'm at -0600 GMT. camping out in Texas at the moment. :) >>feel free to look me up on ICQ @ 21106127 >> >>I looked at the diagram that you sent. from teh look of it you seem to >>have a large dbase that I assume houses a 'master' collection of >>information. with the clients having smaller more personal databases. is >>that right... >> >>David >> >>On Thu, 2002-07-11 at 17:14, Brian wrote: >> > Because of the time difference, i think it is a better idea to have >> > discussions through email/ forum. >> > On the other hand this is no solution for quick discussions. >> > >> > I am available through ICQ at UIN # 66986349 (Bru). So if we could=20 >> arrange >> > this, i want to have the possibility to discuss the further roadmap. >> > What is your time compared to GMT ? >> > >> > Brian >> > >> > >> > At 13:34 11.07.2002 -0500, you wrote: >> > >> > >how do you plan on getting together to discuss plans and ideas for the >> > >project (email, chat program like AIM, forums)? >> > |
From: Brian <br...@br...> - 2002-07-12 22:49:00
|
>Envelope-to: pr...@br... >To: pr...@br... >Subject: dbase design >From: David Haley <kho...@us...> >Date: Fri, 12 Jul 2002 08:32:54 -0700 > >I had a chance to print out the email that you sent >me with all of the table information on it as well as >the design documents that were on sourcefourge. > >I may sound like I keep repeating myself and I'm >sorry if it comes across that way but I'm just trying >to get it all straight in my head. ^_^ > >Now from what I gathered you plan on having one >database house all the information adn then using >php to create a frontend for it. that in itself is pretty >darn easy to do. of course things like login >procedures, registration, email, etc. complicate >things just a little but it's nothing that can't be >easily added on. > >David |
From: Brian <br...@br...> - 2002-07-12 22:26:48
|