OSEC

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 1 Mar 2007 08:05:48 -0000 Issue 4652

php-general-digest-helplists.php.net
Date: Thu Mar 01 2007 - 02:05:48 CST


php-general Digest 1 Mar 2007 08:05:48 -0000 Issue 4652

Topics (messages 249608 through 249642):

Re: SimpleXML & libxml options (XInclude)
        249608 by: Rob
        249613 by: Ben Roberts
        249616 by: Rob
        249617 by: Ben Roberts
        249618 by: Rob
        249620 by: Ben Roberts

Re: FTP issues
        249609 by: Richard Lynch

Re: ID problem
        249610 by: Richard Lynch

Re: IE6 session issues
        249611 by: Richard Lynch

Re: Combining sound files
        249612 by: Richard Lynch

Re: echo text - anti-spam-spider measure
        249614 by: Richard Lynch
        249615 by: Richard Lynch
        249623 by: Richard Lynch
        249639 by: Casey Chu

Re: how to display images stored in DB
        249619 by: Richard Lynch
        249627 by: Mark
        249630 by: Robert Cummings
        249634 by: markw.mohawksoft.com
        249637 by: Robert Cummings
        249638 by: steve

Re: operational musings
        249621 by: Richard Lynch
        249622 by: Richard Lynch
        249624 by: Bob Dusek
        249626 by: Richard Lynch
        249628 by: Bob Dusek

Re: Who in this list would you...
        249625 by: Richard Lynch

Problem with pgsql.so and extensions.
        249629 by: Marc Burgauer
        249632 by: Chris

Re: how to retrieve pictures from postgreSQL DB
        249631 by: Chris

auction scripts?
        249633 by: Lisa A
        249641 by: Stut

Re: Extract printable text from web page using preg_match
        249635 by: M5

Eregi error
        249636 by: Brad
        249640 by: Peter Lauri

best framework (pear vs zend framework)
        249642 by: Marco Sottana

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:


Ben Roberts wrote:

> I'm trying to get the SimpleXML extension to read an XML file and
> process the XInclude statements within the XML file.
>
> The SimpleXML docs state that libxml options may be specified using the
> predefined constants that are available when PHP is compiled with libxml
> support (as it is when you use SimpleXML).
> http://uk2.php.net/manual/en/function.simplexml-element-construct.php

LIBMLXML_XINLCUDE currently only works with XMLReader.

You would need to import your doc to DOM and then processes the xinclude:

   $xml_file = './master.xml';

   $xml = new SimpleXMLElement($xml_file, 0, true);
   $dom = dom_import_simplexml($xml);
   $dom->ownerDocument->xinclude();
        
   print_r($xml);

Rob

attached mail follows:


Rob wrote:
> Ben Roberts wrote:
>
>> I'm trying to get the SimpleXML extension to read an XML file and
>> process the XInclude statements within the XML file.
>>
>> The SimpleXML docs state that libxml options may be specified using
>> the predefined constants that are available when PHP is compiled with
>> libxml support (as it is when you use SimpleXML).
>> http://uk2.php.net/manual/en/function.simplexml-element-construct.php
>
> LIBMLXML_XINLCUDE currently only works with XMLReader.
>
> You would need to import your doc to DOM and then processes the xinclude:
>
> $xml_file = './master.xml';
>
> $xml = new SimpleXMLElement($xml_file, 0, true);
> $dom = dom_import_simplexml($xml);
> $dom->ownerDocument->xinclude();
>
> print_r($xml);
>
> Rob
>

Thanks Rob. That works. And it appears to work flawlessly if you
subsequently convert it back to a SimpleXML object too:

$xml = new SimpleXMLElement($xml_file, 0, true);

$dom = dom_import_simplexml($xml);
$dom->ownerDocument->xinclude();

$xml = simplexml_import_dom($dom);
Dump($xml);

I have to convert it back to the SimpleXML object as I have an existing
application that relies on the SimpleXML structure.

Is it likely that this will be supported directly by SimpleXML in future
versions of PHP?

Ben

attached mail follows:


Ben Roberts wrote:
> Thanks Rob. That works. And it appears to work flawlessly if you
> subsequently convert it back to a SimpleXML object too:
>
> $xml = new SimpleXMLElement($xml_file, 0, true);
>
> $dom = dom_import_simplexml($xml);
> $dom->ownerDocument->xinclude();
>
> $xml = simplexml_import_dom($dom);
> Dump($xml);
No need to even do that. The document is the same document (zero copy
which is why going back and forth is efficient), so when its changed by
the xinclude call, it is reflected in $xml already. Only reason you
would need to do conversions back and forth is if you need specific
nodes that might have been added/changed by the other extension. Here
you are using the same root element and dont have to worry about losing
any child references you might already have, so its a wasted call.
> Is it likely that this will be supported directly by SimpleXML in
> future versions of PHP?
Unless the libxml2 parser in SimpleXML can take advantage of the option,
an XInclude method is not going to be added to SimpleXML. For things
like that, and full XPath support, etc.., you need to interop with DOM
so SimpleXML can be kept simple.

Rob

attached mail follows:


Rob Richards wrote:
> No need to even do that. The document is the same document (zero copy
> which is why going back and forth is efficient), so when its changed by
> the xinclude call, it is reflected in $xml already. Only reason you
> would need to do conversions back and forth is if you need specific
> nodes that might have been added/changed by the other extension. Here
> you are using the same root element and dont have to worry about losing
> any child references you might already have, so its a wasted call.

So really when you perform:

   $dom = dom_import_simplexml($xml);

