Menu
▾
▴
phpwebsite-developers
|
From: Matthew M. <ma...@tu...> - 2007-01-03 13:37:08
|
Good morning. I am looking for feedback on how the core and modules should be distributed. Initially, modules untarred to their own directory. For example, blog_1_3_4.tgz would untar as the directory blog/. This was confusing some people so I changed it to mod/module_name so they could be untarred in the root installation. As for the core, some people are untarring that distro into the core directory when, in fact, it needs to be decompressed and copied into the root. How would you prefer this be done? How would you like the modules and core to untar? When decompressed, what should the directories be named? Is "core" a misleading name for the base files of phpwebsite? Any advice would be appreciated. -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
|
From: Verdon V. <ve...@ve...> - 2007-01-03 13:54:27
|
Morning :) On 3-Jan-07, at 8:27 AM, Matthew McNaney wrote: > Good morning. > > I am looking for feedback on how the core and modules should be > distributed. > > Initially, modules untarred to their own directory. For example, > blog_1_3_4.tgz would untar as the directory blog/. > > This was confusing some people so I changed it to mod/module_name so > they could be untarred in the root installation. Either of these is fine and intuitive for me, but I think mod/ module_name seems a more common sort of convention. The only problem this might cause is that any 3rd-party mods from the phpws-comm project will not follow this convention and that could lead to confusion for new users. > > As for the core, some people are untarring that distro into the core > directory when, in fact, it needs to be decompressed and copied > into the > root. > > How would you prefer this be done? How would you like the modules and > core to untar? When decompressed, what should the directories be > named? > Is "core" a misleading name for the base files of phpwebsite? I must admit to being slightly confused by this the first time. I too thought that 'core' meant things in the core directory only. It didn't take me long to realize that my assumption was wrong, but I can see the confusion :) Perhaps the word 'core' should be reserved for things in the core dir and some other term used for core files not in the core dir ;-) > > Any advice would be appreciated. Ultimately, it doesn't matter what convention you choose, someone will misunderstand it. The most common convention that I see in other projects is that all updates and patches and add-ons can be expanded into the root dir and the appropriate dir/file structure is reflected in the update/patch/ add-on. salut, verdon |
|
From: Shaun M. <sh...@ae...> - 2007-01-04 11:53:35
|
On 3 Jan 2007, at 13:27, Matthew McNaney wrote: > Good morning. > > I am looking for feedback on how the core and modules should be > distributed. > > Initially, modules untarred to their own directory. For example, > blog_1_3_4.tgz would untar as the directory blog/. > I'd prefer that as then it's less likely I or someone else doesn't overwrite the root directory. Certainly from the phpws-comm project, most modules unpack to module-vn.n.n directories and are then moved in but you usually work in /mod not root That in itself confuses some people as they often don't rename the module-vn.n.n directory and end up with two modules of the same name installed from different directories. Maybe it's something we can look at enhancing with boost so the process is web based entirely? Use PEAR's Archive_Tar class? > As for the core, some people are untarring that distro into the core > directory when, in fact, it needs to be decompressed and copied > into the > root. > > How would you prefer this be done? How would you like the modules and > core to untar? When decompressed, what should the directories be > named? > Is "core" a misleading name for the base files of phpwebsite? Call it 'base' ??? Call just the core library 'core'. And for the record I've always disliked 'core' as a directory name since Apache generally thinks it's a core dump and my CVS tool ignores it by default. Even raised an RFE to change it way back. Shaun aegis design - http://www.aegisdesign.co.uk aegis hosting - http://www.aegishosting.co.uk |
|
From: Matthew M. <ma...@tu...> - 2007-01-04 13:20:40
|
On Thu, 2007-01-04 at 11:53 +0000, Shaun Murray wrote: > I'd prefer that as then it's less likely I or someone else doesn't > overwrite the root directory. Certainly from the phpws-comm project, > most modules unpack to module-vn.n.n directories and are then moved > in but you usually work in /mod not root > > That in itself confuses some people as they often don't rename the > module-vn.n.n directory and end up with two modules of the same name > installed from different directories. Anyone have any reservations about having the tarballs decompress to a version labeled directory? For example, blog_1_0_1.tgz creates directory blog_1_0_1/ ? > Maybe it's something we can look at enhancing with boost so the > process is web based entirely? Use PEAR's Archive_Tar class? I'll read up on it, but my spider-sense tingles when thinking about file execution at the web level. > Call it 'base' ??? I like the name 'base'. Any objections? -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
|
From: Verdon V. <ve...@ve...> - 2007-01-04 13:36:21
|
On 4-Jan-07, at 8:14 AM, Matthew McNaney wrote: > On Thu, 2007-01-04 at 11:53 +0000, Shaun Murray wrote: > >> I'd prefer that as then it's less likely I or someone else doesn't >> overwrite the root directory. Certainly from the phpws-comm project, >> most modules unpack to module-vn.n.n directories and are then moved >> in but you usually work in /mod not root >> >> That in itself confuses some people as they often don't rename the >> module-vn.n.n directory and end up with two modules of the same name >> installed from different directories. > > Anyone have any reservations about having the tarballs decompress to a > version labeled directory? For example, blog_1_0_1.tgz creates > directory > blog_1_0_1/ ? This works for me, as I often rename a copy of the new version I've just expanded in this manner anywise, so I have a bit of a local archive of version histories. > >> Maybe it's something we can look at enhancing with boost so the >> process is web based entirely? Use PEAR's Archive_Tar class? > > I'll read up on it, but my spider-sense tingles when thinking about > file > execution at the web level. Speaking only for myself... although this would be convenient in the right hands, I sure wouldn't want my clients being able to do updates via browser/cp either. Often I have to make minor tweaks to mods to suit a client and I know if they could click an update button they would, and blow them away ;-) Also, and I know this sounds petty, I make my living building and maintaining client sites. All that said, I rarely give deity access to a client, just to protect them from themselves. > > >> Call it 'base' ??? > > I like the name 'base'. Any objections? Works for me too. > > -- > Matthew McNaney > Electronic Student Services > Appalachian State University > http://phpwebsite.appstate.edu > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
|
From: hr_vbid <hi...@dc...> - 2007-01-04 18:24:57
|
Good evening (from Berlin is good morning in US ...) About the Delivery, my wish is to have the tar always relative to a current installation path - the place, where the main index php resides. When my focus is, for example, at .../public_html, the decompress can overwrite the actual installation. In case of modules, .../public_html/mod, in case of core, .../public_html/core, in case of the relative root, just that public_html base. If I'm afraid about doing something becomes dangerous, I can set the path to anywhere else and decompress. In this case, manual copy/move is required. But the decompressed files may be viewed before. With simple words, I prefer the same relative path to core and mods in the tar, without the need to investigate in each single case where I have to go in the path tree to decompress. Regards, Hilmar Matthew McNaney wrote: > > Good morning. > > I am looking for feedback on how the core and modules should be > distributed.... > > -- View this message in context: http://www.nabble.com/Delivery-tf2913502.html#a8164528 Sent from the PhpWebsite - Dev mailing list archive at Nabble.com. |
|
From: Matthew M. <ma...@tu...> - 2007-01-05 17:11:20
|
Thank you to everyone who responded. Following your suggestions, here is my tentative plan. core renamed to base. base_1_4_6.tgz untars to phpwebsite_base_1_4_6/ phpwebsite_base_1_4_6/core/ phpwebsite_base_1_4_6/core/class/ phpwebsite_base_1_4_6/inc/ phpwebsite_base_1_4_6/themes/ etc. Modules blog_1_1_1.tgz untars to blog_1_1_1/mod/blog/ blog_1_1_1/mod/blog/class/ etc. The module method is similar to the PEAR package method. This should prevent accidental overwrite and (hopefully) less placement confusion. This is not set yet, so please reply back if you think this is unwise. Best regards, Matt -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
|
From: Greg M. <drk...@co...> - 2007-01-08 07:38:33
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew McNaney wrote: > Is "core" a misleading name for the base files of phpwebsite? > > Any advice would be appreciated. > How big will OpenSolaris be? I don't know but we do have http://www.blastwave.org/ , a GPLed Java, a hint of a GPL3 Solaris, and Knoppix like CDs in the form of BeLenix http://www.genunix.org/distributions/belenix_site/?q=about. As a Solaris customer at work, I am always disappointed at how far back the available code versions are for Solaris but I guess it is improving. I do know that core is used on Solaris systems for C segmentation fault files. The OS dumps a copy of the program's memory into a core file. I recall responding to a forum message. The guy was upset that he did not have a backup of the core directory. You see the default settings of Solaris exclude the *core* from backups. ;-0 Well that was easy to fix with a copy of the core directory from another tar.gz file and the altering of the default backup settings. However, you may want to stay away from the word core in the 1.x world for part of the community that runs phpWebSite on Solaris or OpenSolaris. Regards, Greg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFofTuxyxe5L6mr7IRAtCZAJ9bOM7VMK6x4BSEOsTjOmJFGVNlAwCfdxyj PWoce84+Lzy1rVntF2aS9og= =cew2 -----END PGP SIGNATURE----- |
|
From: Shaun M. <sh...@ae...> - 2007-01-08 14:28:36
|
On 8 Jan 2007, at 07:38, Greg Morgan wrote: > I do know that core is used on Solaris systems for C segmentation > fault > files. The OS dumps a copy of the program's memory into a core file. At least in the default config in Linux, Apache also shows the phpwebsite core directory with a little bomb next to it when viewing with indexes allowed. CVS on my system marks the core directory as a file that's not important, like it does hidden dot files. I'm not sure what they're trying to say but they're describing core code as either not important or 'da bomb'. Shaun aegis design - http://www.aegisdesign.co.uk aegis hosting - http://www.aegishosting.co.uk |
|
From: Matthew M. <ma...@tu...> - 2007-01-08 14:50:55
|
I'd like to think the latter. On Mon, 2007-01-08 at 14:28 +0000, Shaun Murray wrote: > On 8 Jan 2007, at 07:38, Greg Morgan wrote: > > > I do know that core is used on Solaris systems for C segmentation > > fault > > files. The OS dumps a copy of the program's memory into a core file. > > At least in the default config in Linux, Apache also shows the > phpwebsite core directory with a little bomb next to it when viewing > with indexes allowed. > > CVS on my system marks the core directory as a file that's not > important, like it does hidden dot files. > > I'm not sure what they're trying to say but they're describing core > code as either not important or 'da bomb'. > > > > Shaun > aegis design - http://www.aegisdesign.co.uk > aegis hosting - http://www.aegishosting.co.uk > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X