php-general Digest 1 Mar 2013 23:28:45 -0000 Issue 8143
Topics (messages 320333 through 320342):
Re: webDAV/CalDAV client class experience ?
320333 by: Adam Tauno Williams
320334 by: Adam Tauno Williams
Re: Holding "datetimes" in a DB.
320335 by: Simon Schick
320336 by: Lester Caine
320339 by: Matijn Woudt
Introduction ... !
320337 by: Nick Whiting
320338 by: Daniel Brown
320340 by: Jim Giner
320341 by: Daniel Brown
Re: Close enough to Friday...
320342 by: tamouse mailing lists
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Sun, 2013-02-17 at 21:26 -0600, tamouse mailing lists wrote:
> On Sat, Feb 16, 2013 at 2:30 PM, B. Aerts <ba_ae...@yahoo.com> wrote:
> > - the biggest mistake: apparently I commented the fwrite() call to the
> > stream, which explains why he went in time-out ... (in this case, please DO
> > shoot the pianist)
> Nah, just don't leave a tip. :)
> > - Adding the HTTP header "Accept: */*" made sure all read actions ( e.g.
> > GET, PROPFIND, REPORT) worked perfectly
Interesting, suprising, but it makes sense. An Accept header is
required; although most things actually ignore it.
> This is interesting. The Accept header has to do with what media types
> the browser will accept in return. I didn't think it had anything to
> do with what operations the server/application accepts. Must go read
> further....
> > Only problem remaining was that PUT still isn't possible - at least not with
> > one of the providers. Since I used a verbatim copy of a PUT action from the
> > RFC, I strongly suspect the problem to be with the provider.
>
> You've no doubt considered this already, but it might be intentional
> on the provider's part. I'm not up on all the webDAV/calDAV providers;
> I imagine some of them might add in additional layers of auth
> (including the NOWAI layer) just to consider themselves more secure.
I have WebDAV/CardDAV/CalDAV experience - what actually happens when you
do a PUT operation? Do you get any response at all? Is your
content-type header correct? Is your payload actually correct?
--- End Message ---
--- Begin Message ---
On Mon, 2013-02-18 at 12:19 +0100, B. Aerts wrote:
> >> - Adding the HTTP header "Accept: */*" made sure all read actions ( e.g.
> >> GET, PROPFIND, REPORT) worked perfectly
> >
> > This is interesting. The Accept header has to do with what media types
> > the browser will accept in return. I didn't think it had anything to
> > do with what operations the server/application accepts. Must go read
> > further....
>
> I'll have to revoke this statement, as I can't reproduce it anymore.
> I noticed the DaviCal didn't use it, bu the CURL call did - and yielded
> more ( = meaningfull) results.
> But, as I said, can't reproduce it.
>
> The thing I could reproduce was that, if the request was sent to the
> default port, AND this port was included in the "Host" header, both GET
> and PUT yielded HTTP 404.
>
> >
> >> Only problem remaining was that PUT still isn't possible - at least not
> >> with
> >> one of the providers. Since I used a verbatim copy of a PUT action from the
> >> RFC, I strongly suspect the problem to be with the provider.
> >
> > You've no doubt considered this already, but it might be intentional
> > on the provider's part. I'm not up on all the webDAV/calDAV providers;
> > I imagine some of them might add in additional layers of auth
> > (including the NOWAI layer) just to consider themselves more secure.
> >
> Yes I did, but the following arguments should negate that consideration:
> - when running OPTIONS, PUT is included in the allowed HTTP methods
> - the HTTP return code from the PUT command is 301, where a security
> issue would have yielded a code in the 400 range
Ok, and the 301 response contains a Location: header? A 301 as a
response to PUT just means the server relocated/renamed the resource.
> - the other provider does respond as expected (though I agree, that is
> the weakest argument: expectations != specifications )
Nobody, nowhere, matches the spec.
> - the provider does allow sync'ing Sunbird, iCal, ... over CalDAV, and
> that works, even entering a new event (which is a PUT action). The
> Charles debugging proxy too shows that it's only Basic authentication
> that's going up - and succeeding
If your response is 301 why do you believe it is failing?
> $body = <<<XML
> <?xml version="1.0" encoding="utf-8" ?>
> <C:calendar-query xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
> <D:prop>
> <C:calendar-data/>
> <D:getetag/>
> </D:prop>
> <C:filter>
> <C:comp-filter name="VCALENDAR">
> <C:comp-filter name="VEVENT">
> <C:time-range start="20130201T000001Z" end="20130228T000001Z"/>
> </C:comp-filter>
> </C:comp-filter>
> </C:filter>
> </C:calendar-query>
Does PHP provide some kind of XML building library? String building XML
is *always* dicey and it is *VERY* easy to introduce encoding problems.
Something at least with an codepage codec would be good. [although it
*should* work, I manipulate WebDAV servers via curl CLI all the time].
In Python a combination of ElementFlow and the codecs module is
perfection. I assume there is a PHP equivalent.
--
Adam Tauno Williams <awill...@whitemice.org>
--- End Message ---
--- Begin Message ---
Hi, Richard
I, too, tought about switching to UTC times in my database. The only reason
for me was to get prepared for globalisation.
A good article about this consideration is written at PHP Gangsta (sorry,
German only):
http://www.phpgangsta.de/die-lieben-zeitzonen
The reason, why I did not switch to UTC, was the reason, that most of the
pages I host have visitors mostly from Germany.
If you have visitors from different countries, you first have to find out
which time-zone they're in, which can be quite messy. Just watch this video
about timezones (I added a jump-node that get's you directly to the
interesting stuff):
http://www.youtube.com/watch?feature=player_detailpage&v=84aWtseb2-4#t=230s
But basically that doesn't matter that much, since you - anyways - don't
get a time from the client, so you're stuck in this problem either way ...
Each example, I can come up with, does apply to UTC saved timestamps as
well as to non-UTC based timestamps.
One consideration, if you only have to operate in one timezone, like I do,
is stuff like cron-jobs.
Since I only have Germany as main-visitor-source, I can safely configure
the server to Europe/Berlin and pull out stuff like birthday-information at
midnight.
Please do also keep in mind here, that there are not only
full-hour-timezones :)
http://en.wikipedia.org/wiki/List_of_UTC_time_offsets
But .... I can't come up with a problem that you wouldn't have with a local
timezone instead of UTC ...
Bye
Simon
On Fri, Mar 1, 2013 at 11:49 AM, Richard Quadling <rquadl...@gmail.com>wrote:
> Hi.
>
> My heads trying to remember something I may or may not have known to start
> with.
>
> If I hold datetimes in a DB in UTC and can represent a date to a user
> based upon a user preference Timezone (not an offset, but a real
> timezone : Europe/Berlin, etc.) am I missing anything?
>
> Richard.
> --
> Richard Quadling
> Twitter : @RQuadling
> EE : http://e-e.com/M_248814.html
> Zend : http://bit.ly/9O8vFY
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Richard Quadling wrote:
My heads trying to remember something I may or may not have known to start with.
If I hold datetimes in a DB in UTC and can represent a date to a user
based upon a user preference Timezone (not an offset, but a real
timezone : Europe/Berlin, etc.) am I missing anything?
The simple answer is ... No
Slightly more complex ...
If you are displaying timed events in the future and need to support multiple
time zones, then using the browser TZ setting is useless, you need to work with
a daylight saving setting instead. The site 'default' can either be UTC or it
can be a particular timezone, but what will not work reliably is to offset from
the browser information.
If all of your users are in the same timezone, then UTC without setting a
timezone makes perfect sense and you even ignore even the daylight saving
changes. Where the fun comes is where you are displaying times which straddle
the daylight saving switches such as a train movement where the time you need to
display jumps. In this case you have to use UTC for the movement, and display
with the correct daylight saving offest.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--- End Message ---
--- Begin Message ---
On Fri, Mar 1, 2013 at 11:49 AM, Richard Quadling <rquadl...@gmail.com>wrote:
> Hi.
>
> My heads trying to remember something I may or may not have known to start
> with.
>
> If I hold datetimes in a DB in UTC and can represent a date to a user
> based upon a user preference Timezone (not an offset, but a real
> timezone : Europe/Berlin, etc.) am I missing anything?
>
> Richard.
>
I would only use this if you're planning to have servers all around the
world in different timezones, then it would be easier to interchange data.
Otherwise, stick with ur local timezone and it will save you a lot of
unneeded timezone conversions probably.
- Matijn
--- End Message ---
--- Begin Message ---
Hello PHP'ers!
Just thought I would introduce myself to the mailing list since I've worked
with PHP for almost 10 years now and yet haven't really been community
active ...
I've developed quite a few open-source projects over the years that I hope
someone here will find as useful as I have ... they are all hosted on
Github @prggmr.
XPSPL - Signal Processor in PHP
docpx - PHP Documentation Generator for Sphinx
Again Hello Everyone!
Cheers!
--
Nickolas Whiting - prggmr.org
- Remember to write less code that does more faster -
--- End Message ---
--- Begin Message ---
On Fri, Mar 1, 2013 at 10:57 AM, Nick Whiting <prg...@gmail.com> wrote:
> Hello PHP'ers!
>
> Just thought I would introduce myself to the mailing list since I've worked
> with PHP for almost 10 years now and yet haven't really been community
> active ...
>
> I've developed quite a few open-source projects over the years that I hope
> someone here will find as useful as I have ... they are all hosted on
> Github @prggmr.
>
> XPSPL - Signal Processor in PHP
> docpx - PHP Documentation Generator for Sphinx
>
> Again Hello Everyone!
Welcome to the list, Nick. Looking forward to having you involved
in the discussions we have go on here. The list isn't nearly as
active as it was about five years ago, but that's likely to change.
--
</Daniel P. Brown>
Network Infrastructure Manager
http://www.php.net/
--- End Message ---
--- Begin Message ---
On 3/1/2013 12:43 PM, Daniel Brown wrote:
On Fri, Mar 1, 2013 at 10:57 AM, Nick Whiting <prg...@gmail.com> wrote:
Hello PHP'ers!
Just thought I would introduce myself to the mailing list since I've worked
with PHP for almost 10 years now and yet haven't really been community
active ...
I've developed quite a few open-source projects over the years that I hope
someone here will find as useful as I have ... they are all hosted on
Github @prggmr.
XPSPL - Signal Processor in PHP
docpx - PHP Documentation Generator for Sphinx
Again Hello Everyone!
Welcome to the list, Nick. Looking forward to having you involved
in the discussions we have go on here. The list isn't nearly as
active as it was about five years ago, but that's likely to change.
What gives you such optimism? I recently saw a list of languages in use
and PHP has dropped quite a bit over the last 5 or more years.
Being a relative newbie myself, I'm happy that PHP exists and is so
readily available to us hobbyists, etc. Certainly am in favor of your
optimism, but curious (hey it's Friday!) about your prediction.
--- End Message ---
--- Begin Message ---
On Fri, Mar 1, 2013 at 12:54 PM, Jim Giner <jim.gi...@albanyhandball.com> wrote:
>
> What gives you such optimism? I recently saw a list of languages in use and
> PHP has dropped quite a bit over the last 5 or more years.
> Being a relative newbie myself, I'm happy that PHP exists and is so readily
> available to us hobbyists, etc. Certainly am in favor of your optimism, but
> curious (hey it's Friday!) about your prediction.
Just knowing how the patterns go. It's always the same, and it
will likely be the same again. No guarantees, but all it takes is a
bit of fostering of the community to return it to a decently-vibrant
forum.
--
</Daniel P. Brown>
Network Infrastructure Manager
http://www.php.net/
--- End Message ---
--- Begin Message ---
On Thu, Feb 28, 2013 at 9:59 PM, Adam Richardson <simples...@gmail.com> wrote:
> On Thu, Feb 28, 2013 at 10:19 PM, tamouse mailing lists
> <tamouse.li...@gmail.com> wrote:
>>
>> Congratulations on ditching the Dreamweaver Templates!
>>
>> Now, as to preprocessing: how does this benchmark out? Have you
>> noticed a significant different in processing time, memory usage, disk
>> usage, etc?
>
> Well, it depends...
>
> For example, if you use code similar to the inlined function example,
> there is a difference. In that example, the inlined code runs almost
> twice as fast.
>
> <?php
> $a = 1;
> $b = 2;
> $start = microtime();
>
> for ($i = 0; $i < 10000; $i++) {
> $result = ($a > $b && $a % 2 !== 0) ? $a : (($b % 2 !== 0) ? $b : (($a
> % 2 !== 0) ? $a : null));
> }
>
> $runtime = microtime() - $start;
> echo $runtime;
>
> ?>
>
> <?php
>
> function maxodd($a, $b)
> {
> return ($a > $b && $a % 2 !== 0) ? $a : (($b % 2 !== 0) ? $b : (($a %
> 2 !== 0) ? $a : null));
> }
>
> $a = 1;
> $b = 2;
> $start = microtime();
>
> for ($i = 0; $i < 10000; $i++) {
> $result = maxodd($a, $b);
> }
>
> $runtime = microtime() - $start;
> echo $runtime;
>
> ?>
>
> That said, there's tremendous variance across the possible range of
> function types (e.g., number of args, complexity of function, etc.),
> so there's no guarantee you'll always see a worthwhile (which is also
> subjective) improvement. I'm going to use inlining for functions that
> output html-escaped output (the function wraps htmlspecialchars to
> allow whitelisting), as they're frequent and simple, the very type of
> function that is easily inlined and provides some speed benefit.
>
> In terms of the templating, in my tests using siege comparing
> Dreamweaver Templates vs PHP includes, I've typically seen significant
> benefits when the template requires multiple includes, with the effect
> dropping off as the number of includes approaches 0. These results
> should be the same. Again, there seems to be a broad range of
> considerations (in terms of using APC, using absolute paths helped the
> include performance:
> http://www.php.net/manual/en/apc.configuration.php#ini.apc.stat)
>
> There are usually bigger ways to enhance performance (data
> persistence, etc.), but in the same way that I try to teach my little
> girls to turn off the faucet in between spitting into the sink even
> though monitoring showers can do much more to save water, when I see
> simple ways I can consistently save cycles, I try to implement them :)
>
> Adam
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Awesome. Not unsuspected, but still awesome. I know some site schemes
that do a lot of nested templating; and from my work on rails,
rendering a site with tons of partials (the same sort of thing) can
really slow page loads down. I know Smarty caches the compiled
templates automatically, and refreshes if a given template changes
from the cached version, and this does speed things up somewhat, but
it doesn't actually do the full up staticify (if i may be so bold!)
like this.
--- End Message ---