the $dom object is really created by taking a reference to the $xml
object rather than copying it? i.e. (I know this isn't real code)

   $dom = dom_import_simplexml(& $xml);

Is this correct?

attached mail follows:


Ben Roberts wrote:
> So really when you perform:
>
> $dom = dom_import_simplexml($xml);
>
> the $dom object is really created by taking a reference to the $xml
> object rather than copying it? i.e. (I know this isn't real code)
>
> $dom = dom_import_simplexml(& $xml);
Not exactly, but the idea is along those lines.
What is happening is that $dom (DOMElement in this case) now points to
the same libxml2 structure as does $xml (SimpleXMLElement).
So now when you modify the structure of the document with one, it is
reflected by the other because they are in the same document. This also
means that it is possible that objects can become invalid by changes
made in the other extension.

$sxe = new
SimpleXMLElement("<root><child><inner>text</inner></child></root>");
$sxechild = $sxe->child->inner[0];

$dom = dom_import_simplexml($sxe);
$dom->removeChild($dom->firstChild);

var_dump($sxechild);

PHP Warning: var_dump(): Node no longer exists in
/home/rrichards/temp.php on line 8
object(SimpleXMLElement)#3 (0) {
}
This shows that $sxechild is still an SimpleXMLElement, but warnings are
issues that the node it refers to in the document no longer exists.
Although I doubt someone use the code above, it is the smallest piece of
code I could write to demonstrate the possibility.

Rob

attached mail follows:


> Rob Richards wrote:
> Although I doubt someone use the code above, it is the smallest piece
> of code I could write to demonstrate the possibility.

Thanks Rob - that does demonstrate things nicely. Cheers for your help.

attached mail follows:


On Wed, February 28, 2007 8:21 am, Larry Bradley wrote:
> I've written a PHP program to "mirror" data on a local drive to a
> remote
> FTP server. It compares file mod times, and only uploads files that
> are
> newer. Works like a charm. Except ---

Did you consider just using rsync?...

> To examine the remote directories, I use ftp_rawlist() to get a
> directory
> listing which I parse. However, the file modification time does not
> have a
> year, and does not show the seconds. I get around this by "assuming"
> the
> year is the current one, and then compare the file times of the local
> and
> remote files ignoring local file seconds. If they are different, I use
> ftp_mdtm() to get the real remote time, and then do my compare. This
> slows
> things down a bit, as I have to go to the FTP server one more time.

If the minutes are different, why would you bother to check the
seconds?...

> Any thoughts on how to get around this?

> Is there a way to get a better
> directory listing?

I've seen some FTP servers that response to 'ls -als' with about what
you'd expect from the shell.

How they do it, I dunno, but I like it.

> Second and more serious problem is that when I FTP the file to the
> server,
> the file mod time gets set to the current (file-creation) time. The
> same
> thing happens in a local-to-local file copy using copy(), but I can
> use
> touch() to update the mod time.

rsync would fix this.

You could also look at scp which allows you to specify that you want
to maintain file attributes.

> Any thoughts on how I might get the remote FTP server to do the
> equivalent
> of touch()?

Actually, I should think you'd want to convince the server to "know"
when the file was REALLY created/modifed based on the local file, not
force the local file to look different just to accomodate the FTP
server.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:


On Wed, February 28, 2007 3:24 am, Delta Storm wrote:
> I'm building an CMS system (for practice and experience :)).
>
> And of course like many times before I have encountered a problem.
>
> The problem is:
>
> I have a index.php that takes the news from the database and publishes
> them. And by the end of every news on index.php I have a link ('<a
> href="showfullnews.php?id=$id">Show full news</a>')
>
> That leads to a page that has the full news.
>
> At the beginning of showfullnews i have a variable ( $id =
> $_GET['id']; )

echo "id starsts as $id<br />\n";

>
> And in index.php I have the following code:
>
> while ($row = mysql_fetch_array($result))
> {

echo "about to change id from '$id' to '$row[id]'<br />\n";

> $id= $row['id'];

> etc...
> }
>
> In the database I have two tables one for a short version of news for
> index.php and another for fullNews.
>
> In full news the query is: "select title,newsFull from fullnews where
> id='$id'";

echo $query, "<br />\n";

> In the database i'm 100% sure there is a id = 1 in both rows.
>
> I really dont know what is the problem.

Just echo out each variable in turn until you are sure it's what you
think it is.

Somewhere along the way, one of them isn't.

Also turn on E_NOTICE so you'll find any typos.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:


On Wed, February 28, 2007 3:21 am, Dave Goodchild wrote:
> OK. Blank entries means that as date is passed in and validated via
> forms,
> it is then entered into $_SESSION so data can be persistent as the
> user goes
> back and forth. These values are eventually entered into the database
> and
> are blank, whereas the few values that are entered from $_POST (ie
> credit
> card numbers that I don't want to carry around in the session) are
> fine.
>
> The system works in IE7, FF and Opera and has also worked on my local
> version of IE6. I have created a session name and send the
> Cache-control:private header, which fixed similar issues in the past,
> but no
> success in this case.

We can't begin to guess unless you publish your source code somewhere
online.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:


On Wed, February 28, 2007 8:28 am, tedd wrote:
> For the moment, I can use a HEX Editor and inspect the first 256
> bytes of a wav file and find out all the goodies therein, but do you
> know if I strip out the first 256 bytes can I then combine the files
> so they will work (providing the sample rates, frequencies, and such
> as the same)?

Probably not exactly like that.

One of the goodies is file length (actually, I think it's sample
count, but same smell).

So you are going to have to open both headers and plus up the numbers
to get the right new header.

I suspect most .wav readers are far less forgiving than .mp3 readers
due to their relative format age.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:


On Tue, February 27, 2007 10:22 pm, John Taylor-Johnston wrote:
> I need an anti-spam-spider measure for my site. Too many addresses are
> getting raked. In once instance, I created a flash page:
> http://erasethis.glquebec.org/English/contact.htm
> But I just don't have the time to create a flash image for every
> single
> instance, most of which come from dynamically printed PHP pages from a
> MySQL database.
>
> Could I dynamically create a flash image, input the email and tell the
> flash image to mailto:theaddress.com?
>
> Do anyone have a solution? Does one already exist?

http://php.net/ming
would let you do exactly that, assuming the Actionscript to send the
email will work.

> My idea was to create a PHP script and output to a png. But I see many
> problems, including:
>
> 1) How do I avoid echoing the email address in the <a href=""> tag?
> 2) How would I write a png that would be long and high enough?
> 3) How would the same script display the png?

You could "obfuscate" the address with html encoding, such as:
-> &#64; in the HTML
-> %40 in the URL

I believe the scrapers/spammers are still not bothering to defeat this
trivial exercise because they still get a million hits looking for
plain old emails.

> In short, I can't see far enough how to do this and avoid
> spider-raking
> in the HTML or header the content of the image.

I would suspect that every email is tied to some database record, like
an ID.

Provide a FORM which has only the ID in it, and lookup the email, and
send the email out yourself from your own server.

Yes, you could end up sending a LOT of email.

Or not, since you now control the sending with PHP and can refuse to
send in whatever scenario you find unacceptable.

For example, one of my sites does this but won't send more than 4
emails from any given IP address in one 24-hour period.

So a scraper/spammer would need to alter their IP every 4 POST
operations, which is really more work than they'll put into it.

