php-general Digest 3 Mar 2007 08:54:35 -0000 Issue 4656
Topics (messages 249741 through 249758):
Re: how to display images stored in DB
249741 by: steve
249744 by: markw.mohawksoft.com
249746 by: steve
249747 by: Roman Neuhauser
249749 by: Børge Holen
249750 by: markw.mohawksoft.com
Using mysqli_stmt_bind_param in a class - with variable parameters?
249742 by: Christian Heinrich
Re: how to display images stored in DB*
249743 by: markw.mohawksoft.com
249745 by: steve
249751 by: markw.mohawksoft.com
249752 by: Robert Cummings
249754 by: markw.mohawksoft.com
249755 by: Robert Cummings
Re: Your input would be appreciated.
249748 by: Haydar TUNA
Re: best framework (pear vs zend framework)
249753 by: Kevin Waterson
Re: problems with thumbnail image
249756 by: Punit Neb
php-4.4.* on x86_64
249757 by: Michael Kress
Re: advise on consulting fees
249758 by: Haydar Tuna
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
> But storing them in the DB invariably ends up with too many issues
> involving DB storage size and query buffer size, compounded by data
> escaping/security issues.
This on the other hand... I'm a newbie, whatever your saying, BUT and it is a
big one; The data has to be escaped anyway, the binary object has to be
checked for security breaches with or without the database, so this is reason
is by all means wrongly put.
Depends. Use a prepared statement and mysqli for example, and there is
no escaping.
You should still do a virus scan first, however. Doesn't matter how
you store things.
As a newbie, is storing an image in a dB a "good" thing or a "bad" thing?
I tend to go with "depends". We actually store files in a DB in
development, as those machines are separate from the grid. Since some
are windows, linux, and MacOS, it is far easier to store in a DB than
have different code for each development machine depending on their
filesystem. Otherwise, in production, neither way really works, so
there is the hybrid way I alluded to before.
If you are on a hosted server, you may have different filesystem and
database limits for storage. That could make the decision for you.
--- End Message ---
--- Begin Message ---
>> > Not in my environment. All db servers have RAID 10 over 8 SCSI 15K
>> > disks. Pulling from them is always faster than a webserver pulling
>> > from its SATA drive.
>>
>> That's not exactly an apples to apples comparison.
>
> That is true, and sort of the point.
Not really, anything that you provide for the database, could equally be
used for the image server.
>
> However, the whole thing started because someone was asking a trivial
> question. The assumption there is that they are on a hosted
> environment, likely with the the web server and the database on the
> same server. Chances are the filesystem will be a better bet for them
> for speed. But on such a system, the speed difference may not be much
> of a concern.
>
> Where I am, I am forced to think about different things, so my
> viewpoint may be improperly colored. Its completely random that I'm
> posting to this list at all...
>
>> > Also, there is issue of going to the database and going to the
>> > filesystem. Timing wise, you
>>
>> Please explain.
>
> I'm making assumptions about the layout again. The database will
> likely already have the table files opened, but will need a seek to
> get the data. The webserver will have to do an additional seek (I was
> assuming on a far slower drive system, and likely twice for stat and
> read).
I'm not sure I trust this assessment.If it is an often used image it will
be in OS level cache. If it is not, then you will have the I/O.
Regardless, it will be using SQL database cache blocks and reduce the
efficacy of the SQL cache.
>
>> Putting the files in the DB doesn't always remove extra
>> cleanup/management
>> stuff. Sometimes the database stores binary objects as files and
>> sometimes
>> they don't get deleted correctly.
>
> I'm dying to know what database you are using that puts every blob in
> a separate file these days.
>
--- End Message ---
--- Begin Message ---
> I'm making assumptions about the layout again. The database will
> likely already have the table files opened, but will need a seek to
> get the data. The webserver will have to do an additional seek (I was
> assuming on a far slower drive system, and likely twice for stat and
> read).
I'm not sure I trust this assessment.If it is an often used image it will
be in OS level cache. If it is not, then you will have the I/O.
Regardless, it will be using SQL database cache blocks and reduce the
efficacy of the SQL cache.
Remember, I don't use a db to store images, for a variety of reasons,
mostly in that centralized repositories of anything don't scale.
However, if your hardware is far more than than you userbase will
need, the SQL server's caching won't matter, and it will be faster.
Not that it matters, since it would be a more expensive setup than
necessary. Ease of programming wise, or in the one case where we use
it: ease of developer setups, it works better. Those are really just
configuration issues and a syncing issues across platforms.
Storing everything on one machine does not scale.
And as to the "slashdot effect" -- snore.
--- End Message ---
--- Begin Message ---
# [EMAIL PROTECTED] / 2007-03-02 21:37:48 +0100:
> However... 6000 small files (and a sub if obliged) I cannot see one heck of a
> good reason NOT to hold storage in a database... Imagine the rotten backup
> cyclus.
I cannot imagine it. What was the problem?
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
--- End Message ---
--- Begin Message ---
On Saturday 03 March 2007 00:00, Roman Neuhauser wrote:
> # [EMAIL PROTECTED] / 2007-03-02 21:37:48 +0100:
> > However... 6000 small files (and a sub if obliged) I cannot see one heck
> > of a good reason NOT to hold storage in a database... Imagine the rotten
> > backup cyclus.
>
> I cannot imagine it. What was the problem?
No problem... Just ugliness... and some afterthought. The complete dataset
spread out over more than 6000 files instead of one. Using tar and bunzip2 on
the amount of files and at the same time.. also do a sqldump of all the rest
of the information... glue together and send it off to backup storage...
Just seems so .... someone put in a word.
If something happens now, I just rollback, no fuzz. Backup is scheduled once a
day and gives me all the safety needed to keep it live'n kicking.
Last time this "case" was up for discussion, I got the lecture from Richard,
whereas he gave me quite a few good pointers on the file storage subject,
witch I've implemented in my present and future project (Thanks Richard), but
see absolutely no reason to rollback over the previously mentioned project
with the images. It just doesn't fit the task at hand.
Use the tool fitted for the task and databases is _A_ tool, and a good one at
that, but even I can see many ways to missuse it, and the reason is simple;
The first thing one find if searching for many php file storage topics is
easy and even easier solutions to store images in a blob rather than the
filesystem witch actually requires some thinking.
So one should probably STRONGLY suggest otherwise if someone asks, but one
should not ban it, cuz is has its moments
--
---
Børge
Kennel Arivene
http://www.arivene.net
---
--- End Message ---
--- Begin Message ---
>> > I'm making assumptions about the layout again. The database will
>> > likely already have the table files opened, but will need a seek to
>> > get the data. The webserver will have to do an additional seek (I was
>> > assuming on a far slower drive system, and likely twice for stat and
>> > read).
>>
>> I'm not sure I trust this assessment.If it is an often used image it
>> will
>> be in OS level cache. If it is not, then you will have the I/O.
>> Regardless, it will be using SQL database cache blocks and reduce the
>> efficacy of the SQL cache.
>
> Remember, I don't use a db to store images, for a variety of reasons,
> mostly in that centralized repositories of anything don't scale.
Finally someone has something that sounds like a well constructed thought.
> However, if your hardware is far more than than you userbase will
> need, the SQL server's caching won't matter, and it will be faster.
The "good enough" fallacy again.
> Not that it matters, since it would be a more expensive setup than
> necessary.
Using hardware and resources more effectively is seldom more expensive.
> Ease of programming wise, or in the one case where we use
> it: ease of developer setups, it works better.
I've never seen it in practice. A trivial procedural rule during
development is not a big deal.
> Those are really just
> configuration issues and a syncing issues across platforms.
>
> Storing everything on one machine does not scale.
>
> And as to the "slashdot effect" -- snore.
It is a handy "short hand" for heavy access, and it is a big concern if
you have a popular site or hope to have one.
--- End Message ---
--- Begin Message ---
Hi all,
I would like to ask you if anyone of you ever did something like that or
might tell me how to do this.
I am currently switching from PHP4 to PHP5 and mySQL4 to mySQL5.
On account of this, I would like to use the improvements of ext/mysqli
instead of the old ext/mysql. So I need to do a rewrite on my database
class and as of this, I would like to add new functions such as prepared
statements, which are obviously supported by mysqli.
In fact, I would like to write a method within my class like this:
public function bindParam($str_types, &$var_variable)
{
// Code
$mysqli_stmt->bind_param($str_types, $var_variable);
}
This method is supposed to be called like this ($result is an object of
that class)
$result->bindParam("s", $username);
$username = "username";
That does work out already, but I would like to add more parameters like
this:
$result->bind_param("ssss", $username, $email, $me, $you);
As I don't want to write a method with 50 optional parameters (I needed
to add one if I were to use 51 variables), I would like to solve this
problem dynamically. In fact, I tried to recall the bind_param method of
mysqli_stmt several times, but I have to call it only once as PHP
requires me to do this. (I get an error otherwise that the number of
variables isn't fitting to the prepared statement)
So I have to pass all parameters in one call.
I also tried eval() but that didn't really work out, either.
Now, my question is: What can I do to solve this problem? Is there any
elegant way of doing this?
Thanks in advance for any inspiration (and I hope I could make myself
clear).
Yours sincerely
Christian Heinrich
--- End Message ---
--- Begin Message ---
>> > At 10:01 AM -0500 3/1/07, [email protected] wrote:
>>
>>> If you are open to honestly consider, then I shall provide a couple
>>> of examples. But if I do and you do not agree, then your only
>>> recourse will be to *prove* otherwise.
>>>
>>> So, what say you?
>>
>>Absolutely, I'm all about computer science. Give me some real world
>>examples and I'll show you the flaws.
>>
>>-snip-
>>
>>What do *you* say?
>
> Mark:
>
> Well... it's not just me, but from what I've learned and read over the
> years.
>
> Your claim is that in ALL cases using a file system to store images
> is preferable to using a database. As such, you claim that using a dB
> for storing images is "bad" practice.
That is fairly close to my professional opinion, yes. There is, of course,
always the exception to any rule, but in general, I would call storing
bitmaps in a database without a damn good reason, a bad practice, yes.
>
> My claim is that both methods have their advantages and
> disadvantages, as I said in my opening post on this thread "Both
> techniques have up-sides and down-sides -- and I use both depending
> upon needs."
I would say that the error is that you weight each approach equally, and
that one is clearly a bad practice for the various reasons I have posted.
>
> Part of the problem here is that we are using subjective terms such
> as "bad" practice and "preferable" methodologies. So a bit of
> objectivity is in order. Such terms can be viewed from different
> perspectives, such as time taken, cost in equipment, ease of use, and
> many other such concerns.
One can not view the act of using a wrench as a hammer as anything but a
bad practice. I'm sure at one time or another, we have all used a wrench
as a hammer, but that in no way justifies an opinion that using a wrench
as a hammer is appropriate. It may be necessary or convenient at some
point in time, but not something one designs as a solution.
>
> However, I realize that what's "preferable" and "bad" practice for
> you may differ for me and therein provides an opportunity for you to
> pass on *proving* that none of the following fits within in your
> considerations and restrictions. But, that's Okay -- you can keep
> your opinion. I am only offering what I believe to be relevant
> because you said you would honestly consider it.
Hiding behind "opinion" is too easy. There are things that are better than
others. Quality sucks in the software world largely because proper use of
technologies is not understood.
>
> The following are the things I consider important for this discussion:
>
> Consideration 1
>
> Storing images in a database bloats the database and you're more
> likely to approach memory limits of your operating system. However,
> storing images the file system, likewise may cause lookups to become
> slower on some operating systems than using a dB (Granted this is a
> weak consideration, but I read it, so it must be true.) :-)
this is far too weak and unspecific to really address. "Bloat" is a
subjective title. And "lookups to become slower" either encompasses
failures of specific file systems or approach.
>
> Consideration 2
>
> If your project is to supply images across several web servers on
> different host, then you are caught in a sync problem. Images stored
> in a file system must be stored on a local host. In a multiple host
> situation you must have a duplicate set of images on each host.
> Synchronizing images across different files systems on different host
> is far more complicated and problematic than maintaining a single
> database from which all host can draw the most current images.
This is a complete fallacy. It fails on a few assumptions.
(1) If you assume that you have one database supply all the images to all
your servers, then you merely need to expose an "images.domain.com" URL
that contains all your images. That will be faster and more efficient than
a single database.
(2) Again, assuming one machine supply all data, a back-end apache server
serving images from one machine through a validated PHP pass through is
still more efficient than a database.
(3) Assuming that you want to distribute database images, there are many
tools to accomplish this, not the least of which is rsync.
>
> Consideration 3
>
> Storing images images in a file system and their location in a
> database is a two step process in all image operations. If your
> project requires a transactions, then it's obviously more difficult
> to accomplish for not only do you have to do two operations, but they
> must take place in two domains. Whereas, if you store images in a
> database it is a simple matter to add, alter, and delete because it's
> one operation and thus no need to confirm that the file system and
> database remain in sync.
This is a purely hypothetical and easily solved problem, if you can even
create a scenario that would cause it.
First of all, assuming a requirement of ACID transactions, one create the
bitmap file name using something like a UID, save the bitmap to the disk
using fsync() to ensure it is committed to disk, then update the database
record.
I'd like to point out that you are focusing on one aspect of a whole
solution. Yes, this one aspect may take two steps in your code, but at
best, it is unclear that it is any less efficient when compared to what
happens at the database level, and we already know retrieving the bitmap
is more efficient.
>
> Consideration 4
>
> Even without transactions, it's simpler to have all data in a single
> dB than it is two divide the data into two sets and then maintain a
> sync.
Simpler for who? It may take a little NRE do it right, but once it is done
it is done.
>
> Consideration 5
>
> Backups. It is far easier, faster, more reliable, and less prone to
> error to perform a single mysql dump of all images than it is to
> preform a mysql dump of all image locations AND duplicate all image
> files. I even had a client who demanded that his image files be
> localized in such a manner. That's a real world example, where's the
> flaw in providing what the customer wants?
The customer is usually wrong when it comes to technology. They may know,
conceptually, what they want, it is your job to give them what they really
need.
To address the "easier" and "faster" issue, I'm not sure I can fully
agree. Like before, "easy" is a little NRE away. "Faster" is debatable as
the real issue is size of data and data transport. Also, if you are
backing up and using MySQL with MyISAM you will be readlocking the table
while reading data out of it and hurt performance of your database.
>
> Consideration 6
>
> While this should be avoided through good coding practice, but if you
> screw-up a path, things can get chaotic real fast. Hard coding
> partial paths in your code and pulling the rest of the path out of
> the dB is prone to more error than just accessing the image directly
> from the database. Granted, coders should be aware that "all of the
> path" should be taken from the dB and not hard code any path
> information, but that practice isn't always followed. Unfortunately,
> we don't always work with just "our" code and preferences.
I can't accept "stupid programmers" as a reason. Stupid programmers can
break anything.
>
> Consideration 7
>
> The future -- while programming styles and types differ, the trend is
> toward encapsulating (i.e., keeping all data, methods and functions
> together within an organization and hidden). From OOP to unobtrusive
> code, clearly this is the direction of today.
This is too simplistic a view and you are grasping for straws and your
know it.
>
> My personal preference is to keep all my relative data together as
> well. If my data, along with other attributes, incorporates images
> then, I like the idea (but, don't always practice it myself) of
> having everything in one place and storing images along with other
> associated data in a database makes sense to me. To me, images are
> nothing more than large hunks of data. Why tell fat people to sit
> somewhere else?
That is a pretty simplistic view of data. There are classes of data that
are different than others.
It is funny, but most people don't get the fact that SQL databases are not
the best way to store data. They are designed to select algebraic
relationships from a data set. They are designed to ensure accuracy of the
relationships and the integrity of the data.
When you have data that does not need to be associated, queried, or hard
linked to the relationships, the it doesn't make any real sense to use a
SQL database.
>
> I certainly can understand and realize that images, because of their
> size (and size alone), can be problematic with respect to time and
> memory, however, both of those physical restraints are becoming less
> of a limiting factor everyday.
Ahh, th "computer are getting faster" fallacy, people have been using that
for over 25 years and it still isn't true.
>
> Sure, programmers like to reduce the amount of memory their code
> occupies, and reduce the amount of time it takes for their code to
> execute, but in the final accounting, those considerations are
> becoming less and less important each day.
That simply isn't true. Every time you see a web site "slashdotted,"
remember the nonsense you are saying.
>
> For example, the threshold definition for a super-computer twenty
> years ago has been surpassed by todays' common laptops. Likewise,
> memory that cost $1k twenty years ago cost less than $0.01 today.
> Surely, these trends toward faster and cheaper computing will
> continue. To anticipate how these changes will affect programming is
> certainly worth consideration today.
Assuming requirements don't grow in unison.
>
> It is without doubt, in my mind, that the ease that dB's offer in
> localizing data will prevail over distributive methodologies which
> are primarily based upon time and money concerns -- for time and
> money are lessening concerns.
Again, next time you see a site "slashdotted" remember this. That sort of
stuff happens exactly for the reasons you are promoting.
>
> We use dB's far more today than we ever have before and there are
> many reason for this. In my opinion, they are easier, localized,
> provide more function, becoming cheaper, and will probably prevail
> over all data storage methodologies regardless of out-dated legacy
> perspectives or misconceptions about the inherit problems that
> accompany different data types.
There is no doubt that the trend of database vs file systems is
converging, each are getting features of the other, they are not there
yet.
>
> In short, things change -- while the legacy lives on, we don't have
> to use I, J, K, and L as counters as we did in FORTRAN.
It may surprise you to know that there were other languages that could do
more at the same time as FORTRAN's hayday.
>
> Now, if you want to continue this debate, all you have to do is to
> *prove* each of the above examples as being "wrong" to support your
> claim. :-)
>
> So, what say you?
Done.
--- End Message ---
--- Begin Message ---
It is funny, but most people don't get the fact that SQL databases are not
the best way to store data. They are designed to select algebraic
relationships from a data set. They are designed to ensure accuracy of the
relationships and the integrity of the data.
Like blobs in separate files, this is a very old perspective. Not to
say incorrect, but they have evolved into more analytical information
storage servers in the last 15 years. Hmm that sounded like marketing
speak. !! I better get back to work... bye all!
--- End Message ---
--- Begin Message ---
>> It is funny, but most people don't get the fact that SQL databases are
>> not
>> the best way to store data. They are designed to select algebraic
>> relationships from a data set. They are designed to ensure accuracy of
>> the
>> relationships and the integrity of the data.
>
> Like blobs in separate files, this is a very old perspective.
Not as old as you may think.
Most databases use fixed block sizes. This, obviously, allows an efficient
buffer caching system. Be it MySQL, PostgreSQL, SQLite3, etc. BLOBS don't
fit into the blocks well. So, some method must be used to store this data
in a way that does not mess up the nice buffering system.
PostgreSQL uses TOAST, which is kind of cool. It stores large data in a
separate table file. Even allows compression.
MySQL MyISAM, if I recall correctly, stores the binary data in a separate
unique block for blobs.
Oracle still allows you to store BLOBs outside of the tablespace.
> Not to
> say incorrect, but they have evolved into more analytical information
> storage servers in the last 15 years.
People who think the past have no importance in the present are mistaken.
My information was not "old" but your interpretation was "ignorant."
--- End Message ---
--- Begin Message ---
On Fri, 2007-03-02 at 17:31 -0500, [email protected] wrote:
> > Your claim is that in ALL cases using a file system to store images
> > is preferable to using a database. As such, you claim that using a dB
> > for storing images is "bad" practice.
>
> That is fairly close to my professional opinion, yes. There is, of course,
> always the exception to any rule, but in general, I would call storing
> bitmaps in a database without a damn good reason, a bad practice, yes.
Ah, you've changed your tune. Thanks for coming out.
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. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
> On Fri, 2007-03-02 at 17:31 -0500, [email protected] wrote:
>> > Your claim is that in ALL cases using a file system to store images
>> > is preferable to using a database. As such, you claim that using a dB
>> > for storing images is "bad" practice.
>>
>> That is fairly close to my professional opinion, yes. There is, of
>> course,
>> always the exception to any rule, but in general, I would call storing
>> bitmaps in a database without a damn good reason, a bad practice, yes.
>
> Ah, you've changed your tune. Thanks for coming out.
I haven't changed any tune what so ever.
--- End Message ---
--- Begin Message ---
On Fri, 2007-03-02 at 22:53 -0500, [email protected] wrote:
> > On Fri, 2007-03-02 at 17:31 -0500, [email protected] wrote:
> >> > Your claim is that in ALL cases using a file system to store images
> >> > is preferable to using a database. As such, you claim that using a dB
> >> > for storing images is "bad" practice.
> >>
> >> That is fairly close to my professional opinion, yes. There is, of
> >> course,
> >> always the exception to any rule, but in general, I would call storing
> >> bitmaps in a database without a damn good reason, a bad practice, yes.
> >
> > Ah, you've changed your tune. Thanks for coming out.
>
> I haven't changed any tune what so ever.
Uhm, ooooookaaaaaay dooookaaaaaaaay then. I guess it's a good thing that
the archives tell the real story... not to mention the readers of the
list don't exactly have short memories.
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. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
Hello,
In some questions, you can use combobox for easiest data analysis such
as countries . except this, it's very good survey:)
--
Haydar TUNA
Republic Of Turkey - Ministry of National Education
Education Technology Department Ankara / TURKEY
Web: http://www.haydartuna.net
<[EMAIL PROTECTED]>, haber iletisinde sunlari
yazdi:[EMAIL PROTECTED]
> Hello
>
> My name is Lara Thynne and I am a PhD candidate at Deakin University
> Australia.
>
> I am currently running a survey at the following address.
>
> https://dcarf.deakin.edu.au/surveys/oss/
>
> The survey is completely confidential and looks at your views and
> motivations to use Open Source software and to participate in the
> community.
>
> It will only take a few minutes and your contact details will not be
> recorded. You can withdraw your participation at any stage.
>
> I sincerely apologize for the spammish nature of this e-mail - I
> don't mean to abuse this list. I am trying to collect responses
> from as many open source developers and users as possible and a
> mailing list like this is probably the best way to reach many of you.
>
> Please personally CC me with any questions/comments posted to the
> list in response.
>
> Thanks again
>
> Lara
>
> P.S The program that I am using is open source, of course
> (www.phpsurveyor.org)!
--- End Message ---
--- Begin Message ---
This one time, at band camp, "Marco Sottana" <[EMAIL PROTECTED]> wrote:
> which is the best framework ? pear or zend framework?
None of the above...
--
"Democracy is two wolves and a lamb voting on what to have for lunch.
Liberty is a well-armed lamb contesting the vote."
--- End Message ---
--- Begin Message ---
On Friday 02 March 2007 21:59, Roberto Mansfield wrote:
> The problem is that your function generates thumbnail and then tries to
> return the binary image within the html document. Html contains *links*
> to images, not the images themselves. So you need to do something like
> this:
>
> <img src="create_thumbnail.php?filename=<? echo $photo_img_name; ?>">
>
> Then you create_thumbnail.php can return the binary image:
>
> <?
>
> // be sure to validate the user supplied parameter!
> $photo_img_name = $_REQUEST['filename'];
>
>
> $percent = 0.5;
> list($width, $height) = getimagesize($photo_img_name);
> $newwidth = $width * $percent;
> $newheight = $height * $percent;
> $thumb = imagecreatetruecolor($newwidth, $newheight);
> $source = imagecreatefrompng($photo_img_name);
> imagecopyresized($thumb, $source, 0, 0, 0, 0, $newwidth, $newheight,
> $width,
> $height);
>
> // or whatever the correct mime/type is
> header("Content-type: image/png");
>
> echo imagepng($thumb);
> }
I assumed there are no problems with the html part of things as the original
image was being display perfectly. Guess thats where the difference between
newbies and old hands is evident.
I have added the suggested validation. Many thanks for all the help.
regards
Punit Neb
--- End Message ---
--- Begin Message ---
hi there, I've got a dual xeon x86_64 and I got centos-4.4 installed on
it (it's actually a XenU machine). Centos-4.4 comes with php-4.3 but for
some reason I have to install php-4.4. Now my problem is that I can't
get the thing compiled. I tried with this package:
http://3es.atomicrocketturtle.com/packages/php/php-4.4.4-1.art.src.rpm
which compiles and works perfectly on i386 but it fails to compile on
x86_64. Unfortunately it's no longer supported by art.
So I played around a little bit with that src.rpm i.e. I built
lib64-patches because during configure phase there were lots of 'not
found messages'. I made the beast find my lib64 stuff i.e. I modified
all the config.m4 files in the ext subdirs, I even changed libtool from
1.5 to 1.4 (which seems to be a requirement), but after all, I couldn't
compile it as more and more errors arose.
Then I tried plain php i.e. the tar.gz, but even that didn't lead me to
a successfully built binary, there were these lib64 issues, so even the
plain tar.gz showed up that it still has to be patched.
Any suggestions, how can I get php compiled on the x86_64 architecture?
Is there any comprehensive guide on how to set up a build environment
for php(-4.4)?
Has anybody successfully built an rpm for php-4.4 for centos-4?
Of course, an rpm would be my preference in order to keep the system
capable of being updated easily.
TIA
Regards,
Michael
--
Michael Kress, [EMAIL PROTECTED]
http://www.michael-kress.de / http://kress.net
P E N G U I N S A R E C O O L
--- End Message ---
--- Begin Message ---
Hello,
You can developed private web site template for your clients. This
template can be personal page, company page and so on. if you try this, you
can deal with only graphic design. Your development time for the web site
will decrease. :)
--
Haydar TUNA
Republic Of Turkey - Ministry of National Education
Education Technology Department Ankara / TURKEY
Web: http://www.haydartuna.net
""John"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> This may be deviating a bit from the intent of the list, and someone feel
> free to say so if the list shouldn't be used for this. My apologies in
> advance if that is the case. This is NOT a self-advertisement!
>
>
>
> My question is regarding the "going rate" for software development
> consulting -
>
>
>
> Currently, my clients are mostly companies requesting graphic design and
> web
> development for websites, and my rate is 65-85 an hour, quoted per
> project.
>
>
>
> I have a large prospective client who is looking for a consultant for
> development and support for ongoing software projects, and I'm wondering
> how
> differently a client of this size/nature would be handled. They'd be
> looking
> at around 100-150 hours a month on a continual basis.
>
>
>
> I recognize it is a bit different than my other clients who are usually
> single projects that are opened and closed fairly quickly, but would 65-85
> an hour be reasonable and fair? I know there are a lot of variables that
> would affect it, but generally, what would be a "competitive" rate?
>
>
>
> Feel free to respond to me privately rather than to the list.
>
>
>
> I appreciate any suggestions and insight that anyone may offer!
>
>
>
> Thanks
>
>
>
> J
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
--- End Message ---
