|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
php-general-digest-help
lists.php.net
Date: Tue Feb 12 2008 - 12:04:22 CST
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
php-general Digest 12 Feb 2008 18:04:22 -0000 Issue 5289
Topics (messages 269145 through 269179):
Re: How to read excel sheet and display it's contents.
269145 by: Wolf
Re: Run Process in back ground
269146 by: Per Jessen
269151 by: Nirmalya Lahiri
Re: Session and Multi Server Architecture
269147 by: Per Jessen
269148 by: Per Jessen
269160 by: Stut
269162 by: Sancar Saran
269163 by: Sancar Saran
269164 by: Sancar Saran
269165 by: Per Jessen
269166 by: Stut
269167 by: Stut
269168 by: Per Jessen
269170 by: Stut
269172 by: Sancar Saran
269173 by: Nathan Nobbe
Re: Gzipped output
269149 by: Per Jessen
PHP 5.2.5 installation
269150 by: Yoshika Kehelpannala
269152 by: jihad A. Al-Ammar \(ÌåÇÏ ÇáÚãÇÑ\)
269153 by: Nirmalya Lahiri
269155 by: Nathan Rixham
269158 by: Floor Terra
Template system in PHP
269154 by: Xavier de Lapeyre
269156 by: Brice
269157 by: clive
269159 by: Nathan Rixham
269161 by: Jochem Maas
269169 by: Bastien Koert
269177 by: Greg Donald
269178 by: Nate Tallman
Re: memcached (was: session and Multi Server Architecture)
269171 by: Per Jessen
Question about development
269174 by: Jason Pruim
269179 by: Nathan Rixham
Re: LVS (was: Session and Multi Server Architecture)
269175 by: Per Jessen
269176 by: Nathan Nobbe
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscribelists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscribelists.php.net
To post to the list, e-mail:
php-generallists.php.net
----------------------------------------------------------------------
attached mail follows:
Yes, read the documentation and look at include and require in the php documentation.
-----Original Message-----
From: srihari naidu <srihari_asdyahoo.com>
Sent: Monday, February 11, 2008 5:51 PM
To: PHP Mail List <php-generallists.php.net>
Subject: [PHP] How to read excel sheet and display it's contents.
Hi, can any suggest me how to read and display the content in a html page.
I tried phpexcelreadrer at http://sourceforge.net/projects/phpexcelreader/ but got error
Warning: require_once(Spreadsheet/Excel/Reader/OLERead.php) [function.require-once]: failed to open stream: No such file or directory in D:\phpdocs\reader2\Excel\reader.php on line 31
Fatal error: require_once() [function.require]: Failed opening required 'Spreadsheet/Excel/Reader/OLERead.php' (include_path='.;C:\php5\pear') in D:\phpdocs\reader2\Excel\reader.php on line 31
can any please suggest me the solution for this error please.
Thanks in advance
Regards,
Sri Hari
---------------------------------
Never miss a thing. Make Yahoo your homepage.
attached mail follows:
Stut wrote:
>> Yes:
>>
>> mail( .... );
>> header("Location:http://domain.com");
>>
>>
>> mail() only takes as long as it takes to drop the mail in your local
>> filesystem.
>
> Not necessarily. As discussed at length on this list last month
> sendmail (or a substitute) may try to deliver the message rather than
> passing it to a local MTA.
True, a lot will depend on your local MTA. If you're running postfix,
sendmail will always behave like I described.
If you're running a local MTA (local="on the same machine"), I would
expect sendmail to be very quick, but I have no experience with the
other MTAs (sendmail itself, exim, qmail et al.)
/Per Jessen, Zürich
attached mail follows:
--- Richard Kurth <richardkurthcenturytel.net> wrote:
> Is there a way that I can call a function that will send an email
> and
> then move on redirecting to another website without having to what
> for
> the email to send?
> SendEmail($memberemail,$MailFrom,$MailHost);
> header("Location:http://domain.com");
>
> --
Richard,
You can do it in other way. The steps are....
1> Just keep the emails in database.
2> Write another shell/PHP script which will fetch email from
database and send the email using local/remote MTA.
3> Run this script from cron as background process.
---
Nirmalya Lahiri
[+91-9433113536]
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
attached mail follows:
mike wrote:
> On 2/11/08, Per Jessen <percomputer.org> wrote:
>> Because you've chosen another option - memcached presumably - which
>> is more expensive over all. (IMHO).
>
> mysql (stated above), and i already have a connection open each
> page...
Ah, so all you need is per-connection persistency. Yep, that is by far
the easiest. I use LVS for my mail-server cluster, also per-connection
persistency only.
>> LVS won't migrate any of your data for you. It'll shift the client
>> to an available server, that's all.
>
> yes i know that. so you're either advocating:
>
> a) persistence AND central session management, or
> b) persistence and not keeping anything important in a session in case
> the server is pulled out of the pool? (assuming non-centralized
> session support)
Option b).
In the case of a controlled server removal, wouldn't you be able to wait
until all clients are gone? You know, set the LVS weight to 0, then
wait, then remove the server without session loss.
/Per Jessen, Zürich
attached mail follows:
Stut wrote:
> Per Jessen wrote:
>> mike wrote:
>>
>>>> Check out persistency in LVS for instance:
>>>> http://www.linuxvirtualserver.org/docs/persistence.html
>>> i know persistence handling is an option in LVS, but i haven't seen
>>> the need to use it. i use LVS right now without even bothering with
>>> any of that.
>>
>> Because you've chosen another option - memcached presumably - which
>> is more expensive over all. (IMHO).
>
> Based on what? I'm currently looking at replacing a file-based cache
> with memcached and I'm interested in all justified opinions.
You might not have much use for mine then :-)
If I compare plain session-persistency (session being a client to server
relationship, not $_SESSION) with memcacheds copying objects around
across many machines, common sense tells me that the latter will use a
lot more resources. Both on the network and on each machine.
With memcached, and 1000 clients for a cluster of 50 machines, each
using up 1Mb of $_SESSION space, that is 1000Mb per machine, 50Gb in
total.
With session-persistency, you have 50 machines with 1000/50 clients
each, making 20Mb per machine. And virtually no session-related
inter-machine network traffic. And your machines are not busy with
keeping 980 objects needlessly up-to-date.
Of course, processing power, network capacity and memory are all very
cheap these days, so it's easy to put on the Microsoft hat and be
wasteful.
>> On the next request, LVS will know not to try that server, and the
>> user will move to another one. Obviously the session-context will
>> die, but is that really a big deal? How often does one of your
>> servers die? Sure, if you've got 10,000 in a cluster, you'll have
>> fans and harddisks pop every so often, but I have my doubts about
>> memcached scaling to that level (please correct me if I'm wrong here,
>> I have _no_ experience with memcached).
>
> Facebook. Digg. LiveJournal. That enough scalability proof for ya? If
> not there are plenty more where those came from.
It wasn't really the scalability I was interested in here, but I'd be
interested to hear some numbers if you have any.
My point with the 10,000 machines was - with that many components, even
the 100,000 hours MTBF of a regular harddisk will mean one will break
every ten hours (statistically speaking). Add fan- and other failures
to that, and you'll have sessions dying quite frequently. Which _could_
be a significant problem, and maybe enough to make you want to use
memcached for object replication. (there might also be a restriction in
the number of concurrent clients handled by LVS session persistency).
However, with a much smaller cluster, say 50 or 100 machines, hardware
failures will be a lot less frequent, and having the odd session die
once a week might not be a problem. Which is why I think LVS session
persistency is perfectly fine.
/Per Jessen, Zürich
attached mail follows:
Per Jessen wrote:
> Stut wrote:
>
>> Per Jessen wrote:
>>> mike wrote:
>>>
>>>>> Check out persistency in LVS for instance:
>>>>> http://www.linuxvirtualserver.org/docs/persistence.html
>>>> i know persistence handling is an option in LVS, but i haven't seen
>>>> the need to use it. i use LVS right now without even bothering with
>>>> any of that.
>>> Because you've chosen another option - memcached presumably - which
>>> is more expensive over all. (IMHO).
>> Based on what? I'm currently looking at replacing a file-based cache
>> with memcached and I'm interested in all justified opinions.
>
> You might not have much use for mine then :-)
>
> If I compare plain session-persistency (session being a client to server
> relationship, not $_SESSION) with memcacheds copying objects around
> across many machines, common sense tells me that the latter will use a
> lot more resources. Both on the network and on each machine.
>
> With memcached, and 1000 clients for a cluster of 50 machines, each
> using up 1Mb of $_SESSION space, that is 1000Mb per machine, 50Gb in
> total.
>
> With session-persistency, you have 50 machines with 1000/50 clients
> each, making 20Mb per machine. And virtually no session-related
> inter-machine network traffic. And your machines are not busy with
> keeping 980 objects needlessly up-to-date.
>
> Of course, processing power, network capacity and memory are all very
> cheap these days, so it's easy to put on the Microsoft hat and be
> wasteful.
In my mind you're exchanging traffic over a local network (probably
1Gbps) for a less resilient load balancing system. By locking users to
particular machines you don't allow for the possibility that you'll end
up with a large number of users on any given server while others lie
idle. Personally I'd always opt for a solution where my hardware will be
utilised as evenly as possible regardless of user patterns.
>>> On the next request, LVS will know not to try that server, and the
>>> user will move to another one. Obviously the session-context will
>>> die, but is that really a big deal? How often does one of your
>>> servers die? Sure, if you've got 10,000 in a cluster, you'll have
>>> fans and harddisks pop every so often, but I have my doubts about
>>> memcached scaling to that level (please correct me if I'm wrong here,
>>> I have _no_ experience with memcached).
>> Facebook. Digg. LiveJournal. That enough scalability proof for ya? If
>> not there are plenty more where those came from.
>
> It wasn't really the scalability I was interested in here, but I'd be
> interested to hear some numbers if you have any.
Mike posted a link to a thread that discusses Facebook usage. I don't
have any other numbers handy but I'm sure Google can find some for you
if needed.
> My point with the 10,000 machines was - with that many components, even
> the 100,000 hours MTBF of a regular harddisk will mean one will break
> every ten hours (statistically speaking). Add fan- and other failures
> to that, and you'll have sessions dying quite frequently. Which _could_
> be a significant problem, and maybe enough to make you want to use
> memcached for object replication. (there might also be a restriction in
> the number of concurrent clients handled by LVS session persistency).
>
> However, with a much smaller cluster, say 50 or 100 machines, hardware
> failures will be a lot less frequent, and having the odd session die
> once a week might not be a problem. Which is why I think LVS session
> persistency is perfectly fine.
Which is why memcache should never be the definitive source for any
data. Memcache is volatile storage, that's a fact you can't get away
from. If you're using it to store session data then you either accept
that sessions might die at any time or you back it up with storage in
something more persistent.
I'll be using memcache as a simple cache. I hate sessions and avoid them
for anything but the most trivial sites. The main sites I work with no
longer use sessions because they add a pointless layer of complexity to
any application that need to scale beyond a single machine. Maybe I'm
just lucky that the applications I develop don't need to store huge
amounts of temporary data during a visit, but I'm yet to come across a
reason to use "session data".
-Stut
--
http://stut.net/
attached mail follows:
On Tuesday 12 February 2008 00:45:59 Michael McGlothlin wrote:
> > implement session_set_save_handler() with a database, or
> > ideally, memcache.
>
> I use memcache with a secondary db backing. Works pretty well. I use it
> for session data as well as any other uses I want to make of memcache.
> Memcache makes it fast and using the db makes it more persistent and
> able to handle larger chunks of data.
>
> --
> Michael McGlothlin
> Southwest Plumbing Supply
Hello
I really really interesting about this SECONDARY DB BACKING.
Could you lead me a document, article, ANYTHING to backing up memcached into
anything ?
Last time it when I was try it, it was huge disaster.
Regards
Sancar
attached mail follows:
Hello
On Tuesday 12 February 2008 13:39:19 Stut wrote:
>
> I'll be using memcache as a simple cache. I hate sessions and avoid them
> for anything but the most trivial sites. The main sites I work with no
> longer use sessions because they add a pointless layer of complexity to
> any application that need to scale beyond a single machine. Maybe I'm
> just lucky that the applications I develop don't need to store huge
> amounts of temporary data during a visit, but I'm yet to come across a
> reason to use "session data".
>
> -Stut
>
May I ask how can you record the state ?
Regards
Sancar
attached mail follows:
Hello
For poor man's multinode, ADODB offers Sql based sessions, it was good enough
for starters.
Of course memcached based session storage was an option. But with this model
need better implementation. Memcached was just cache, there was no offical
way to backup data. (as far as I know)
Regards
Sancar
attached mail follows:
Stut wrote:
>> Of course, processing power, network capacity and memory are all very
>> cheap these days, so it's easy to put on the Microsoft hat and be
>> wasteful.
>
> In my mind you're exchanging traffic over a local network (probably
> 1Gbps) for a less resilient load balancing system. By locking users to
> particular machines you don't allow for the possibility that you'll
> end up with a large number of users on any given server while others
> lie idle.
There's no question of locking users to particular machines, nor of
uneven distribution. LVS will distribute evenly or according to
weights.
> Personally I'd always opt for a solution where my hardware
> will be utilised as evenly as possible regardless of user patterns.
Certainly.
> I'll be using memcache as a simple cache. I hate sessions and avoid
> them for anything but the most trivial sites. The main sites I work
> with no longer use sessions because they add a pointless layer of
> complexity to any application that need to scale beyond a single
> machine.
Well, we have no problem using sessions on our web-cluster (with LVS
session persistency).
Do you write your apps specifically for use with memcached? I did think
of that, but I thought people would prefer not have their apps tied
directly to memcached. I guess it's a matter of choice.
/Per Jessen, Zürich
attached mail follows:
Per Jessen wrote:
> Stut wrote:
>
>>> Of course, processing power, network capacity and memory are all very
>>> cheap these days, so it's easy to put on the Microsoft hat and be
>>> wasteful.
>> In my mind you're exchanging traffic over a local network (probably
>> 1Gbps) for a less resilient load balancing system. By locking users to
>> particular machines you don't allow for the possibility that you'll
>> end up with a large number of users on any given server while others
>> lie idle.
>
> There's no question of locking users to particular machines, nor of
> uneven distribution. LVS will distribute evenly or according to
> weights.
Indeed, but you must see that making the decision of which server to use
per request will result in a more even distribution than deciding once
per session.
>> Personally I'd always opt for a solution where my hardware
>> will be utilised as evenly as possible regardless of user patterns.
>
> Certainly.
>
>> I'll be using memcache as a simple cache. I hate sessions and avoid
>> them for anything but the most trivial sites. The main sites I work
>> with no longer use sessions because they add a pointless layer of
>> complexity to any application that need to scale beyond a single
>> machine.
>
> Well, we have no problem using sessions on our web-cluster (with LVS
> session persistency).
Good for you.
> Do you write your apps specifically for use with memcached? I did think
> of that, but I thought people would prefer not have their apps tied
> directly to memcached. I guess it's a matter of choice.
No, but that's purely a result of the way I approach any programming
problem. I try to deal in layers of abstraction at every level.
Coincidentally I'm modifying my cache layer today to support memcache as
a backend option since the current file-based backend is experiencing
scalability problems due to recent traffic increases. Since the app is
purposefully layered and modular I don't need to touch anything other
than this layer.
Having said that I don't see a problem with depending on a particular
piece of software as a dependency of the application. Your app already
requires PHP, and most likely requires a bunch of extensions to be
present so I don't see a major problem in adding memcache to that list,
especially if it means you can use it much more efficiently by assuming
it's available.
Since I'm just replacing a file-based cache with memcache I'm certain it
won't be as efficient as it would be if I dove into the rest of the code
and changed it to use memcache directly. For a start I'd be able to make
use of requesting multiple keys at once which is not going to be
possible with the way it works at the moment, but it will get past the
scalability limits currently being tapped.
-Stut
--
http://stut.net/
attached mail follows:
Sancar Saran wrote:
> Hello
> On Tuesday 12 February 2008 13:39:19 Stut wrote:
>> I'll be using memcache as a simple cache. I hate sessions and avoid them
>> for anything but the most trivial sites. The main sites I work with no
>> longer use sessions because they add a pointless layer of complexity to
>> any application that need to scale beyond a single machine. Maybe I'm
>> just lucky that the applications I develop don't need to store huge
>> amounts of temporary data during a visit, but I'm yet to come across a
>> reason to use "session data".
>>
>> -Stut
>>
> May I ask how can you record the state ?
You may.
Oh, you probably want an actual answer... ok.
The only 'state' I really need to keep track of is a few details about
the logged in user (ID, username, etc). These get encrypted and get
passed around as a single value in the same way PHP manages the session
ID (cookie or embedded in the URL).
The encrypted value is time limited and gets updated on each request.
Clearly there is a limit to how much info can be stored like this but
after some analysis of how the site worked I reached the conclusion that
most of the crap that was being put into the session was not required
from request to request and could be retrieved from the DB when it was
needed.
This has been running on a site with > 1 million unique users a month
for over 6 months with no issues. I now use this system with most sites
I get involved in and am yet to find a valid reason to replace it with a
traditional session.
Part of the reason this works is that in the few parts of the site where
it would make sense to use a traditional session to temporarily store
data it does it in a table in the database. This is essentially a
SQL-based session but with one important difference... DB hits are
limited when they are needed only - i.e. when the user is using those
parts of the site. With a SQL-based session you cause 2+ DB hits for
each request even if you don't actually use the session. This is bad m'kay!
Over the past few years I've learnt a lot about scalability and the
single biggest tip I can pass on is to only do what is absolutely
necessary at any given time. Sessions are the biggest barrier to being
able to do that, so they had to go.
Hope that answers your question.
-Stut
--
http://stut.net/
attached mail follows:
Stut wrote:
>> There's no question of locking users to particular machines, nor of
>> uneven distribution. LVS will distribute evenly or according to
>> weights.
>
> Indeed, but you must see that making the decision of which server to
> use per request will result in a more even distribution than deciding
> once per session.
You might see a somewhat uneven distribution if you only have a small
number of machines, but the resources you're saving by not having
memcached replicate objects will now be available for that slightly
less even distribution.
> Having said that I don't see a problem with depending on a particular
> piece of software as a dependency of the application. Your app already
> requires PHP, and most likely requires a bunch of extensions to be
> present so I don't see a major problem in adding memcache to that
> list, especially if it means you can use it much more efficiently by
> assuming it's available.
My personal choice would be not to have my application deal directly
with caching, but that's mostly a matter of choice.
/Per Jessen, Zürich
attached mail follows:
Per Jessen wrote:
> Stut wrote:
>
>>> There's no question of locking users to particular machines, nor of
>>> uneven distribution. LVS will distribute evenly or according to
>>> weights.
>> Indeed, but you must see that making the decision of which server to
>> use per request will result in a more even distribution than deciding
>> once per session.
>
> You might see a somewhat uneven distribution if you only have a small
> number of machines, but the resources you're saving by not having
> memcached replicate objects will now be available for that slightly
> less even distribution.
I'm not sure what you mean by "replicate objects".
>> Having said that I don't see a problem with depending on a particular
>> piece of software as a dependency of the application. Your app already
>> requires PHP, and most likely requires a bunch of extensions to be
>> present so I don't see a major problem in adding memcache to that
>> list, especially if it means you can use it much more efficiently by
>> assuming it's available.
>
> My personal choice would be not to have my application deal directly
> with caching, but that's mostly a matter of choice.
Abstraction is great but where scalability is needed it can prove to be
horribly inefficient, but as you say it's a matter of choice.
-Stut
--
http://stut.net/
attached mail follows:
On Tuesday 12 February 2008 16:06:04 Stut wrote:
> Sancar Saran wrote:
> > Hello
> >
> > On Tuesday 12 February 2008 13:39:19 Stut wrote:
> >> I'll be using memcache as a simple cache. I hate sessions and avoid them
> >> for anything but the most trivial sites. The main sites I work with no
> >> longer use sessions because they add a pointless layer of complexity to
> >> any application that need to scale beyond a single machine. Maybe I'm
> >> just lucky that the applications I develop don't need to store huge
> >> amounts of temporary data during a visit, but I'm yet to come across a
> >> reason to use "session data".
> >>
> >> -Stut
> >
> > May I ask how can you record the state ?
>
> You may.
>
> Oh, you probably want an actual answer... ok.
>
> The only 'state' I really need to keep track of is a few details about
> the logged in user (ID, username, etc). These get encrypted and get
> passed around as a single value in the same way PHP manages the session
> ID (cookie or embedded in the URL).
>
> The encrypted value is time limited and gets updated on each request.
>
> Clearly there is a limit to how much info can be stored like this but
> after some analysis of how the site worked I reached the conclusion that
> most of the crap that was being put into the session was not required
> from request to request and could be retrieved from the DB when it was
> needed.
>
> This has been running on a site with > 1 million unique users a month
> for over 6 months with no issues. I now use this system with most sites
> I get involved in and am yet to find a valid reason to replace it with a
> traditional session.
>
> Part of the reason this works is that in the few parts of the site where
> it would make sense to use a traditional session to temporarily store
> data it does it in a table in the database. This is essentially a
> SQL-based session but with one important difference... DB hits are
> limited when they are needed only - i.e. when the user is using those
> parts of the site. With a SQL-based session you cause 2+ DB hits for
> each request even if you don't actually use the session. This is bad m'kay!
>
> Over the past few years I've learnt a lot about scalability and the
> single biggest tip I can pass on is to only do what is absolutely
> necessary at any given time. Sessions are the biggest barrier to being
> able to do that, so they had to go.
>
> Hope that answers your question.
>
> -Stut
Yes
Thanks much :)
Sancar
attached mail follows:
well guys, im reading all this stuff about LVS and
so forth, and i must admit, i really dont know the
first thing about it. i mean, i do understand the
vserver concept, is LVS essentially the same as
v-server,
http://linux-vserver.org/Welcome_to_Linux-VServer.org
?
also, i dont understand how LVS is used to implement
a 'persistent' session. allow me to explain my
disconnect.. so you are using virtual servers on a real
system; what benefit, in the context of sessions does
this provide over a single machine w/ 1 os? another
fundamental disconnect is, how are you using these
machines to store session state, a network filesystem?
also, in terms of scalability, isnt facebook proof that
memcache can scale?
thanks,
-nathan
attached mail follows:
Stut wrote:
>> Make any PHP-based script available without usage-restriction, and
>> you've got yourself a DDOS potential. Â Using exec() doesn't change
>> anything.
>
> I would argue that it makes it easier since creating and tearing down
> processes is a pretty expensive operation for most OS's, but like I
> said you're free to do whatever you want with your servers and
> clients.
I don't know about most OS'es, but "creating and tearing down
processes" is very cheap on Linux. The fork() call takes very few
resources (copy-on-write etc.)
If you subsequently load another binary using execv(), it could well
turn into a "pretty expensive operation", but that's up to you.
If you're the target of a DOS attack, I would venture a guess and say
your Apache server is dead long before exec() would have a chance to
exacerbate the problem.
Regardless, the OP was after delivering large files compressed chunk by
chunk - I really do not see a security issue in using gzip for that,
but I still like Andre Robinets solution better.
/Per Jessen, Zürich
attached mail follows:
Hi,
I have downloaded and setup the Apachi web server and My SQL 5.0.51a prior
to my PHP installation on the windows platform. As I have downloaded the PHP
5.2.5 version (msi) and installed it on my system, it gave some errors that
says a lot of dll's and sort of files are missing. I checked how to install
it on your site and found only the basic 5.xx is documented. Please help me
on this.
Thanks and regards,
attached mail follows:
Why don’t you try installing it the easy way through WAMP. It installs PHP, MySQL, and Apache all configured and ready to go.
http://www.wampserver.com/en/
Includes :
- Apache 2.2.6
- MySQL 5.0.45
- PHP 5.2.5
From: Yoshika Kehelpannala [mailto:yoshikakcsbsl.com]
Sent: 12/Feb/2008 11:56 AM
To: php-generallists.php.net
Subject: [PHP] PHP 5.2.5 installation
Hi,
I have downloaded and setup the Apachi web server and My SQL 5.0.51a prior to my PHP installation on the windows platform. As I have downloaded the PHP 5.2.5 version (msi) and installed it on my system, it gave some errors that says a lot of dll’s and sort of files are missing. I checked how to install it on your site and found only the basic 5.xx is documented. Please help me on this.
Thanks and regards,
attached mail follows:
--- Yoshika Kehelpannala <yoshikakcsbsl.com> wrote:
> Hi,
>
> I have downloaded and setup the Apachi web server and My SQL
> 5.0.51a prior
> to my PHP installation on the windows platform. As I have
> downloaded the PHP
> 5.2.5 version (msi) and installed it on my system, it gave some
> errors that
> says a lot of dll's and sort of files are missing. I checked how to
> install
> it on your site and found only the basic 5.xx is documented. Please
> help me
> on this.
>
--
Yoshika,
Please post the name of dll's and other files which are reported as
missing..!!! Without that no one can identify the error...
---
Nirmalya Lahiri
[+91-9433113536]
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
attached mail follows:
I had the same problems installing 5.2.5 last week on windows, the
installer's a bit corrupt!
I ended up having to manually install from the latest snapshot instead;
(download, extract, configure manually) alternatively, attempt to
install as best it will, then overwrite with a snapshot.
terrible advice from myself there! but it will work.
Nathan
Yoshika Kehelpannala wrote:
> Hi,
>
>
>
> I have downloaded and setup the Apachi web server and My SQL 5.0.51a
> prior to my PHP installation on the windows platform. As I have
> downloaded the PHP 5.2.5 version (msi) and installed it on my system, it
> gave some errors that says a lot of dll’s and sort of files are missing.
> I checked how to install it on your site and found only the basic 5.xx
> is documented. Please help me on this.
>
>
>
> Thanks and regards,
>
>
>
attached mail follows:
On Feb 12, 2008 9:55 AM, Yoshika Kehelpannala <yoshikakcsbsl.com> wrote:
> I have downloaded and setup the Apachi web server and My SQL 5.0.51a prior
> to my PHP installation on the windows platform. As I have downloaded the PHP
> 5.2.5 version (msi) and installed it on my system, it gave some errors that
> says a lot of dll's and sort of files are missing. I checked how to install
> it on your site and found only the basic 5.xx is documented. Please help me
> on this.
I have had the same problem. I figured I was stupid and forgot something
(I'm used to "pkg_add php5", not Windows installers). My sollution was
to install WAMP server (http://www.wampserver.com/), lazy and effective.
Floor
attached mail follows:
Hi,
I need to develop a website, but my management is rather unstable in his
vision for the layout.
I'm thinking of developing the components as classes and functions, and
then use a template system to render the layout.
If the management wishes to change the layout, I'll just have to modify
my template and the jobs' done.
Do any of you guys & gurls know of a way to implement that template
system.
(The best one I know of is that of Wordpress)
Regards,
Xavier de Lapeyre
Web Developer
attached mail follows:
Hi,
I suggest you to use a framework. Lots of them implements template system
and more. You'll don't have to reinvent the wheel.
My favorit is Copix http://www.copix.org/
Email me if you need help.
Brice
On Feb 12, 2008 11:01 AM, Xavier de Lapeyre <xavieredsnetworks.net> wrote:
> Hi,
> I need to develop a website, but my management is rather unstable in his
> vision for the layout.
> I'm thinking of developing the components as classes and functions, and
> then use a template system to render the layout.
> If the management wishes to change the layout, I'll just have to modify
> my template and the jobs' done.
>
> Do any of you guys & gurls know of a way to implement that template
> system.
>
> (The best one I know of is that of Wordpress)
>
> Regards,
> Xavier de Lapeyre
> Web Developer
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
attached mail follows:
Xavier de Lapeyre wrote:
>
> Do any of you guys & gurls know of a way to implement that template
> system.
>
>
Smarty ?
> (The best one I know of is that of Wordpress)
>
> Regards,
> Xavier de Lapeyre
> Web Developer
>
>
attached mail follows:
another vote here for smarty - it's pretty much standard issue nowadays
and means should the need ever arise you can easily bring in a web
designer to do the html without having to worry about them learning some
new system.
Nathan
clive wrote:
> Xavier de Lapeyre wrote:
>>
>> Do any of you guys & gurls know of a way to implement that template
>> system.
>>
>>
> Smarty ?
>> (The best one I know of is that of Wordpress)
>>
>> Regards,
>> Xavier de Lapeyre
>> Web Developer
>>
>>
attached mail follows:
Xavier de Lapeyre schreef:
> Hi,
> I need to develop a website, but my management is rather unstable in his
> vision for the layout.
> I'm thinking of developing the components as classes and functions, and
> then use a template system to render the layout.
> If the management wishes to change the layout, I'll just have to modify
> my template and the jobs' done.
>
> Do any of you guys & gurls know of a way to implement that template
> system.
>
> (The best one I know of is that of Wordpress)
you can do better.
don't bother to create your own template system, using something that already
exists. there are plenty of 'php template engines' out there. one of the
most well known is Smarty (http://smarty.net/) which is a good one to start with,
they have quite extensive docs and a decent mailing list (things which I feel are
worth taking into consideration beyond the purely technical pros and cons when
deciding which one to use).
googling for php+template+engine will get you a stack of possible candidates.
also consider that the way you write your HTML heavily influences how much
you have to change when management decides on a visual change. if you go the
route of writing very functional HTML (i.e. HTML that makes next to no attempt to
provide layout/styling) and use CSS as much as possible to provide the actually
layout/design then you might consider not bothering with a template and just using
CSS to implement UI design changes.
to get an idea of exactly how different a single page of HTML can look depending on
the CSS that is applied take a look at csszengarden
>
> Regards,
> Xavier de Lapeyre
> Web Developer
>
attached mail follows:
smarty?
bastien
> Date: Tue, 12 Feb 2008 14:01:11 +0400> From: xavieredsnetworks.net> To: php-generallists.php.net> Subject: [PHP] Template system in PHP> > Hi,> I need to develop a website, but my management is rather unstable in his> vision for the layout.> I'm thinking of developing the components as classes and functions, and> then use a template system to render the layout.> If the management wishes to change the layout, I'll just have to modify> my template and the jobs' done.> > Do any of you guys & gurls know of a way to implement that template> system.> > (The best one I know of is that of Wordpress)> > Regards,> Xavier de Lapeyre> Web Developer> > -- > PHP General Mailing List (http://www.php.net/)> To unsubscribe, visit: http://www.php.net/unsub.php>
_________________________________________________________________
attached mail follows:
On 2/12/08, Xavier de Lapeyre <xavieredsnetworks.net> wrote:
> Do any of you guys & gurls know of a way to implement that template
> system.
eval() is my favorite templating engine.
http://php.net/eval
--
Greg Donald
http://destiney.com/
attached mail follows:
Ditto on Eval()
PHP is already a templating system. Why go the long way around?
On Feb 12, 2008 10:13 AM, Greg Donald <gdonaldgmail.com> wrote:
> On 2/12/08, Xavier de Lapeyre <xavieredsnetworks.net> wrote:
> > Do any of you guys & gurls know of a way to implement that template
> > system.
>
> eval() is my favorite templating engine.
>
> http://php.net/eval
>
>
> --
> Greg Donald
> http://destiney.com/
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
attached mail follows:
Stut wrote:
>>>> There's no question of locking users to particular machines, nor of
>>>> uneven distribution. LVS will distribute evenly or according to
>>>> weights.
>>> Indeed, but you must see that making the decision of which server to
>>> use per request will result in a more even distribution than
>>> deciding once per session.
>>
>> You might see a somewhat uneven distribution if you only have a small
>> number of machines, but the resources you're saving by not having
>> memcached replicate objects will now be available for that slightly
>> less even distribution.
>
> I'm not sure what you mean by "replicate objects".
>
My mistake - I though I'd understood that memcached would replicate
objects across the servers, but that's clearly wrong.
If I've got it right, virtually every access to a cached object will
require network traffic? (the exception being those cases where your
object is on your local memcached).
I've very likely overlooked something or other, but overall memcached
seems to me to be unnecessarily complicated when the same problem can
be solved with session persistency (even if you have to accept a
slightly uneven load at times).
/Per Jessen, Zürich
attached mail follows:
Hi Everyone,
I know this isn't 100% on topic... But when is any post to this list
100% on topic? :)
I've been doing some googling trying to find info on how to plan for
what a website needs. Stuff like Does it need a forum, live support,
database driven etc. etc. Does anyone have a form that they use to
give to the client asking them to outline some ideas that they have
about the website?
What I'm looking for is something that I could give to a potential
client and ask them to describe some basic aspects of their target
audience, a rough idea of what they want it to look like, or at least
other sites that they like. Stuff like that..
Even if you don't have such a form, I'm sure you all have standard
questions you ask each client before giving a quote :)
Anyone want to share with the class?
If there is interest, I may even put it together on a webpage to help
future people :)
--
Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424
www.raoset.com
japruimraoset.com
attached mail follows:
Jason Pruim wrote:
> Hi Everyone,
>
> I know this isn't 100% on topic... But when is any post to this list
> 100% on topic? :)
>
> I've been doing some googling trying to find info on how to plan for
> what a website needs. Stuff like Does it need a forum, live support,
> database driven etc. etc. Does anyone have a form that they use to give
> to the client asking them to outline some ideas that they have about the
> website?
>
> What I'm looking for is something that I could give to a potential
> client and ask them to describe some basic aspects of their target
> audience, a rough idea of what they want it to look like, or at least
> other sites that they like. Stuff like that..
>
> Even if you don't have such a form, I'm sure you all have standard
> questions you ask each client before giving a quote :)
>
> Anyone want to share with the class?
>
> If there is interest, I may even put it together on a webpage to help
> future people :)
> --
>
> Jason Pruim
> Raoset Inc.
> Technology Manager
> MQC Specialist
> 3251 132nd ave
> Holland, MI, 49424
> www.raoset.com
> japruimraoset.com
I always take the simple approach, ask them what they want to
achieve/expect from the website. Then verbally work backwards with them
to figure out what the website needs in order to reach the clients goal.
(personally) In all honesty I'd stay away from any kind of form, as
they'll just pick "nice to have" boxes and end up with something
overpriced, not suited to there needs and you'll get complaints in 6
months time.
hope that makes sense!
ps: the only thing I've found useful that way after many years, is to
make the base site structure with very short text descriptions on each
page + links to the next page | and for god sake, leave the "home" page
will very very last!
Nathan
attached mail follows:
Nathan Nobbe wrote:
> i mean, i do understand the vserver concept, is LVS essentially the
> same as v-server,
> http://linux-vserver.org/Welcome_to_Linux-VServer.org ?
Hi Nathan,
they're two very different things. The VServer project makes multiple
servers out of one, LVS makes multiple physical servers appear as one.
With LVS you can basically have e.g. 50 physical boxes accessed as if
they were just one big server.
> also, i dont understand how LVS is used to implement a 'persistent'
> session. allow me to explain my disconnect.. so you are using
> virtual servers on a real system; what benefit, in the context of
> sessions does this provide over a single machine w/ 1 os? another
> fundamental disconnect is, how are you using these
> machines to store session state, a network filesystem?
Each physical server will store session information locally, probably on
a local filesystem. Depending on your needs you could have a
distributed filesystem or a DRDB setup, but you'd have other reason for
having those.
> also, in terms of scalability, isnt facebook proof that
> memcache can scale?
I'd misunderstood how memcached works, hence my misguided comment about
it's lack of scalability.
/Per Jessen, Zürich
attached mail follows:
On Feb 12, 2008 10:55 AM, Per Jessen <percomputer.org> wrote:
> Nathan Nobbe wrote:
>
> > i mean, i do understand the vserver concept, is LVS essentially the
> > same as v-server,
> > http://linux-vserver.org/Welcome_to_Linux-VServer.org ?
>
> Hi Nathan,
>
> they're two very different things. The VServer project makes multiple
> servers out of one, LVS makes multiple physical servers appear as one.
>
> With LVS you can basically have e.g. 50 physical boxes accessed as if
> they were just one big server.
>
> > also, i dont understand how LVS is used to implement a 'persistent'
> > session. allow me to explain my disconnect.. so you are using
> > virtual servers on a real system; what benefit, in the context of
> > sessions does this provide over a single machine w/ 1 os? another
> > fundamental disconnect is, how are you using these
> > machines to store session state, a network filesystem?
>
> Each physical server will store session information locally, probably on
> a local filesystem. Depending on your needs you could have a
> distributed filesystem or a DRDB setup, but you'd have other reason for
> having those.
>
> > also, in terms of scalability, isnt facebook proof that
> > memcache can scale?
>
> I'd misunderstood how memcached works, hence my misguided comment about
> it's lack of scalability.
>
>
> /Per Jessen, Zürich
excellent! thanks for your response,
now i am at least an enlightened newb :D
-nathan
- image/jpg attachment: image001.jpg
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]