On a super busy server with millions of users or millions of potential
recipients, this would probably be a big deal...

On MOST websites, you'll essentially be playing postman for a couple
legit emails a day, at most, and not having any problem with
scrapers/spammers.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:


You could also use %XX in HEX on the mailto:

On Tue, February 27, 2007 11:09 pm, Casey Chu wrote:
> It works. =P I tested it.
>
> Try it here! =P
>
> http://themfund.com/snippets/test.php
>
> On 2/27/07, Casey Chu <heavyccaseygmail.com> wrote:
>> I'm not sure with both of your questions. I'm too lazy to try.
>>
>> Untested: But to encode it, you would use
>>
>> preg_replace_callback('~([\d\w])~', create_function('$a', 'return
>> "&#".ord($a[0]).";";'), $theEmail);
>>
>> Hopefully that works?
>>
>> On 2/27/07, John Taylor-Johnston
>> <John.Taylor-Johnstoncegepsherbrooke.qc.ca> wrote:
>> > How do I encode it? And would the href tag work?
>> >
>> > Casey Chu wrote:
>> > > ^ So put that into a <a href> tag.
>> > >
>> > > On 2/27/07, Casey Chu <heavyccaseygmail.com> wrote:
>> > >> Try using Javascript? Or use all entities? For example:
>> > >> mailto:php-generallists.php.net would turn into
>> > >> &#109;&#97;&#105;&#108;&#116;&#111;&#58;&#112;&#104;&#112;&#45;&#103;&#101;&#110;&#101;&#114;&#97;&#108;&#64;&#108;&#105;&#115;&#116;&#115;&#46;&#112;&#104;&#112;&#46;&#110;&#101;&#116;
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> On 2/27/07, John Taylor-Johnston
>> > >> <John.Taylor-Johnstoncegepsherbrooke.qc.ca> wrote:
>> > >> > I need an anti-spam-spider measure for my site. Too many
>> addresses are
>> > >> > getting raked. In once instance, I created a flash page:
>> > >> > http://erasethis.glquebec.org/English/contact.htm
>> > >> > But I just don't have the time to create a flash image for
>> every
>> > >> single
>> > >> > instance, most of which come from dynamically printed PHP
>> pages from a
>> > >> > MySQL database.
>> > >> >
>> > >> > Could I dynamically create a flash image, input the email and
>> tell the
>> > >> > flash image to mailto:theaddress.com?
>> > >> >
>> > >> > Do anyone have a solution? Does one already exist?
>> > >> >
>> > >> > My idea was to create a PHP script and output to a png. But I
>> see many
>> > >> > problems, including:
>> > >> >
>> > >> > 1) How do I avoid echoing the email address in the <a
>> href=""> tag?
>> > >> > 2) How would I write a png that would be long and high
>> enough?
>> > >> > 3) How would the same script display the png?
>> > >> >
>> > >> > In short, I can't see far enough how to do this and avoid
>> > >> spider-raking
>> > >> > in the HTML or header the content of the image.
>> > >> >
>> > >> > Any advice, code or input would be appreciated,
>> > >> > John
>> > >> >
>> > >> > <a href="<?php
>> > >> >
>> > >> > #what do I put here?
>> > >> > $mydata->email = "mesomewhere.com";
>> > >> > echo $??????????;
>> > >> >
>> > >> > ?>"><img src="<?php
>> > >> > |header('Content-type: image/png');|
>> > >> > #How do I display the image?
>> > >> >
>> > >> > $mydata->email = "mesomewhere.com";
>> > >> > echo $??????????;
>> > >> >
>> > >> > ?>" width="???" height="???">
>> > >> >
>> > >> > --
>> > >> > PHP General Mailing List (http://www.php.net/)
>> > >> > To unsubscribe, visit: http://www.php.net/unsub.php
>> > >> >
>> > >> >
>> > >>
>> > >
>> >
>> > --
>> > PHP General Mailing List (http://www.php.net/)
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:


On Wed, February 28, 2007 1:20 am, Stut wrote:
> Of all the possible methods, entities are the easiest for bots to
> handle. They just need to decode the entities.
>
> More reliable methods involve using javascript to write out the
> mailto:
> tag. Do it in several statements. But even then, some of the smarter
> spiders will execute simple javascript like that. You can make it
> better
> by using onload to execute the javascript which means the spider will
> need to implement that, which I don't believe they do at the moment.
>
> Of course the best way is to use an image and don't link it. If it's
> just a way for visitors to contact you, use a contact form. You don't
> expose the email address and can control it a lot better.

I'm no expert, but as far as I can tell from my readings on this
subject, the reality is that spammers just don't bother to harvest
them.

Ongoing studies, older studies, newer studies.

Everybody knows that the spammers *could* decode HEX or even the JS
fairly trivially, but they don't.

There are many theories [*] as to why that is, but the empirical
evidence is that the obfuscation is very effective at reducing spam
dramatically, no matter how silly that seems.

* Maybe it's too much low hanging fruit. Maybe they don't want to
risk hitting honey-pot emails. Maybe anybody smart enough to
obfustcate is too smart to fall for the stupid spam anyway. ...

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:


http://themfund.com/snippets/test.php

Has %HEX, &#entity;, and even a entity version of the hex!

On 2/28/07, Richard Lynch <ceol-i-e.com> wrote:
> On Wed, February 28, 2007 1:20 am, Stut wrote:
> > Of all the possible methods, entities are the easiest for bots to
> > handle. They just need to decode the entities.
> >
> > More reliable methods involve using javascript to write out the
> > mailto:
> > tag. Do it in several statements. But even then, some of the smarter
> > spiders will execute simple javascript like that. You can make it
> > better
> > by using onload to execute the javascript which means the spider will
> > need to implement that, which I don't believe they do at the moment.
> >
> > Of course the best way is to use an image and don't link it. If it's
> > just a way for visitors to contact you, use a contact form. You don't
> > expose the email address and can control it a lot better.
>
> I'm no expert, but as far as I can tell from my readings on this
> subject, the reality is that spammers just don't bother to harvest
> them.
>
> Ongoing studies, older studies, newer studies.
>
> Everybody knows that the spammers *could* decode HEX or even the JS
> fairly trivially, but they don't.
>
> There are many theories [*] as to why that is, but the empirical
> evidence is that the obfuscation is very effective at reducing spam
> dramatically, no matter how silly that seems.
>
> * Maybe it's too much low hanging fruit. Maybe they don't want to
> risk hitting honey-pot emails. Maybe anybody smart enough to
> obfustcate is too smart to fall for the stupid spam anyway. ...
>
> --
> Some people have a "gift" link here.
> Know what I want?
> I want you to buy a CD from some starving artist.
> http://cdbaby.com/browse/from/lynch
> Yeah, I get a buck. So?
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

attached mail follows:


On Tue, February 27, 2007 8:03 pm, Kevin Waterson wrote:
> This one time, at band camp, "Richard Lynch" <ceol-i-e.com> wrote:
>
>> *ALL* of the arguments on this topic, and benchmarks, are in the PHP
>> General archives.
> I am not concerned with past benchmarks done by others, I am asking
> what
> current benchmarks this user has made to make his claim.

Why?

They'd be no more nor less meaningful than the previous benchmarks to
you personally.

Or maybe I've just lost the thread of conversation here...

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:


Kevin Waterson wrote:

> This one time, at band camp, zerof <zerofterra.com.br> wrote:
>
>> It is not a good practice to store pictures in DataBases, use links,
>> instead of.
>
> Rubbish, where are your benchmarks?

It has almost nothing to do with benchmarks.

Images are typically best supported in the form of files. They are more
easily manipulated by external tools.

The web browser sees an image as a single HTTP request. Invoking the PHP
script engine, parsing the script, and executing a SQL query to retrieve
the image from the database is less efficient than letting the web server
just send the file.

Image files do not need to be constrained by the rigid requirements of a
relational database.

I could go on, but it should be clear enough that putting images in a
database is not a good idea.

attached mail follows:


On Wed, 2007-02-28 at 17:04 -0500, Mark wrote:
> Kevin Waterson wrote:
>
> > This one time, at band camp, zerof <zerofterra.com.br> wrote:
> >
> >> It is not a good practice to store pictures in DataBases, use links,
> >> instead of.
> >
> > Rubbish, where are your benchmarks?
>
> It has almost nothing to do with benchmarks.
>
> Images are typically best supported in the form of files. They are more
> easily manipulated by external tools.
>
> The web browser sees an image as a single HTTP request. Invoking the PHP
> script engine, parsing the script, and executing a SQL query to retrieve
> the image from the database is less efficient than letting the web server
> just send the file.
>
> Image files do not need to be constrained by the rigid requirements of a
> relational database.
>
> I could go on, but it should be clear enough that putting images in a
> database is not a good idea.

What about when you need to share those files across a 50 node network?
I'd keep it in a database, then when I need it cache a local copy on the
filesystem. Then I can just check the timestamp in the database to see
if the file has changed. Voila, multi-node high availability images.

Seems better than have a local copy of every single image. I guess the
answer is... it depends on what you're doing!

Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'

attached mail follows:


> On Wed, 2007-02-28 at 17:04 -0500, Mark wrote:
>> Kevin Waterson wrote:
>>
>> > This one time, at band camp, zerof <zerofterra.com.br> wrote:
>> >
>> >> It is not a good practice to store pictures in DataBases, use links,
>> >> instead of.
>> >
>> > Rubbish, where are your benchmarks?
>>
>> It has almost nothing to do with benchmarks.
>>
>> Images are typically best supported in the form of files. They are more
>> easily manipulated by external tools.
>>
>> The web browser sees an image as a single HTTP request. Invoking the PHP
>> script engine, parsing the script, and executing a SQL query to retrieve
>> the image from the database is less efficient than letting the web
>> server
>> just send the file.
>>
>> Image files do not need to be constrained by the rigid requirements of a
>> relational database.
>>
>> I could go on, but it should be clear enough that putting images in a
>> database is not a good idea.
>
> What about when you need to share those files across a 50 node network?

Without more information about the nodes and the network design, I can't
offer a good argument against it, but I can say, that given any rational
system, bitmap images are better as discrete files than contents of a
database.

If you give me more information, I can counter with more specifics.

> I'd keep it in a database, then when I need it cache a local copy on the
> filesystem. Then I can just check the timestamp in the database to see
> if the file has changed. Voila, multi-node high availability images.

You can do that sort of operation with any number of other tools more
efficiently.

>
> Seems better than have a local copy of every single image. I guess the
> answer is... it depends on what you're doing!

No, it just seems like if the only tool you are comfortable with is a
hammer, then every job is more or less exactly like a nail.

Databases are great tools, but there are many tasks which they can do,
just not well.

attached mail follows:


On Wed, 2007-02-28 at 22:08 -0500, markwmohawksoft.com wrote:
> > On Wed, 2007-02-28 at 17:04 -0500, Mark wrote:
> >> Kevin Waterson wrote:
> >>
> >> > This one time, at band camp, zerof <zerofterra.com.br> wrote:
> >> >
> >> >> It is not a good practice to store pictures in DataBases, use links,
> >> >> instead of.
> >> >
> >> > Rubbish, where are your benchmarks?
> >>
> >> It has almost nothing to do with benchmarks.
> >>
> >> Images are typically best supported in the form of files. They are more
> >> easily manipulated by external tools.
> >>
> >> The web browser sees an image as a single HTTP request. Invoking the PHP
> >> script engine, parsing the script, and executing a SQL query to retrieve
> >> the image from the database is less efficient than letting the web
> >> server
> >> just send the file.
> >>
> >> Image files do not need to be constrained by the rigid requirements of a
> >> relational database.
> >>
> >> I could go on, but it should be clear enough that putting images in a
> >> database is not a good idea.
> >
> > What about when you need to share those files across a 50 node network?
>
> Without more information about the nodes and the network design, I can't
> offer a good argument against it,

Oh, let's just say 50 nodes across the internet -- no specific location.
And remember, I don't want to have every file on every server, I may
have petabytes of data. Feel free to comment.

> but I can say, that given any rational
> system, bitmap images are better as discrete files than contents of a
> database.

I'd argue that's only true if you need to modify the contents, and you
can't do so without a copy on the filesystem. Otherwise I'd have to
disagree. Databases implement their own filesystem for the most parts.
In fact many newer bleeding edge filesystems are practically database
implementations. As such, the OS and the Database are merely layers over
the raw medium. Sure the database is often layered over the OS's
implementation of the filesystem, but that is not necessaril true since
some databases support raw access in which case they're performance is
probably just as good as the OS (and quite probably better if you want
to store meta information about the file and it's data).

> If you give me more information, I can counter with more specifics.

I don't have specifics, I was just giving a sample scenario from the top
of my head.

> > I'd keep it in a database, then when I need it cache a local copy on the
> > filesystem. Then I can just check the timestamp in the database to see
> > if the file has changed. Voila, multi-node high availability images.
>
> You can do that sort of operation with any number of other tools more
> efficiently.

Maybe... and even so, are they just as convenient? Why implement
multiple protocols when one will suffice? KISS!

> > Seems better than have a local copy of every single image. I guess the
> > answer is... it depends on what you're doing!
>
> No, it just seems like if the only tool you are comfortable with is a
> hammer, then every job is more or less exactly like a nail.

I'm quite comfortable with many tools. But if it looks like a duck, and
walks like a duck, then I'm sure the hammer will suffice.

> Databases are great tools, but there are many tasks which they can do,
> just not well.

Well one thing I know the webserver itself and the filesystem can't do
is check the credentials of a logged in user to see if they are allowed
the file. Well, I guess the webserver could do it... sort of... with
http auth. Wonder if that works with many custom authentication
systems... I presume you would somehow cram that into the webserver? I
guess if the only tool with which you're comfortable is a screwdriver,
then every job is more or less exactly like a screw. As such, I think
you're screwed. Remember, I said it depends on what you're doing, you
said "no", and well quite frankly you're wrong, because your screw and
screwdriver mentality doesn't work in every imaginable scenario.

Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'

attached mail follows:


> > >> The web browser sees an image as a single HTTP request. Invoking the PHP
> > >> script engine, parsing the script, and executing a SQL query to retrieve
> > >> the image from the database is less efficient than letting the web
> > >> server
> > >> just send the file.

In a simple setup, that is probably true. However, if you use PHP to
do authentication or throttling, then the engine is already there. On
the flip side, you can use sendfile() or on Lighhttpd you can push the
sending of the file back to the webserver using x-sendfile.

> > >> Image files do not need to be constrained by the rigid requirements of a
> > >> relational database.

File systems are not immune to constraints. For example, ext3 only
allows 32000 subdirectories. So if you gave each user a directory to
upload files to, you would be stuck at a max of 32000 users. Or start
going to silly things like /S/t/e/Steve.gif

More constaints below..

> > > What about when you need to share those files across a 50 node network?

Webfarm scenarios do come to mind. There is an issue of how to sync
all webservers to have all files. Then again, if you are using 50
webservers, the chances of them all being able to house all your files
(1 petabyte, as an example given) is not very good.

> some databases support raw access in which case they're performance is
> probably just as good as the OS (and quite probably better if you want
> to store meta information about the file and it's data).

While the database method makes for a good way of doing offsite
backups (replicating out to a slave), the database can easily become a
choke point as well.

> > > I'd keep it in a database, then when I need it cache a local copy on the
> > > filesystem. Then I can just check the timestamp in the database to see
> > > if the file has changed. Voila, multi-node high availability images.

You will need to keep information about what you are caching so that
you can prune. Best choice I guess would be to keep a local sqlite db
on the webserver to keep track. However, you had better understand
your filesystem. In ext3, for example, if you have a lot of files in a
folder you will likely use the dir_index option when creating the
partition. But realize that deleting files does not delete leaf nodes
of the btree, which can have all sorts of performance and disk usage
effects that are non-obvious.

There are hybid models, of course. mogilefs for example uses mysql to
store data file info, but not the file itself. Instead a series of
programs are used to spread the files across a farm of servers, using
mutiple replicas for fault tolerance and performance reasons. Those
files are stored using a combination of directory mazes and hashes to
avoid typical filesystem issues.

So there are lots of ways to deal with the issue. Depends on your
constraints on time, complexity, and scalability. After all, if you
only have 10,000 users, who cares! 100 million might be different.

-s

attached mail follows:


On Tue, February 27, 2007 6:59 pm, Jay Blanchard wrote:
> I had an interesting thought after watching a demo of a POS system and
> wondered if the same type of methodology could be applied in a PHP
> application. I haven't thought this all the way through, but a
> fully-hatched idea like this could signal a major change in
> applications
> designed with PHP.
>
> In the POS if the network connectivity was lost the store could
> continue
> to operate, once the network connectivity was restored the data from
> each store would sync back up and data would be sent to the central
> server, yadda, yadda, yadda. Of course this is in a client/server
> application with an executable residing on each workstation.
>
> So, if you wanted to do this with PHP you would likely have to have a
> local web /database server (each store), establish a socket (primary
> and
> store servers?) to watch for an outage/restore and then write the code
> to support the sync up. Can it be done with PHP? It would definitely
> be
> worth the trouble given the frequency that connections to stores get
> lost.

Sure you could do that!

You could set up mini MySQL servers on the local client, or you could
just use a text file, or perhaps SQLLite.

You could even simplify things quite a bit by having the main
application ALWAYS just write to the local storage.

A cron job or second thread/task/process would be run to always be
pushing the stored data up to the server.

And then some kind of heartbeat to make it go "beep" when it's
off-line for more than X seconds.

This would be more resilient to temporary outages, and get the tricky
sync stuff, as well as the network connection testing, out of the main
application.

I'm betting somebody has already done this kind of thing with PHP,
actually. Sorry.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:


Perhaps try just opening TWO old-school sockets, one for write, one
for read...

On Tue, February 27, 2007 8:12 pm, Bob Dusek wrote:
> The company I work for is currently doing this... using PHP in a
> retail
> environment, with a Linux server in every store, talking to the POS
> controller via a socket, storing data in a database (postgres), and
> processing retail transactions in real-time. And, sending results of
> those transactions to a central server (which isn't running Linux,
> PHP,
> or Apache).
>
> I'm finding the PHP socket support to be unreliable, though.
>
> Everything's fine when we have one socket open to talk to the store
> controller. I open the socket and bind to an address:port, the store
> controller connects to it just fine, and we move on.
>
> However, right now, we're using Postgres as a queue between two
> programs
> that are processing transactions. I'm trying to get rid of Postgres
> and
> use a pair of IPC sockets (created with socket_create_pair() and using
> pcntl_fork()).
>
> The IPC sockets seem to be totally unreliable, at this point.
> Sometimes, when I call socket_write(), the function just never
> returns.
> My application doesn't die.... but, the line of code immediately
> following the socket_write() function never gets executed in the
> parent
> process. The child process receives the data and logs it
> successfully.
> So, I know the socket_write function is getting called and doing
> something. It just never returns.
>
> Anyone here have any ideas?
>
> I can send more details, and even chunks of pertinent code.
>
>> -----Original Message-----
>> From: Robert Cummings [mailto:robertinterjinn.com]
>> Sent: Tuesday, February 27, 2007 8:13 PM
>> To: Jay Blanchard
>> Cc: php-generallists.php.net
>> Subject: Re: [PHP] operational musings
>>
>> On Tue, 2007-02-27 at 18:59 -0600, Jay Blanchard wrote:
>> > Howdy cats and kittens!
>> >
>> > I had an interesting thought after watching a demo of a POS
>> system and
>> > wondered if the same type of methodology could be applied in a PHP
>> > application. I haven't thought this all the way through, but a
>> > fully-hatched idea like this could signal a major change in
>> applications
>> > designed with PHP.
>> >
>> > In the POS if the network connectivity was lost the store
>> could continue
>> > to operate, once the network connectivity was restored the data
>> from
>> > each store would sync back up and data would be sent to the
>> central
>> > server, yadda, yadda, yadda. Of course this is in a client/server
>> > application with an executable residing on each workstation.
>> >
>> > So, if you wanted to do this with PHP you would likely have
>> to have a
>> > local web /database server (each store), establish a socket
>> (primary and
>> > store servers?) to watch for an outage/restore and then
>> write the code
>> > to support the sync up. Can it be done with PHP? It would
>> definitely be
>> > worth the trouble given the frequency that connections to stores
>> get
>> > lost.
>>
>> Let's make a check list:
>>
>> local webserver -- check
>> local database server -- check
>> socket support -- check
>> write code -- check
>>
>> All signs point to YES :)
>>
>> Cheers,
>> Rob.
>> --
>> .------------------------------------------------------------.
>> | InterJinn Application Framework - http://www.interjinn.com |
>> :------------------------------------------------------------:
>> | An application and templating framework for PHP. Boasting |
>> | a powerful, scalable system for accessing system services |
>> | such as forms, properties, sessions, and caches. InterJinn |
>> | also provides an extremely flexible architecture for |
>> | creating re-usable components quickly and easily. |
>> `------------------------------------------------------------'
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:


Is there a well-known bug I'm up against with the IPC socket pair?

If I were to revert to a standard socket approach (ie. I already posted
an issue with the standard socket and nobody volunteered any help, so I
switched to IPC sockets)...

aren't sockets supposed to be two-way communication?

> -----Original Message-----
> From: Richard Lynch [mailto:ceol-i-e.com]
> Sent: Wednesday, February 28, 2007 4:11 PM
> To: Bob Dusek
> Cc: Robert Cummings; Jay Blanchard; php-generallists.php.net
> Subject: RE: [PHP] operational musings
>
> Perhaps try just opening TWO old-school sockets, one for write, one
> for read...
>
> On Tue, February 27, 2007 8:12 pm, Bob Dusek wrote:
> > The company I work for is currently doing this... using PHP in a
> > retail
> > environment, with a Linux server in every store, talking to the POS
> > controller via a socket, storing data in a database (postgres), and
> > processing retail transactions in real-time. And, sending
> results of
> > those transactions to a central server (which isn't running Linux,
> > PHP,
> > or Apache).
> >
> > I'm finding the PHP socket support to be unreliable, though.
> >
> > Everything's fine when we have one socket open to talk to the store
> > controller. I open the socket and bind to an address:port,
> the store
> > controller connects to it just fine, and we move on.
> >
> > However, right now, we're using Postgres as a queue between two
> > programs
> > that are processing transactions. I'm trying to get rid of Postgres
> > and
> > use a pair of IPC sockets (created with
> socket_create_pair() and using
> > pcntl_fork()).
> >
> > The IPC sockets seem to be totally unreliable, at this point.
> > Sometimes, when I call socket_write(), the function just never
> > returns.
> > My application doesn't die.... but, the line of code immediately
> > following the socket_write() function never gets executed in the
> > parent
> > process. The child process receives the data and logs it
> > successfully.
> > So, I know the socket_write function is getting called and doing
> > something. It just never returns.
> >
> > Anyone here have any ideas?
> >
> > I can send more details, and even chunks of pertinent code.
> >
> >> -----Original Message-----
> >> From: Robert Cummings [mailto:robertinterjinn.com]
> >> Sent: Tuesday, February 27, 2007 8:13 PM
> >> To: Jay Blanchard
> >> Cc: php-generallists.php.net
> >> Subject: Re: [PHP] operational musings
> >>
> >> On Tue, 2007-02-27 at 18:59 -0600, Jay Blanchard wrote:
> >> > Howdy cats and kittens!
> >> >
> >> > I had an interesting thought after watching a demo of a POS
> >> system and
> >> > wondered if the same type of methodology could be
> applied in a PHP
> >> > application. I haven't thought this all the way through, but a
> >> > fully-hatched idea like this could signal a major change in
> >> applications
> >> > designed with PHP.
> >> >
> >> > In the POS if the network connectivity was lost the store
> >> could continue
> >> > to operate, once the network connectivity was restored the data
> >> from
> >> > each store would sync back up and data would be sent to the
> >> central
> >> > server, yadda, yadda, yadda. Of course this is in a client/server
> >> > application with an executable residing on each workstation.
> >> >
> >> > So, if you wanted to do this with PHP you would likely have
> >> to have a
> >> > local web /database server (each store), establish a socket
> >> (primary and
> >> > store servers?) to watch for an outage/restore and then
> >> write the code
> >> > to support the sync up. Can it be done with PHP? It would
> >> definitely be
> >> > worth the trouble given the frequency that connections to stores
> >> get
> >> > lost.
> >>
> >> Let's make a check list:
> >>
> >> local webserver -- check
> >> local database server -- check
> >> socket support -- check
> >> write code -- check
> >>
> >> All signs point to YES :)
> >>
> >> Cheers,
> >> Rob.
> >> --
> >> .------------------------------------------------------------.
> >> | InterJinn Application Framework - http://www.interjinn.com |
> >> :------------------------------------------------------------:
> >> | An application and templating framework for PHP. Boasting |
> >> | a powerful, scalable system for accessing system services |
> >> | such as forms, properties, sessions, and caches. InterJinn |
> >> | also provides an extremely flexible architecture for |
> >> | creating re-usable components quickly and easily. |
> >> `------------------------------------------------------------'
> >>
> >> --
> >> PHP General Mailing List (http://www.php.net/)
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
> --
> Some people have a "gift" link here.
> Know what I want?
> I want you to buy a CD from some starving artist.
> http://cdbaby.com/browse/from/lynch
> Yeah, I get a buck. So?
>
>

attached mail follows:


On Wed, February 28, 2007 3:32 pm, Bob Dusek wrote:
> Is there a well-known bug I'm up against with the IPC socket pair?
...
> aren't sockets supposed to be two-way communication?

Put it this way...

If my memory serves me correctly, and understanding that I'm talking
about several years of list reading/posting boiled down to a couple
paragraphs, and my memory HAS proven faulty in the past...

I tried to do 2-way sockets and failed, filed a bug report, had it
marked as bogus, and used 2 one-way sockets and went on with life.

Others have posted problems in this same area, switch to 2 one-way
socket, and posted "hey, it works!"

Still others have had problems with sockets just up and dying no
matter what, however, so there is no promise it will work. Only a
better chance.

I have NO IDEA what the new-fangled socket pair thingie is, how it
works, how it's supposed to work, or if it's even implemented any
different than just 2 one-way sockets, and I'm just asking you to
waste your time doing in PHP what is already failing in C.

But it should take you, what?, 5 minutes to try it and find out if
it's better/worse? Okay, call it a day by the time you get done
fixing typos and silly mistakes and really get down to a real test.
Plus another 4 days to be convinced it really really works, or that
the failure is consistently bad enough to be a true problem.

For a true check on known problems, surf to http://bugs.php.net

Way better than my memory, that's for sure. :-)

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:


Wow. That pretty much sums it up!

I'll probably give the standard sockets another try. I'll report back
on my problems.
 

> -----Original Message-----
> From: Richard Lynch [mailto:ceol-i-e.com]
> Sent: Wednesday, February 28, 2007 4:32 PM
> To: Bob Dusek
> Cc: Robert Cummings; Jay Blanchard; php-generallists.php.net
> Subject: RE: [PHP] operational musings
>
> On Wed, February 28, 2007 3:32 pm, Bob Dusek wrote:
> > Is there a well-known bug I'm up against with the IPC socket pair?
> ...
> > aren't sockets supposed to be two-way communication?
>
> Put it this way...
>
> If my memory serves me correctly, and understanding that I'm talking
> about several years of list reading/posting boiled down to a couple
> paragraphs, and my memory HAS proven faulty in the past...
>
> I tried to do 2-way sockets and failed, filed a bug report, had it
> marked as bogus, and used 2 one-way sockets and went on with life.
>
> Others have posted problems in this same area, switch to 2 one-way
> socket, and posted "hey, it works!"
>
> Still others have had problems with sockets just up and dying no
> matter what, however, so there is no promise it will work. Only a
> better chance.
>
> I have NO IDEA what the new-fangled socket pair thingie is, how it
> works, how it's supposed to work, or if it's even implemented any
> different than just 2 one-way sockets, and I'm just asking you to
> waste your time doing in PHP what is already failing in C.
>
> But it should take you, what?, 5 minutes to try it and find out if
> it's better/worse? Okay, call it a day by the time you get done
> fixing typos and silly mistakes and really get down to a real test.
> Plus another 4 days to be convinced it really really works, or that
> the failure is consistently bad enough to be a true problem.
>
> For a true check on known problems, surf to http://bugs.php.net
>
> Way better than my memory, that's for sure. :-)
>
> --
> Some people have a "gift" link here.
> Know what I want?
> I want you to buy a CD from some starving artist.
> http://cdbaby.com/browse/from/lynch
> Yeah, I get a buck. So?
>
>

attached mail follows:


On Tue, February 27, 2007 6:41 pm, Jay Blanchard wrote:
> [snip]
> He would need to work in-house. And the location is somewhere in
> Scandinavia. He could work as sub contractor or employed for my
> company.
> [/snip]
>
> I don't know too many list denizens who live in Scandinavia, so that
> severely limits your choices.

I'm sure I know several list denziens who live in Scandinavia, but I
have no idea which ones they are. :-)

Richard "the only thing worse than my face recognition is my
geography" Lynch

Post the job around on some boards with very clear requirements and
see what resumes come in. Seems to be effective for most.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

attached mail follows:


I found various links via Google mentioning the problem of ordering
the extension in the ini file. In my case this hasn't produced quite
the result. I haven't found an order that works for me.

Here the problem:

Freebsd 6
apache 1.3.34
PHP 5.2.1

I am using the ports collection and I have done a complete update
prior of attempting building PHP5.

My apache crashes with a "exit on signal 11 (core dumped)" on
restart. The culprit seems to be the pgsql.so extension in the ini file.
I found a work around, which might shed some light to people who
understand the extension mechanism.

If I want to restart apache, I first edit the extension.ini file and
out-comment (using a #) the line with pgsql.so. I then restart
apache. Then I edit the extension.ini file again and remove the hash.
Then I restart apache again and it works.

I tried this repeatedly tonight and it seems to "hold". I will be
monitoring the server of course.

As I haven't found an order that works, I added my list of extensions
and PHP configuration options at the end.

Can anybody offer any help?

Cheers,

Marc

extension=pgsql.so
extension=session.so
extension=bcmath.so
extension=calendar.so
extension=curl.so
extension=dom.so
extension=exif.so
extension=filter.so
extension=gd.so
extension=gettext.so
extension=iconv.so
extension=imap.so
extension=json.so
extension=pcre.so
extension=posix.so
extension=readline.so
extension=simplexml.so
extension=soap.so
extension=spl.so
extension=tokenizer.so
extension=xml.so
extension=xmlreader.so
extension=xmlwriter.so
extension=xsl.so
extension=zip.so
extension=zlib.so
extension=mysql.so

'./configure' '--enable-versioning' '--with-layout=GNU' '--with-
config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--enable-
libxml' '--with-libxml-dir=/usr/local' '--enable-reflection' '--
program-prefix=' '--disable-cgi' '--with-apxs=/usr/local/sbin/apxs'
'--with-regex=php' '--with-zend-vm=CALL' '--enable-debug' '--disable-
ipv6' '--prefix=/usr/local'

Here some links documenting the problem:

http://www-gatago.com/muc/lists/freebsd/ports/40745984.html
http://www.pingle.org/2006/10/18/php-crashes-extensions/
http://marc.theaimsgroup.com/?l=php-db&m=114994519214164&w=2

attached mail follows:


Marc Burgauer wrote:
> I found various links via Google mentioning the problem of ordering the
> extension in the ini file. In my case this hasn't produced quite the
> result. I haven't found an order that works for me.
>
> Here the problem:
>
> Freebsd 6
> apache 1.3.34
> PHP 5.2.1
>
> I am using the ports collection and I have done a complete update prior
> of attempting building PHP5.
>
> My apache crashes with a "exit on signal 11 (core dumped)" on restart.
> The culprit seems to be the pgsql.so extension in the ini file.
> I found a work around, which might shed some light to people who
> understand the extension mechanism.

Could be a version mismatch (ie the pgsql.so is compiled for php 4.x and
the rest are for php 5.x).

Having said that, the internals list would be a better place to ask
because they would be able to help you debug/work out exactly what's
going on (they're the C coders, we're just the plebs who use the end
result ;) ).

--
Postgresql & php tutorials
http://www.designmagick.com/

attached mail follows:


tedd wrote:
> At 5:12 PM -0600 2/27/07, Richard Lynch wrote:
>> Personally, I think your first mistake was putting the image into the
>> DB at all.
>>
>> Unless you're the CIA doing pixel comparisons actually in SQL stored
>> procedures or something. :-)
>
> Richard:
>
> I highly respect your opinion and on this list you provide tremendous
> help -- however -- I must disagree with you about storing images in
> dB's. Both techniques (using dB or the file system) have their up-sides
> and down-sides and neither have anything to do about CIA pixel comparisons?
>
> This idea of CIA pixel comparisons has been brought up before and it's
> pointless. There is no way for anyone to do a pixel search in MySQL.
> Images are not text and thus can't be subject to a "full text" like
> search. There are no functions in MySQL that will permit pixel searches
> AND that isn't important anyway -- not everything stored in a dB has to
> be search-able. That's not a requirement for entry!
>
> When someone uses a dB for storing images, that's what they are doing --
> storing. I never store images without other data, like image type, size,
> description and such. So, why would I want to separate out that single
> attribute from a record and store that in a remote file system when I
> could just as easily store it in a dB? It's like saying "Never use css
> to display an image, only use html" when both work well under different
> needs.
>
> Furthermore, I have yet to talk with a single MySQL expert nor read a
> single MySQL book that claims what you claim. Could you be mistaken?
> Perhaps you might rethink your position. You know, we all learn -- I do
> everyday.

Like Rob said in a different thread, it depends on what you're doing.

If you're pulling out the image every single time from the db - that's
bad - because your browser will never be able to cache it and you're
putting more strain on the server because it will have to fetch the
image from the database every single page request.

If you're storing it in the db and creating a local cache copy which can
be expired (through cron or some other means), that's good. You're
reducing server load by having the local copy and have the advantage of
replication in the database to distribute the image around.

--
Postgresql & php tutorials
http://www.designmagick.com/

attached mail follows:


I have a client that bought some property that he'd like to have a website
and have people bid on the land? Does anyone know of any software or could
write something simple for me to put this on his site?
thanks,
Lisa A

attached mail follows:


Lisa A wrote:
> I have a client that bought some property that he'd like to have a website
> and have people bid on the land? Does anyone know of any software or could
> write something simple for me to put this on his site?

This wheel is not simply a round object, and it already exists...
http://ebay.com/

-Stut

attached mail follows:


On 28-Feb-07, at 1:48 AM, Colin Guthrie wrote:

> M5 wrote:
>> No, it's not a very good solution. Striptags will leave everything
>> within <head>, <style> and <script> (in the body or out). Comments
>> are
>> also included.
>>
>> I know it's possible to use non reg-ex strpos/substr to extra
>> everything
>> within <body>, but as another poster correctly said, this assumes a
>> consistent HTML document (which there is not).
>>
>> I realize now that such a regex would be rather sophisticated, but I
>> thought surely it must exist, since text-scrapping the readable
>> content
>> of a web page must not be rare.
>
> Said it before, but low-tech solution is to use program "lynx" with
> the
> -dump argument and capture the output back to PHP. I'm assuming you
> are
> on Linux or OSX I guess as I've not heard of using lynx on
> windows.....

Thanks, that sounds like a good direction. And yes, I'm on OS X.

> There are loads of command line options to control the way lynx
> displays
> the output so you have a very fine grain of control here.
>
> Col
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

attached mail follows:


Hey all,
I have been having some trouble with the "eregi" function. I have the
following piece of code in my application:

    function standard_input($input, $min=0, $max=50){
        if (strlen($input) <= $max and strlen($input) >= $min ) {
            $pattern = '^[a-z0-9\!\_ \.- ,/]*$';
            if(!eregi($pattern, $input)){
                return false;
            }else{
                return true;
            }
        }else{
            return false;
        }
       
    }

And i am running PHP version 5.2.1

I receive the following error:
*Warning*: eregi() [function.eregi
<http://idontwanttouse.net/MeetMyMate/Bin/Debug/function.eregi>]:
REG_ERANGE in *[File Location]* on line *287

*Any ideas what might cause this? Googling REG_ERANGE only showed more
questions.

attached mail follows:


Not sure, but I don't think you should escape all those characters inside of
the character class. I might be wrong. However, that might not have anything
to do with the error. But I do think you need to escape the / in the end...
And the - you should have in the beginning of the character class, otherwise
it will be treated as a range.

Best regards,
Peter Lauri

www.dwsasia.com - company web site
www.lauri.se - personal web site
www.carbonfree.org.uk - become Carbon Free

-----Original Message-----
From: Brad [mailto:bradtrueguava.com]
Sent: Thursday, March 01, 2007 5:09 AM
To: PHP Mailing
Subject: [PHP] Eregi error

Hey all,
I have been having some trouble with the "eregi" function. I have the
following piece of code in my application:

    function standard_input($input, $min=0, $max=50){
        if (strlen($input) <= $max and strlen($input) >= $min ) {
            $pattern = '^[a-z0-9\!\_ \.- ,/]*$';
            if(!eregi($pattern, $input)){
                return false;
            }else{
                return true;
            }
        }else{
            return false;
        }
       
    }

And i am running PHP version 5.2.1

I receive the following error:
*Warning*: eregi() [function.eregi
<http://idontwanttouse.net/MeetMyMate/Bin/Debug/function.eregi>]:
REG_ERANGE in *[File Location]* on line *287

*Any ideas what might cause this? Googling REG_ERANGE only showed more
questions.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

attached mail follows:


which is the best framework ? pear or zend framework?