Menu
▾
▴
bobs-devel — Developer mailing list
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(23) |
Jul
(37) |
Aug
(13) |
Sep
(33) |
Oct
(37) |
Nov
(1) |
Dec
(12) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(1) |
Feb
(7) |
Mar
(34) |
Apr
(41) |
May
(20) |
Jun
(13) |
Jul
(2) |
Aug
(20) |
Sep
(13) |
Oct
(8) |
Nov
(15) |
Dec
(32) |
| 2004 |
Jan
(65) |
Feb
(20) |
Mar
(29) |
Apr
(27) |
May
(37) |
Jun
(9) |
Jul
(7) |
Aug
(6) |
Sep
(16) |
Oct
|
Nov
(1) |
Dec
(18) |
| 2005 |
Jan
(18) |
Feb
(3) |
Mar
|
Apr
(14) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
(23) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(13) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Rene R. <re...@gr...> - 2002-09-07 20:01:45
|
I'm trying to get bobs working again but I seem to have some problems with the configurations. smb_share doesn't seem to be exported when I open the user interface. I'm looking into this. -Rene On Mon, 2002-09-02 at 14:37, Rene Rask wrote: > > I just used rFastTemplate for the html in some other stuff I just did. > That should be nice and easy to use in bobs as well. > > This is a link to the tutorial. > http://www.astrofoto.org/people/roland/rFT/tutorial.html > > I think I might want to use that anyway in some of the other stuff. > > If you can figure out how to uncommit a cvs commit, feel free to uncommit > the changes I made that broke cvs. > > I'll try to figure out how to make a branch for the new stuff I'm working on. > > -Rene > > > > I finished breaking up class_config into three classes. These are the > > variables and functions of each class. I hope I didn't break much (or > > anything). I was very careful, but I couldn't do good testing because > > some of it was already broken. > > > > class config > > var $admin_pwd; > > var $sys_conf; > > var $server_defs; > > var $serverdir = ''; > > function config () > > function get_siteroot() > > > > class admin extends config > > var $admin_ok = 'no'; > > function check_admin ($password) > > > > class server extends config > > var $login_ok = 'no'; > > var $servers = ''; > > var $config = ''; > > function server() > > function login ($login_server, $login_name, $login_password) > > function set_config ($set_server) > > function check_active () > > function check_day () > > function get_server_defs() > > function init_new_server($server, $share) > > function get_server_list() > > function commit_changes ($mode) > > > > I'm planning to start on the user/group/server access screens next. I'm > > going to make another class like class_list.php for the access screens. > > I also need to figure out what to do with some of the html parsing in > > admin.php and gui.pinc. > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Bobs-devel mailing list > Bob...@li... > https://lists.sourceforge.net/lists/listinfo/bobs-devel |
|
From: Joe z. <jz...@at...> - 2002-09-01 23:29:04
|
I believe you have to download the prior version you want, then commit that. I don't think there's an "uncommit". Joe Rene Rask wrote: >... > >If you can figure out how to uncommit a cvs commit, feel free to uncommit >the changes I made that broke cvs. > >I'll try to figure out how to make a branch for the new stuff I'm working on. > >-Rene > > > > |
|
From: Rene R. <re...@gr...> - 2002-09-01 12:35:48
|
I just used rFastTemplate for the html in some other stuff I just did. That should be nice and easy to use in bobs as well. This is a link to the tutorial. http://www.astrofoto.org/people/roland/rFT/tutorial.html I think I might want to use that anyway in some of the other stuff. If you can figure out how to uncommit a cvs commit, feel free to uncommit the changes I made that broke cvs. I'll try to figure out how to make a branch for the new stuff I'm working on. -Rene > I finished breaking up class_config into three classes. These are the > variables and functions of each class. I hope I didn't break much (or > anything). I was very careful, but I couldn't do good testing because > some of it was already broken. > > class config > var $admin_pwd; > var $sys_conf; > var $server_defs; > var $serverdir = ''; > function config () > function get_siteroot() > > class admin extends config > var $admin_ok = 'no'; > function check_admin ($password) > > class server extends config > var $login_ok = 'no'; > var $servers = ''; > var $config = ''; > function server() > function login ($login_server, $login_name, $login_password) > function set_config ($set_server) > function check_active () > function check_day () > function get_server_defs() > function init_new_server($server, $share) > function get_server_list() > function commit_changes ($mode) > > I'm planning to start on the user/group/server access screens next. I'm > going to make another class like class_list.php for the access screens. > I also need to figure out what to do with some of the html parsing in > admin.php and gui.pinc. |
|
From: Joe z. <jz...@at...> - 2002-09-01 03:43:28
|
I finished breaking up class_config into three classes. These are the
variables and functions of each class. I hope I didn't break much (or
anything). I was very careful, but I couldn't do good testing because
some of it was already broken.
class config
var $admin_pwd;
var $sys_conf;
var $server_defs;
var $serverdir = '';
function config ()
function get_siteroot()
class admin extends config
var $admin_ok = 'no';
function check_admin ($password)
class server extends config
var $login_ok = 'no';
var $servers = '';
var $config = '';
function server()
function login ($login_server, $login_name, $login_password)
function set_config ($set_server)
function check_active ()
function check_day ()
function get_server_defs()
function init_new_server($server, $share)
function get_server_list()
function commit_changes ($mode)
I'm planning to start on the user/group/server access screens next. I'm
going to make another class like class_list.php for the access screens.
I also need to figure out what to do with some of the html parsing in
admin.php and gui.pinc.
|
|
From: Joe z. <jz...@at...> - 2002-08-29 03:32:08
|
Well, good. I was worried you might have had a headache relapse or something. I've been making good progress. When you get around to it, check out the list.php in the doc directory (read the instructions at the top first). Joe Rene wrote: >Hi again > >Sorry for my complete lack of replies. I've been strung out with servers >dying around me, moving and other stuff. I expect to get started on bobs >again this week. > >René > >If only this chaos could restrain itself to a few hours each day ;) > > >On Sat, 2002-08-24 at 23:09, Joe zacky wrote: > > >>I got the admin interface doing everything I planned on except for the >>user/group access. It's pretty messy, but I plan to move much of the >>code to new gui functions and html classes. I stripped out the html >>output from class_config.php and put some of it in gui.pinc and >>admin.php. Now I'm going to work on new classes for html output that I >>can use in the admin and user/group interfaces. >> >>I'm considering redoing the class structure as defined in my August 11 >>email, but I'm going to work on the html classes first. >> >>Look at the cvs comments for more details. >> >> >> >>------------------------------------------------------- >>This sf.net email is sponsored by: OSDN - Tired of that same old >>cell phone? Get a new here for FREE! >>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 >>_______________________________________________ >>Bobs-devel mailing list >>Bob...@li... >>https://lists.sourceforge.net/lists/listinfo/bobs-devel >> >> > > > > >------------------------------------------------------- >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 >_______________________________________________ >Bobs-devel mailing list >Bob...@li... >https://lists.sourceforge.net/lists/listinfo/bobs-devel > > > |
|
From: Rene <re...@gr...> - 2002-08-28 08:09:03
|
Hi again Sorry for my complete lack of replies. I've been strung out with servers dying around me, moving and other stuff. I expect to get started on bobs again this week. Ren=E9 If only this chaos could restrain itself to a few hours each day ;) On Sat, 2002-08-24 at 23:09, Joe zacky wrote: > I got the admin interface doing everything I planned on except for the=20 > user/group access. It's pretty messy, but I plan to move much of the=20 > code to new gui functions and html classes. I stripped out the html=20 > output from class_config.php and put some of it in gui.pinc and=20 > admin.php. Now I'm going to work on new classes for html output that I=20 > can use in the admin and user/group interfaces. >=20 > I'm considering redoing the class structure as defined in my August 11=20 > email, but I'm going to work on the html classes first. >=20 > Look at the cvs comments for more details. >=20 >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390 > _______________________________________________ > Bobs-devel mailing list > Bob...@li... > https://lists.sourceforge.net/lists/listinfo/bobs-devel |
|
From: Joe z. <jz...@at...> - 2002-08-24 21:09:34
|
I got the admin interface doing everything I planned on except for the user/group access. It's pretty messy, but I plan to move much of the code to new gui functions and html classes. I stripped out the html output from class_config.php and put some of it in gui.pinc and admin.php. Now I'm going to work on new classes for html output that I can use in the admin and user/group interfaces. I'm considering redoing the class structure as defined in my August 11 email, but I'm going to work on the html classes first. Look at the cvs comments for more details. |
|
From: Joe z. <jz...@at...> - 2002-08-15 04:29:19
|
I don't understand. I was thinking a plugin would be something that gets passed pre-defined parameters and returns pre-defined parameters, whether it be a call to an API or a class based on a pre-defined base plugin class. The details of how the plugin works should be of no concern to bobs - except for any pre-defined constraints there may be. I haven't tried to figure out how you're using plugins, because I've got my head buried in the admin config. I don't have any experience with pc based plugins either. And I don't understand what the "data layer" would be. So, I guess that's no help. Joe Rene wrote: >I'm still trying to decide whether I think an API interface would be a >good idea or if "plugins" should be selfcontained. > >I'm trying to seperate as much as possible to a form a base >functionality. Then plugins can use that and add to it as needed. > >What bothers me is that plugins cannot extend each other. This to is the >key problem. Do I just say "fine, so be it" or do I restructure the >whole thing until I find a way? >In the current state a plugin would need to provide an API to be usefull >to other plugins. > >Taking the fast path now would be easy, but later on it might prove more >work if things need to change. > >There are 3 layers of separation in what we've done so far. >-- Admin layer > configuration/login >-- Base layer > common functionality >-- Plugin layer > specific functionality > >If another layer should be added it would probably be a data layer >between plugins and base. That would enable plugins to use each others >functionality better. But it would also require extensive work to define >how data is passed and what type of data are passed. > >How do you feel about this? I don't really have the experience required >to define the data layer and its inner workings. >If you are experienced in that area we could work together on it. > >-Rene > > > > > >On Mon, 2002-08-12 at 08:25, Joe zacky wrote: > > >>Rene wrote: >> >> >> >>>This looks fine to me. >>>The way I think of it is that config/admin classes end up passing an >>>array to the "base" class which contains all configuration settings of >>>the active server. >>> >>> >>> >>I'm trying to think of the "objects" involved. Site configuration >>(config object), server configuration (server object), List of servers >>(serverlist class), administrator login (admin object), user logins >>(user, group, and access classes), and screen functions like html output >>(gui class). >> >> >> >>>I hardcoded the config in the example I put up. I just need to fit in >>>the real stuff you've been working on. >>> >>> >>> >>> >>I think my stuff's ready enough for you to use now. I have half a dozen >>more small changes to make and some code review/cleanup before another >>checkin. The class reorganization will take more time. I've been using >>SourceNavigator as my editor. It has a nice 'grep' function that >>searches all the source code in the project. >> >> >> >>>So in the end the only communication between admin/config/login and the >>>rest of bobs is an array with the configuration settings. >>> >>> >>> >>> >>The array(s) and functions in the "server" object will be basically what >>the "config" class is now. >> >>Joe >> >> >> >>>-Rene >>> >>>On Sun, 2002-08-11 at 22:15, Joe zacky wrote: >>> >>> >>> >>> >>>>Now that I've gotten familiar with the admin interface and config class, >>>>I feel like you - I want to rewrite the classes. I've been reading a lot >>>>in the php manual and examples and I think a single server definition >>>>should be an object (class). A serverlist class could extend the server >>>>class. All the classes could be based on a simple config class that just >>>>basically stores the siteroot and server directory. >>>> >>>>Here's my proposed class structure. Please let me know what you think. >>>> >>>>------------------------------------------------------ >>>>BOBS proposed class structure >>>> >>>>CLASS VARIABLES CLASS FUNCTIONS >>>> >>>> config >>>>siteroot config (constructor) >>>>serverdir >>>> admin extends config >>>>admin_ok check_admin >>>>admin_pwd >>>> server extends config >>>> server (constructor) - inits >>>>as new server >>>>server_defs[] get_ini - get .ini file into >>>>config >>>>login_ok check_active >>>>new check_day >>>>config login >>>> commit_changes >>>> serverlist extends server >>>>servers[] set_config >>>>current_server set_current >>>> get_current >>>>------------------------------------------------------ >>>> >>>>I think the check_rules and parsing should be in a class too, but I'm >>>>not sure how to fit it in yet. Maybe an edit class and a GUI class that >>>>extend server? >>>> >>>>Joe >>>> >>>>P.S. I could finish the functionality the way it is if you want to get a >>>>working version out there before rewriting the classes. Just let me know. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >> >>------------------------------------------------------- >>This sf.net email is sponsored by:ThinkGeek >>Welcome to geek heaven. >>http://thinkgeek.com/sf >>_______________________________________________ >>Bobs-devel mailing list >>Bob...@li... >>https://lists.sourceforge.net/lists/listinfo/bobs-devel >> >> > > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Bobs-devel mailing list >Bob...@li... >https://lists.sourceforge.net/lists/listinfo/bobs-devel > > > |
|
From: Rene <re...@gr...> - 2002-08-12 07:44:48
|
I'm still trying to decide whether I think an API interface would be a good idea or if "plugins" should be selfcontained. I'm trying to seperate as much as possible to a form a base functionality. Then plugins can use that and add to it as needed. What bothers me is that plugins cannot extend each other. This to is the key problem. Do I just say "fine, so be it" or do I restructure the whole thing until I find a way? In the current state a plugin would need to provide an API to be usefull to other plugins. Taking the fast path now would be easy, but later on it might prove more work if things need to change. There are 3 layers of separation in what we've done so far. -- Admin layer configuration/login -- Base layer common functionality -- Plugin layer specific functionality If another layer should be added it would probably be a data layer between plugins and base. That would enable plugins to use each others functionality better. But it would also require extensive work to define how data is passed and what type of data are passed. How do you feel about this? I don't really have the experience required to define the data layer and its inner workings. If you are experienced in that area we could work together on it. -Rene On Mon, 2002-08-12 at 08:25, Joe zacky wrote: > Rene wrote: > > >This looks fine to me. > >The way I think of it is that config/admin classes end up passing an > >array to the "base" class which contains all configuration settings of > >the active server. > > > I'm trying to think of the "objects" involved. Site configuration > (config object), server configuration (server object), List of servers > (serverlist class), administrator login (admin object), user logins > (user, group, and access classes), and screen functions like html output > (gui class). > > > > >I hardcoded the config in the example I put up. I just need to fit in > >the real stuff you've been working on. > > > > > I think my stuff's ready enough for you to use now. I have half a dozen > more small changes to make and some code review/cleanup before another > checkin. The class reorganization will take more time. I've been using > SourceNavigator as my editor. It has a nice 'grep' function that > searches all the source code in the project. > > >So in the end the only communication between admin/config/login and the > >rest of bobs is an array with the configuration settings. > > > > > The array(s) and functions in the "server" object will be basically what > the "config" class is now. > > Joe > > >-Rene > > > >On Sun, 2002-08-11 at 22:15, Joe zacky wrote: > > > > > >>Now that I've gotten familiar with the admin interface and config class, > >>I feel like you - I want to rewrite the classes. I've been reading a lot > >>in the php manual and examples and I think a single server definition > >>should be an object (class). A serverlist class could extend the server > >>class. All the classes could be based on a simple config class that just > >>basically stores the siteroot and server directory. > >> > >>Here's my proposed class structure. Please let me know what you think. > >> > >>------------------------------------------------------ > >>BOBS proposed class structure > >> > >>CLASS VARIABLES CLASS FUNCTIONS > >> > >> config > >>siteroot config (constructor) > >>serverdir > >> admin extends config > >>admin_ok check_admin > >>admin_pwd > >> server extends config > >> server (constructor) - inits > >>as new server > >>server_defs[] get_ini - get .ini file into > >>config > >>login_ok check_active > >>new check_day > >>config login > >> commit_changes > >> serverlist extends server > >>servers[] set_config > >>current_server set_current > >> get_current > >>------------------------------------------------------ > >> > >>I think the check_rules and parsing should be in a class too, but I'm > >>not sure how to fit it in yet. Maybe an edit class and a GUI class that > >>extend server? > >> > >>Joe > >> > >>P.S. I could finish the functionality the way it is if you want to get a > >>working version out there before rewriting the classes. Just let me know. > >> > >> > >> > >> > >> > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Bobs-devel mailing list > Bob...@li... > https://lists.sourceforge.net/lists/listinfo/bobs-devel |
|
From: Joe z. <jz...@at...> - 2002-08-12 06:25:35
|
Rene wrote: >This looks fine to me. >The way I think of it is that config/admin classes end up passing an >array to the "base" class which contains all configuration settings of >the active server. > I'm trying to think of the "objects" involved. Site configuration (config object), server configuration (server object), List of servers (serverlist class), administrator login (admin object), user logins (user, group, and access classes), and screen functions like html output (gui class). > >I hardcoded the config in the example I put up. I just need to fit in >the real stuff you've been working on. > > I think my stuff's ready enough for you to use now. I have half a dozen more small changes to make and some code review/cleanup before another checkin. The class reorganization will take more time. I've been using SourceNavigator as my editor. It has a nice 'grep' function that searches all the source code in the project. >So in the end the only communication between admin/config/login and the >rest of bobs is an array with the configuration settings. > > The array(s) and functions in the "server" object will be basically what the "config" class is now. Joe >-Rene > >On Sun, 2002-08-11 at 22:15, Joe zacky wrote: > > >>Now that I've gotten familiar with the admin interface and config class, >>I feel like you - I want to rewrite the classes. I've been reading a lot >>in the php manual and examples and I think a single server definition >>should be an object (class). A serverlist class could extend the server >>class. All the classes could be based on a simple config class that just >>basically stores the siteroot and server directory. >> >>Here's my proposed class structure. Please let me know what you think. >> >>------------------------------------------------------ >>BOBS proposed class structure >> >>CLASS VARIABLES CLASS FUNCTIONS >> >> config >>siteroot config (constructor) >>serverdir >> admin extends config >>admin_ok check_admin >>admin_pwd >> server extends config >> server (constructor) - inits >>as new server >>server_defs[] get_ini - get .ini file into >>config >>login_ok check_active >>new check_day >>config login >> commit_changes >> serverlist extends server >>servers[] set_config >>current_server set_current >> get_current >>------------------------------------------------------ >> >>I think the check_rules and parsing should be in a class too, but I'm >>not sure how to fit it in yet. Maybe an edit class and a GUI class that >>extend server? >> >>Joe >> >>P.S. I could finish the functionality the way it is if you want to get a >>working version out there before rewriting the classes. Just let me know. >> >> >> >> >> |
|
From: Rene <re...@gr...> - 2002-08-12 04:07:20
|
This looks fine to me. The way I think of it is that config/admin classes end up passing an array to the "base" class which contains all configuration settings of the active server. I hardcoded the config in the example I put up. I just need to fit in the real stuff you've been working on. So in the end the only communication between admin/config/login and the rest of bobs is an array with the configuration settings. -Rene On Sun, 2002-08-11 at 22:15, Joe zacky wrote: > Now that I've gotten familiar with the admin interface and config class, > I feel like you - I want to rewrite the classes. I've been reading a lot > in the php manual and examples and I think a single server definition > should be an object (class). A serverlist class could extend the server > class. All the classes could be based on a simple config class that just > basically stores the siteroot and server directory. > > Here's my proposed class structure. Please let me know what you think. > > ------------------------------------------------------ > BOBS proposed class structure > > CLASS VARIABLES CLASS FUNCTIONS > > config > siteroot config (constructor) > serverdir > admin extends config > admin_ok check_admin > admin_pwd > server extends config > server (constructor) - inits > as new server > server_defs[] get_ini - get .ini file into > config > login_ok check_active > new check_day > config login > commit_changes > serverlist extends server > servers[] set_config > current_server set_current > get_current > ------------------------------------------------------ > > I think the check_rules and parsing should be in a class too, but I'm > not sure how to fit it in yet. Maybe an edit class and a GUI class that > extend server? > > Joe > > P.S. I could finish the functionality the way it is if you want to get a > working version out there before rewriting the classes. Just let me know. > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Bobs-devel mailing list > Bob...@li... > https://lists.sourceforge.net/lists/listinfo/bobs-devel |
|
From: Joe z. <jz...@at...> - 2002-08-11 20:15:21
|
Now that I've gotten familiar with the admin interface and config class,
I feel like you - I want to rewrite the classes. I've been reading a lot
in the php manual and examples and I think a single server definition
should be an object (class). A serverlist class could extend the server
class. All the classes could be based on a simple config class that just
basically stores the siteroot and server directory.
Here's my proposed class structure. Please let me know what you think.
------------------------------------------------------
BOBS proposed class structure
CLASS VARIABLES CLASS FUNCTIONS
config
siteroot config (constructor)
serverdir
admin extends config
admin_ok check_admin
admin_pwd
server extends config
server (constructor) - inits
as new server
server_defs[] get_ini - get .ini file into
config
login_ok check_active
new check_day
config login
commit_changes
serverlist extends server
servers[] set_config
current_server set_current
get_current
------------------------------------------------------
I think the check_rules and parsing should be in a class too, but I'm
not sure how to fit it in yet. Maybe an edit class and a GUI class that
extend server?
Joe
P.S. I could finish the functionality the way it is if you want to get a
working version out there before rewriting the classes. Just let me know.
|
|
From: Joe z. <jz...@at...> - 2002-08-10 23:09:55
|
I got the admin interface working just enough that you can create server definitions and modify them. It still needs much work. I'm planning to break out the html code from class_config and put it in admin.php or class_admin.php. I followed your "config editor suggestions" email from July 14th. The server definitions are now in config.php. The share input fields will show based on which backup/restore method you choose. I simplified the rules a bit to make life easier on myself. Let me know what you think. The following is a list of some of the things I did and still need to do: ------------------------------------------------------------------------------------------- Admin Interface: done - Show only one password (temporarily) - will be moving user/group/password to another screen. done - Fixup menu buttons. Create images with text, similar to the BOBS user menu. done - Replace server.definitions.ini. done - Add lots of comments. done - class_config.php - Add/change functions as specified in config editor suggestions email July 14. Remove server.definitions.ini from CVS. Take html stuff out of class_config.php. Possibly create a class_admin.php. Classes should be simple. "special" fields: run days - display as checkboxes. Allow for parms to smb, like user id and password per share. Headings "Server: xxx Share: xxx" in edit server details and forward. Edit server modes support - protect fields in delete mode. Change button to "Delete". Show mode on screen. Make "Delete" actually delete. Compare actual screens to design screens and fixup some. Like back/next buttons. Change icon "login" to "login/logout" Redisplay "edit server details" until no more changes and all edits passed. Use saved-config array to compare? wish list item: Allow to search/select from list of network computers (based on subnet) and/or list of shares (nfs, rsync, smb) on the computer. Add input field edits. Add message routines New file and interface for user (and group) administration. Cron: cron/check_loop is hardcoded. create 'make install_cron' INSTALL: Add more instructions on how to uninstall, because 'make uninstall' won't necessarily remove all the files and directories. ------------------------------------------------------------------------------------------- Joe |
|
From: Joe z. <jz...@at...> - 2002-08-06 06:45:38
|
You've been busy. I tried out your tarball. It shows me a directory tree in the left frame that expands and contracts and a listing of arrays in the right frame. I took a brief look at some of the code, I don't pretend to understand it. I see you've got the plugins going. I also took a look at class_tree.php. I know how difficult it is to work with directory trees, expanding and collapsing them, because I wrote a c++ program to do that. Judging by the function names in class_tree.php, it looks like your doing a good job at keeping the class functions simple and sensible. I gave up on my c++ tree class because it got out of control - everything I added made it more complicated, rather than simplifying things. I'm very pleased with myself. I got the edit_server and check_rules working so the page redisplays based on the dependencies. Once I get it to write to the server .ini config files, I'll check it in, before I add the user security screens. I'm eager to show it to you. - Joe Rene wrote: >I've put up a tarball with my latest work: >http://grain.dk/bobs/bobs.tgz > >Just a simple self-contained example. (with sample databases) >Please have a look if you have the time. > >It expects files to be places in /var/www/html/bobs >If they are not placed there, edit the servers/testserver.php >Just change the line with the path to a correct one. > >The file structure has changed from the current layout. I'm splitting >and moving classes when I see a reason to do it. > >-Rene > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Bobs-devel mailing list >Bob...@li... >https://lists.sourceforge.net/lists/listinfo/bobs-devel > > > |
|
From: Rene <re...@gr...> - 2002-08-05 03:42:55
|
I've put up a tarball with my latest work: http://grain.dk/bobs/bobs.tgz Just a simple self-contained example. (with sample databases) Please have a look if you have the time. It expects files to be places in /var/www/html/bobs If they are not placed there, edit the servers/testserver.php Just change the line with the path to a correct one. The file structure has changed from the current layout. I'm splitting and moving classes when I see a reason to do it. -Rene |
|
From: Rene <re...@gr...> - 2002-08-04 16:19:34
|
I'm not touching the config or admin classes. But I started from scratch yet again. This time things are starting to work with oop. Then only things that may need to be done to the administration class is adding more configuration options. (I hope that is all it takes) I'm not including any admin or config parts yet. I hardcode them and try to make it possible to plug in your contributions when its ready. - Rene __Back to making objects .. and moving stuff around. On Sun, 2002-08-04 at 08:39, Joe zacky wrote: > My experience with OOP is that it's a different way of thinking. I like > the idea of OOP in general, but it's easy for experienced programmers to > use it incorrectly because they're used to thinking a certain way. I > briefly looked at Eclipse, but I'm too much into admin.php right now to > take time to read about it. > > I'm understanding class_config now and things are starting to fall into > place. Today I added lots of comments to help me understand what it's > doing and where functions are called from. I've got the server > definitions stored in $this->config and the new server fields > initialized from the definitions. Next I'll be working on the parsing > and rules. > > I'm pretty much rewriting admin.php, and class_config.php will be > heavily modified - so please don't make any big changes to > class_config.php until I've checked it in. > > -- Joe > > Rene Rask wrote: > > >Hi > > > >I've been trying really hard to understand OOP and how to use it. > > > >I was pointed to a oop system called Eclipse. > >Heres a link to it. > >http://www.students.cs.uu.nl/people/voostind/eclipse/index.php > > > >I'm going to base my studies on that and try to implement something that > >we can use in BOBS. > > > >Take a look at it if you have the time. > > > >Hope you are having less problems with the admin pages ;-) > > > >Rene > > > > > > > > > >------------------------------------------------------- > >This sf.net email is sponsored by: Dice - The leading online job board > >for high-tech professionals. Search and apply for tech jobs today! > >http://seeker.dice.com/seeker.epl?rel_code=31 > >_______________________________________________ > >Bobs-devel mailing list > >Bob...@li... > >https://lists.sourceforge.net/lists/listinfo/bobs-devel > > > > > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Bobs-devel mailing list > Bob...@li... > https://lists.sourceforge.net/lists/listinfo/bobs-devel |
|
From: Joe z. <jz...@at...> - 2002-08-04 06:40:07
|
My experience with OOP is that it's a different way of thinking. I like the idea of OOP in general, but it's easy for experienced programmers to use it incorrectly because they're used to thinking a certain way. I briefly looked at Eclipse, but I'm too much into admin.php right now to take time to read about it. I'm understanding class_config now and things are starting to fall into place. Today I added lots of comments to help me understand what it's doing and where functions are called from. I've got the server definitions stored in $this->config and the new server fields initialized from the definitions. Next I'll be working on the parsing and rules. I'm pretty much rewriting admin.php, and class_config.php will be heavily modified - so please don't make any big changes to class_config.php until I've checked it in. -- Joe Rene Rask wrote: >Hi > >I've been trying really hard to understand OOP and how to use it. > >I was pointed to a oop system called Eclipse. >Heres a link to it. >http://www.students.cs.uu.nl/people/voostind/eclipse/index.php > >I'm going to base my studies on that and try to implement something that >we can use in BOBS. > >Take a look at it if you have the time. > >Hope you are having less problems with the admin pages ;-) > >Rene > > > > >------------------------------------------------------- >This sf.net email is sponsored by: Dice - The leading online job board >for high-tech professionals. Search and apply for tech jobs today! >http://seeker.dice.com/seeker.epl?rel_code=31 >_______________________________________________ >Bobs-devel mailing list >Bob...@li... >https://lists.sourceforge.net/lists/listinfo/bobs-devel > > > |
|
From: Rene R. <re...@gr...> - 2002-07-31 22:17:56
|
Hi I've been trying really hard to understand OOP and how to use it. I was pointed to a oop system called Eclipse. Heres a link to it. http://www.students.cs.uu.nl/people/voostind/eclipse/index.php I'm going to base my studies on that and try to implement something that we can use in BOBS. Take a look at it if you have the time. Hope you are having less problems with the admin pages ;-) Rene |
|
From: Rene <re...@gr...> - 2002-07-27 11:19:21
|
Thats right. But if you feel that server.definitions.ini should stay, thats fine with me. Rene On Sat, 2002-07-27 at 09:01, Joe zacky wrote: > In emails July 14th, you described how to modify class_config.php and > config.php to get rid of server.definitions.ini and use php instead. > We're just getting rid of server.definitions.ini, not the actual defined > servers like testserver.share.ini, right? > > Joe > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Bobs-devel mailing list > Bob...@li... > https://lists.sourceforge.net/lists/listinfo/bobs-devel |
|
From: Joe z. <jz...@at...> - 2002-07-27 07:01:38
|
In emails July 14th, you described how to modify class_config.php and config.php to get rid of server.definitions.ini and use php instead. We're just getting rid of server.definitions.ini, not the actual defined servers like testserver.share.ini, right? Joe |
|
From: Rene <re...@gr...> - 2002-07-25 09:12:13
|
On Thu, 2002-07-25 at 06:46, Joe zacky wrote: > I'm breaking up admin.php using several include files. Most of them > should be a mix of php and html. They're not classes. > > What file name extension should I give them, php? pinc? ...? > > What include directory should I put them in, htmlinc? inc? winc? Just use the extension that you feel makes sense. I'm trying to work out a new structure. htmlinc is retired. I made a mistake by including it in the first place. In related news. I'm still working on a grand restructuring. There are some issues with php and classes that I'm trying to figure out before I make a more precise layout description. Rene > > Joe > > > > > > ------------------------------------------------------- > 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 > _______________________________________________ > Bobs-devel mailing list > Bob...@li... > https://lists.sourceforge.net/lists/listinfo/bobs-devel |
|
From: Joe z. <jz...@at...> - 2002-07-25 04:46:58
|
I'm breaking up admin.php using several include files. Most of them should be a mix of php and html. They're not classes. What file name extension should I give them, php? pinc? ...? What include directory should I put them in, htmlinc? inc? winc? Joe |
|
From: Joe z. <jz...@at...> - 2002-07-25 00:58:55
|
Excellent. That should make things more modular and easy to work with. I'm getting ready to start php coding the admin interface. I'm looking forward to working with classes in php, never done that. Joe Rene wrote: >Since I'm breaking things right now, I might as well go all the way. I'm >ripping out the parts that generate scripts. They are put in a seperate >dir and will be used as templates. > >I'll try to make a map of what I think should go where and post it to >the list. > >-Rene > > > >On Tue, 2002-07-23 at 07:22, Rene wrote: > > >>I updated the cvs. >> >>Updates include: >>1. new database handling >>2. cmdloop now handling different types of scripts. >>3. dir trees are generated on backup and saved as serialized files. >> >>Restore and search are broken for now. >> >>I'm working on how to add files to the restore queue. Dirs are added but >>files are currently not. This affects the way current and incremental >>works so expect some changes there. >> >>If you have any large indexes (like 100.000+ files) you should notice a >>speed improvement while loading the dir trees. >> >>-Rene >> >> >> >>------------------------------------------------------- >>This sf.net email is sponsored by:ThinkGeek >>Welcome to geek heaven. >>http://thinkgeek.com/sf >>_______________________________________________ >>Bobs-devel mailing list >>Bob...@li... >>https://lists.sourceforge.net/lists/listinfo/bobs-devel >> >> > > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Bobs-devel mailing list >Bob...@li... >https://lists.sourceforge.net/lists/listinfo/bobs-devel > > > |
|
From: Rene <re...@gr...> - 2002-07-23 12:10:47
|
Since I'm breaking things right now, I might as well go all the way. I'm ripping out the parts that generate scripts. They are put in a seperate dir and will be used as templates. I'll try to make a map of what I think should go where and post it to the list. -Rene On Tue, 2002-07-23 at 07:22, Rene wrote: > I updated the cvs. > > Updates include: > 1. new database handling > 2. cmdloop now handling different types of scripts. > 3. dir trees are generated on backup and saved as serialized files. > > Restore and search are broken for now. > > I'm working on how to add files to the restore queue. Dirs are added but > files are currently not. This affects the way current and incremental > works so expect some changes there. > > If you have any large indexes (like 100.000+ files) you should notice a > speed improvement while loading the dir trees. > > -Rene > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Bobs-devel mailing list > Bob...@li... > https://lists.sourceforge.net/lists/listinfo/bobs-devel |
|
From: Rene <re...@gr...> - 2002-07-23 05:30:45
|
I updated the cvs. Updates include: 1. new database handling 2. cmdloop now handling different types of scripts. 3. dir trees are generated on backup and saved as serialized files. Restore and search are broken for now. I'm working on how to add files to the restore queue. Dirs are added but files are currently not. This affects the way current and incremental works so expect some changes there. If you have any large indexes (like 100.000+ files) you should notice a speed improvement while loading the dir trees. -Rene |
2 messages has been excluded from this view by a project administrator.
