phpicalendar-devel — Mailing list for PHP iCalendar Developers

[PHPiCalendar-DEV] Repeating event weekly byday

[Jim Hu <ji...@ta...>]

Anyone get a chance to look at this yet?

Jim

> Message: 1
> To: php...@li...
> From: Jim Hu <ji...@ta...>
> Date: Sat, 3 Dec 2005 01:16:16 -0600
> Subject: [PHPiCalendar-DEV] Another repeat issue - what's this for?
> Reply-To: php...@li...
>
> This is in the case 'WEEKLY' part of ical_parser.php.
>
> // Since this renders events from $next_range_time to
> $next_range_time + 1 week, I need to handle intervals
> // as well. This checks to see if $next_date_time is after $day_start
> (i.e., "next week"), and thus
> // if we need to add $interval weeks to $next_date_time.
> if ($next_date_time > strtotime($week_start_day, $next_range_time) &&
> $interval > 1) {
>   	$next_date_time = strtotime('+'.($interval - 1).' '.$freq_type,
> $next_date_time);
> }
>
> This appears to be the cause of a bug reported on the bbs, where
> events that repeat every 2 weeks gain a week in successive months.
> Commenting it out seems to fix that bug, and my test calendar works
> with repeats of 1, 2, 3, 4, and 5 weeks.  But presumably the code was
> put in the parser for a reason.  Or is it now redundant with
> something else? $next_range_time must be bumped by $interval  
> elsewhere.
>
> This has NOT been added to CVS, but the patch is noted on the bbs.
> =====================================
> Jim Hu


=====================================
Jim Hu
Associate Professor and Associate Head for Graduate Programs
Dept. of Biochemistry and Biophysics
2128 TAMU
Texas A&M Univ.
College Station, TX 77843-2128
979-862-4054

[PHPiCalendar-DEV] Another repeat issue - what's this for?

[Jim Hu <ji...@ta...>]

This is in the case 'WEEKLY' part of ical_parser.php.

// Since this renders events from $next_range_time to  
$next_range_time + 1 week, I need to handle intervals
// as well. This checks to see if $next_date_time is after $day_start  
(i.e., "next week"), and thus
// if we need to add $interval weeks to $next_date_time.
if ($next_date_time > strtotime($week_start_day, $next_range_time) &&  
$interval > 1) {
  	$next_date_time = strtotime('+'.($interval - 1).' '.$freq_type,  
$next_date_time);
}

This appears to be the cause of a bug reported on the bbs, where  
events that repeat every 2 weeks gain a week in successive months.   
Commenting it out seems to fix that bug, and my test calendar works  
with repeats of 1, 2, 3, 4, and 5 weeks.  But presumably the code was  
put in the parser for a reason.  Or is it now redundant with  
something else? $next_range_time must be bumped by $interval elsewhere.

This has NOT been added to CVS, but the patch is noted on the bbs.
=====================================
Jim Hu

[PHPiCalendar-DEV] Last weekday of month bug

[Jim Hu <ji...@ta...>]

 From the bbs:

http://phpicalendar.net/forums/viewtopic.php?p=1395#1395

Dates specified as repeating on the last Wed of the month don't  
calculate properly.  They disappear when a short month follows a long  
month.

 From what I can figure out, it turns out that this is because of the  
way we calculate $next_range_time for that kind of event.   
ical_parser.php calls date(t) to get the last day of the current  
month and uses that to calculate where the days are in the last  
week.  It then passes the last day of the month on as  
$next_range_time and when the loop increments by $interval (a month  
in this case), you wind up jumping from Jan 31 to Feb 31, which gets  
converted to March 3 (unless it's a leap year).  The byday subroutine  
then correctly grabs just the month and calculates the last wednesday  
in March correctly, having skipped February altogether.

I believe that the solution is to just reset $next_range_time to the  
start of the current month inside the code that deals with byday events.

      #reset next_range_time to start of month
      $next_range_time = strtotime(date('Y-m-'.'1', $next_range_time));

This works in my test install and I put it in CVS.  However, I'm not  
sure if it's in the right place in terms of the nesting of the loop.   
Could this bug show up for other kinds of byday events?

Also, this is in the code

case 'MONTHLY':
      if (empty($bymonth)) $bymonth = array(1,2,3,4,5,6,7,8,9,10,11,12);
           $next_range_time = strtotime(date('Y-m-01',  
$next_range_time));
           $next_date_time = $next_date_time;

The last two lines in that block don't do anything...they set vars to  
their current values, don't they?  The last line has to be useless.   
Does the other one set $next_range_time if it starts out undef?  Or  
is it just vestigial?


=====================================
Jim Hu
Associate Professor and Associate Head for Graduate Programs
Dept. of Biochemistry and Biophysics
2128 TAMU
Texas A&M Univ.
College Station, TX 77843-2128
979-862-4054

[PHPiCalendar-DEV] Fixed the typo and another bug

[Jim Hu <ji...@ta...>]

OK, fixed the missing minus sign in the CVS.  Also fixed another dumb  
mistake...default calendar path should be set BEFORE cpath gets added  
to it.

Jim

Re: [PHPiCalendar-DEV] I'm really messed up on the calendar name stuff

[Nicolas C. <nic...@gm...>]

Hi Jim,

On 12/1/05, Jim Hu <ji...@ta...> wrote:
>
> Help!!!
> Now I'm really not sure what is happening, I thought I had put the
> CVS back into its previous working state...but on my install, which I
> just resynched to CVS, the calendar names are truncating all over the
> place.  I suspect that I'm not flushing my parsed cal files often
> enough when I debug.  Was I right about getCalendarname() the first
> time?
>
> I now think I was right before, and it should return basename
> ($cal_path,".ics")
>
> But I'm not uploading anything else until I'm sure that it works.
> Could someone else please take a look and let me know what they think
> is right.
>
> Yecchh.  Sorry.
>
> Jim
>
> p.s.  I'm still only getting the digests, so please cc me directly if
> you know which way it should be.
>

According to cvsweb, about
phpicalendar/phpicalendar/functions/calendar_functions.php
(On line 196) :

v 1.16 : return substr(basename($cal_path), 0, -4);
v 1.17 : return basename($cal_path,".ics");
v 1.18 : return substr(basename($cal_path), 0, 4);

I think it's just that when you turn back the code, you missed the minus
sign.
Hope it helps!


Nicolas,
--
I'm a poor and lonesome Yaourt... (Air connu)

[PHPiCalendar-DEV] I'm really messed up on the calendar name stuff

[Jim Hu <ji...@ta...>]

Help!!!
Now I'm really not sure what is happening, I thought I had put the  
CVS back into its previous working state...but on my install, which I  
just resynched to CVS, the calendar names are truncating all over the  
place.  I suspect that I'm not flushing my parsed cal files often  
enough when I debug.  Was I right about getCalendarname() the first  
time?

I now think I was right before, and it should return basename 
($cal_path,".ics")

But I'm not uploading anything else until I'm sure that it works.   
Could someone else please take a look and let me know what they think  
is right.

Yecchh.  Sorry.

Jim

p.s.  I'm still only getting the digests, so please cc me directly if  
you know which way it should be.
=====================================
Jim Hu
Associate Professor and Associate Head for Graduate Programs
Dept. of Biochemistry and Biophysics
2128 TAMU
Texas A&M Univ.
College Station, TX 77843-2128
979-862-4054

[PHPiCalendar-DEV] Re: [ phpicalendar-Feature Requests-1109495 ] Print View does not show Location

[Nicolas C. <nic...@gm...>]

On 12/1/05, SourceForge.net <no...@so...> wrote:
>
> Checked in code provided by Nicolas Contamin to address this. (Never saw =
any
> patch files from danone_lyon. Apologies.)

Sorry for the misunderstanding. i've changed my mail account to this
ML, as i'm not yet using a local mailer, on my computers.

My realname is Nicolas CONTAMIN, but everybody call me "Danon'." (like
the yoghourt... ;) ) and, as I'm currently living in Lyon, France,
I've created my sourceforge account as 'danone_lyon', but hasn't
populated it, yet.


Danon'. / Nicolas.
--
I'm a poor and lonesome Yaourt... (Air connu)

Re: [PHPiCalendar-DEV] ready for 2.2?

[Wesley M. <we...@we...>]

I've committed Nicolas' two patches for the week view and print view. =20=

Thanks a bunch, Nicolas. I'm not sure what to do about the french =20
diff file though. It seems as though some English words were =20
correctly replaced with French words, but also some French words that =20=

were already translated are also being replaced? I'm afraid I don't =20
know enough French to say what is correct; was there some dialect or =20
something that those changes are affecting?

On Nov 29, 2005, at 1:22 AM, Nicolas Contamin wrote:

> Arg, I'm such a fool in the morning
>
> 'eidolon' stands for 'eidolon.univ-lyon2.fr'. The link down their =20
> is repaired...
> All apologize,
>
> Nicolas.
>
> On 11/29/05, Nicolas Contamin <nic...@gm...> wrote:
>> On 11/29/05, Wesley Miaw <we...@we...> wrote:
>>> Hi Chad,
>>>
>>> I'm good. Jim, did you want to put anything else in like the CSS
>>> stuff? I haven't gotten another email from Nicolas about the changes
>>> he made to support removal of the weekends though. So we could also
>>> wait for that.
>>
>> Here (http://eidolon.univ-lyon2.fr/~nicoconta/diff_files/) are =20
>> patch files (in the
>> 'diff -Naur' format) for :
>>
>> n=B0 1109495 : "Print View does not show Location".
>> n=B0 1353342 : "Hide weekends".
>> n=B0 - : French translation file.
>>
>> I'm also thinking of a major change (Don't be scared!), but it'll be
>> the subject of my next mail ...
>>
>> Nicolas.

--
Wesley Miaw
we...@we...

Re: [PHPiCalendar-DEV] ready for 2.2?

[Wesley M. <we...@we...>]

Sorry I haven't responded to this yet. I get these incorporated soon.

On Nov 29, 2005, at 1:22 AM, Nicolas Contamin wrote:

> Arg, I'm such a fool in the morning
>
> 'eidolon' stands for 'eidolon.univ-lyon2.fr'. The link down their =20
> is repaired...
> All apologize,
>
> Nicolas.
>
> On 11/29/05, Nicolas Contamin <nic...@gm...> wrote:
>> On 11/29/05, Wesley Miaw <we...@we...> wrote:
>>> Hi Chad,
>>>
>>> I'm good. Jim, did you want to put anything else in like the CSS
>>> stuff? I haven't gotten another email from Nicolas about the changes
>>> he made to support removal of the weekends though. So we could also
>>> wait for that.
>>
>> Here (http://eidolon.univ-lyon2.fr/~nicoconta/diff_files/) are =20
>> patch files (in the
>> 'diff -Naur' format) for :
>>
>> n=B0 1109495 : "Print View does not show Location".
>> n=B0 1353342 : "Hide weekends".
>> n=B0 - : French translation file.
>>
>> I'm also thinking of a major change (Don't be scared!), but it'll be
>> the subject of my next mail ...
>>
>> Nicolas.

--
Wesley Miaw
we...@we...

Re: [PHPiCalendar-DEV] Real admin page

[Wesley M. <we...@we...>]

Hi Nicolas,

>  Ok.
> The idea is to let just the admin modifying those parameters, under  
> the secure admin area.
> So if apache is well configured, it would be any problem.
>
> I'll work on it next week, when I'll be less busy, and call you  
> back for analysing the effectivness.

Just to be clear, my opinion is that we shouldn't make the contents  
of config.inc.php editable or viewable from a web page. I do not know  
if any of the other developers have an opinion on this one way or the  
other.

>> I still don't understand your question, sorry?
>
> Login/pass seem to be used only for admin purpose.
> And according to the code, 'admin' is an apache authenticated user,  
> so i'm not sure, it's usefull to duplicate it (and in a clear format).

There are different logins at work here. The login for the admin page  
is not an HTTP authenticated user. HTTP authentication is used (at  
least as far as config.inc.php is concerned) to identify users for  
access to different calendars.

The login for the admin page may either be authenticated against the  
username in config.inc.php or against an FTP server (which I have not  
tried myself) and is used to determine who can upload calendar files.

BTW - I just noticed the default is for admin to be 'yes'. I think it  
should default to 'no'. Anyone else have opinions on this?

>> I don't see much alternative to having a plaintext username/password
>> for the admin login. You want to do a client-side one-way hash or
>> something? Or something more complicated like SiteKey?
>
> Yes a ('homemade' ?) hash or a web base auth. as we already use in  
> 'publish.ical.php'.

HTTP authentication is also passed in the clear unless you are using  
SSL. So that doesn't give you any benefits over the current plaintext  
login. Turning on HTTP authentication also requires more web server  
privileges than some people have. So moving from the current username/ 
password text login to an HTTP authentication is a bad idea in my  
opinion. It will work for less people, and not give you any security  
benefits.

A client-side hash is an interesting thing to consider. But to do  
this securely, you need to make it a one-way hash that is different  
every time, based on a token provided by the server. And the server  
needs to manage the token(s) that were distributed to allow only one- 
time use at the client. Otherwise you can just replay the captured  
hash and you're in. Those same tokens need some sort of expiration.

If you want to try and tackle implementing something like Diffie- 
Hellman (which I think still has problems, but I always remember the  
name) then you're welcome to. A bit of overkill in my opinion though.  
We could ask for peer-review of the PHP code at sci.crypt or something.

Later,
--
Wesley Miaw
we...@we...

Re: [PHPiCalendar-DEV] Real admin page

[Nicolas C. <nic...@gm...>]

Hi Wesley,

On 12/1/05, Wesley Miaw <we...@we...> wrote:
>
> Being able to modify the values such as to show events or todos may
> expose information the calendar owner or server administrator doesn't
> want to expose. Supporting webcals from a site that doesn't initially
> want to do that may result in abuse of their installation. The
> tmp_dir and calendar path provide information about the web server's
> internals which could be bad if revealed.
>
> Certainly accessing and/or modifying this information is ideally
> restricted. All I'm saying is that by exposing this on a web page,
> we're opening ourselves up to additional security concerns and in my
> opinion the benefits are negligible.


 Ok.
The idea is to let just the admin modifying those parameters, under the
secure admin area.
So if apache is well configured, it would be any problem.

I'll work on it next week, when I'll be less busy, and call you back for
analysing the effectivness.

I still don't understand your question, sorry?


Login/pass seem to be used only for admin purpose.
And according to the code, 'admin' is an apache authenticated user, so i'm
not sure, it's usefull to duplicate it (and in a clear format).

I don't see much alternative to having a plaintext username/password
> for the admin login. You want to do a client-side one-way hash or
> something? Or something more complicated like SiteKey?
>

Yes a ('homemade' ?) hash or a web base auth. as we already use in '
publish.ical.php'.

Let stand this point until I give you something to (crack), look at.


Nicolas.

Re: [PHPiCalendar-DEV] Real admin page

[Wesley M. <we...@we...>]

Hi Nicolas,

>> I would consider the calendar path, things like webcals, showing
>> events, showing todos, login, the tmp_dir, and all of those login
>> things like locked cals, etc to be secret information also.
>
> What is damaging in seeing all thoses information (I'm not talking,  
> of course, about login) ?
> Calendars are access restricted, by the htaccess procedure, and  
> everything else is just information, in a readonly (well configure)  
> anonymous web server ...

Being able to modify the values such as to show events or todos may  
expose information the calendar owner or server administrator doesn't  
want to expose. Supporting webcals from a site that doesn't initially  
want to do that may result in abuse of their installation. The  
tmp_dir and calendar path provide information about the web server's  
internals which could be bad if revealed.

Certainly accessing and/or modifying this information is ideally  
restricted. All I'm saying is that by exposing this on a web page,  
we're opening ourselves up to additional security concerns and in my  
opinion the benefits are negligible.

>> > What are their practical uses ?
>> > Entering the 'admin' page and publishing (I'm not sure, they're  
>> really
>> > useful in it), what else ?
>>
>> Not sure what your question is?
>
> A part of entering the admin page and publishing calendars, where  
> the couple login/pass is used, in phpicalendar ? (I'm thinking of  
> getting rid of plaintext password, because THAT is a real security  
> breach)

I still don't understand your question, sorry?

I don't see much alternative to having a plaintext username/password  
for the admin login. You want to do a client-side one-way hash or  
something? Or something more complicated like SiteKey?

Later,
--
Wesley Miaw
we...@we...

Re: [PHPiCalendar-DEV] Real admin page

[Nicolas C. <nic...@gm...>]

On 11/30/05, Wesley Miaw <we...@we...> wrote:
>
> Hi Nicolas,
>
> > You're right.
> > The login/pass are the only secret information contained in this file,
> > aren't they ?
>
> I would consider the calendar path, things like webcals, showing
> events, showing todos, login, the tmp_dir, and all of those login
> things like locked cals, etc to be secret information also.


What is damaging in seeing all thoses information (I'm not talking, of
course, about login) ?
Calendars are access restricted, by the htaccess procedure, and everything
else is just information, in a readonly (well configure) anonymous web
server ...

The other stuff is more cosmetic, and probably not damaging to expose.
>
> > What are their practical uses ?
> > Entering the 'admin' page and publishing (I'm not sure, they're really
> > useful in it), what else ?
>
> Not sure what your question is?


A part of entering the admin page and publishing calendars, where the coupl=
e
login/pass is used, in phpicalendar ? (I'm thinking of getting rid of
plaintext password, because THAT is a real security breach)


Nicolas.

Re: [PHPiCalendar-DEV] Real admin page

[Wesley M. <we...@we...>]

Hi Nicolas,

> You're right.
> The login/pass are the only secret information contained in this file,
> aren't they ?

I would consider the calendar path, things like webcals, showing  
events, showing todos, login, the tmp_dir, and all of those login  
things like locked cals, etc to be secret information also.

The other stuff is more cosmetic, and probably not damaging to expose.

> What are their practical uses ?
> Entering the 'admin' page and publishing (I'm not sure, they're really
> useful in it), what else ?

Not sure what your question is?

Later,
--
Wesley Miaw
we...@we...

[PHPiCalendar-DEV] I think I broke something

[Jim Hu <ji...@ta...>]

I thought I had checked, but I my last change to calendar_functions  
broke it and should be reverted.  Sorry!!!  I can't believe I didn't  
test that simple thing.

The line should be
	return substr(basename($cal_path),0,4);
not 	
	returnbasename($cal_path,".ics");

I realize that the problem I was trying to fix was something I  
created in rss.php when I was trying to fix problems with webcals.  I  
reverted that too.
I've repatched both in CVS.  Ugh.  Sorry again.  I'm still not sure  
why this didn't work.

Jim
=====================================
Jim Hu
Associate Professor and Associate Head for Graduate Programs
Dept. of Biochemistry and Biophysics
2128 TAMU
Texas A&M Univ.
College Station, TX 77843-2128
979-862-4054

Re: [PHPiCalendar-DEV] Real admin page

[Nicolas C. <nic...@gm...>]

On 11/30/05, Wesley Miaw <we...@we...> wrote:
> The advantage of having the variables only defined in config.inc.php
> is security. I personally would not want to expose certain things on
> the admin page. And I don't think the current situation is too
> difficult for regular admins to grasp. Right now, config.inc.php can
> be read-only and it can hide things like the blacklisted calendars or
> user accounts. We're opening up a whole can of worms if we decide to
> make this something that can be modified from a web page.
>
> Certainly, the idea is nice. But I think things are less complicated
> and more secure the current way, and there is very little advantage
> to putting together a web-based admin page. config.inc.php is too
> straight-forward and simple as it stands for me to believe it can
> really benefit from a better UI.
>
> Anyway, that's my 2 cents.

You're right.
The login/pass are the only secret information contained in this file,
aren't they ?

What are their practical uses ?
Entering the 'admin' page and publishing (I'm not sure, they're really
useful in it), what else ?

By the way, thanks all for your cents, thats the major point of a discussio=
n. ;)


Nicolas.
--
I'm a poor and lonesome Yaourt... (Air connu)

Re: [PHPiCalendar-DEV] What License does PHP iCalendar use?

[Wesley M. <we...@we...>]

I'm guessing the BSD license is what Chad is really looking for???

Anyway, bundling is different from integrating. Under the GPL (which =20
is PHP iCalendar's current license), if they integrate PHP iCalendar =20
with their other software, then their other software needs to be =20
released under the GPL also. But if they're just bundling then the =20
only thing they need to do is include the source code somehow, and =20
not even necessarily on the same media.

Just from looking at the screen shots, it looks like TasksPro will =20
generate iCalendar files, which can be accessed or subscribed to via =20
any iCalendar compliant software, which includes PHP iCalendar. Which =20=

seems to match his statement:

"Please note: PHP iCalendar is bundled with Tasks Pro=99 as a web based =20=

iCalendar viewer for the Tasks Pro=99 generated iCalendars. However, =20
PHP iCalendar is not my software and I do not provide any support for =20=

it."

On Nov 29, 2005, at 4:38 PM, Ben Francis wrote:

> Chad Little wrote:
>> I've actually considered changing the license to something free-er
>> under Creative Commons. Like free but give attribution.
>
> Just want to mention that every time someone posts a message the
> creative commons license mailing list asking about licensing software
> the usual response is "Creative Commons isn't really suited to
> software". It's not that you can't use a creative commons license, =20
> it's
> just not what they're designed for and you could run into problems in
> the future.
>
> --
> Ben "tola" Francis
> http://hippygeek.co.uk
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through =20
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD =20
> SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel

--
Wesley Miaw
we...@we...

Re: [PHPiCalendar-DEV] Real admin page

[Wesley M. <we...@we...>]

The advantage of having the variables only defined in config.inc.php =20
is security. I personally would not want to expose certain things on =20
the admin page. And I don't think the current situation is too =20
difficult for regular admins to grasp. Right now, config.inc.php can =20
be read-only and it can hide things like the blacklisted calendars or =20=

user accounts. We're opening up a whole can of worms if we decide to =20
make this something that can be modified from a web page.

Certainly, the idea is nice. But I think things are less complicated =20
and more secure the current way, and there is very little advantage =20
to putting together a web-based admin page. config.inc.php is too =20
straight-forward and simple as it stands for me to believe it can =20
really benefit from a better UI.

Anyway, that's my 2 cents.

On Nov 29, 2005, at 3:10 AM, Marook Kenja wrote:

> Hi Nicolas,
>
> Well, it was just a suggestion for an easy solution, so you didn't =20
> have to include XML parsing functions, or write your own parser - =20
> or at least a very simple write function.
>
> As the 'parser' would be a simple 'include "path/to/file.inc.php";'
> and the write could simply run through the defined variables, maybe =20=

> in an array, it should be Very simple.
>
> But if you wanna play around with parsing & writing XML files (or =20
> plain text), then fine with me - it's just raising the =20
> implementation level... ;-)
>
>
> Best,
>
>     Jakob Peterh=E4nsel
>
> 'I don't have to try to be a sex bomb, I am one!'
> - Kylie Minogue
>
> Email:     ja...@hj...
> AIM:         Marook
> Phone:     +45 22684961
>
> On 29/11/2005, at 11:12, Nicolas Contamin wrote:
>
>> On 11/29/05, Marook Kenja <ma...@cr...> wrote:
>>> Hi All,
>>>
>>> Why not write a PHP constant definition file insted?
>>>
>>> Then you only need to Write the file, not parse it back, as it would
>>> be simple
>>>
>>> define ('theSettingName', 'theValue');
>>> lines. Would that not be easier, or?
>>
>> I hardly find the interest of a static page in a script format.
>> When I'll click on the 'save' button, I'll have to rewrite a php file
>> ? Sound strange to me.
>>
>> Would mind to explain a little bit more ?
>> Parsing is not a real charge for the server according to the =20
>> current process.

--
Wesley Miaw
we...@we...

Re: [PHPiCalendar-DEV] What License does PHP iCalendar use?

[Ben F. <li...@hi...>]

Chad Little wrote:
> I've actually considered changing the license to something free-er 
> under Creative Commons. Like free but give attribution. 

Just want to mention that every time someone posts a message the
creative commons license mailing list asking about licensing software
the usual response is "Creative Commons isn't really suited to
software". It's not that you can't use a creative commons license, it's
just not what they're designed for and you could run into problems in
the future.

--
Ben "tola" Francis
http://hippygeek.co.uk

Re: [PHPiCalendar-DEV] What License does PHP iCalendar use?

[Chad L. <ch...@ch...>]

I've actually considered changing the license to something free-er =20
under Creative Commons. Like free but give attribution. It hasn't =20
been an issue getting improvements back into the system.

-Chad

On Nov 29, 2005, at 3:08 PM, Marook Kenja wrote:

> Hi,
>
> Ok, I just thought they where not allowed to charge for software =20
> that included it, but is allowed to charge for consultant work =20
> around it.
>
> As their software links to this project and even state "now =20
> includes PHP iCalendar 2.1", it seems to me they make money on open-=20=

> source software be re-selling it.
> I know it's onnly an add-on feature, but it's listed as a feature, =20
> not as a 'possible integration option'
>
> Ohh well..,
>
>
>     Jakob Peterh=E4nsel
>
> 'I don't have to try to be a sex bomb, I am one!'
> - Kylie Minogue
>
> Email:     ja...@hj...
> AIM:         Marook
> Phone:     +45 22684961
>
> On 29/11/2005, at 23:27, Ben Francis wrote:
>
>> Marook Kenja wrote:
>>
>>> If PHP iCalendar is under GPL, shouldn't there be a free non-=20
>>> commersial
>>> version of Tasks Pro as long as they use this software in it????
>>
>> There is nothing in the GPL which prohibits anyone from charging for
>> software, providing they release the source code of any changes they
>> make. It's free as in freedom, not free as in beer.
>>
>> Ben
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through =20
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD =20
> SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel

Re: [PHPiCalendar-DEV] What License does PHP iCalendar use?

[Marook K. <ma...@cr...>]

Hi,

Ok, I just thought they where not allowed to charge for software that =20=

included it, but is allowed to charge for consultant work around it.

As their software links to this project and even state "now includes =20
PHP iCalendar 2.1", it seems to me they make money on open-source =20
software be re-selling it.
I know it's onnly an add-on feature, but it's listed as a feature, =20
not as a 'possible integration option'

Ohh well..,


     Jakob Peterh=E4nsel

'I don't have to try to be a sex bomb, I am one!'
- Kylie Minogue

Email:     ja...@hj...
AIM:         Marook
Phone:     +45 22684961

On 29/11/2005, at 23:27, Ben Francis wrote:

> Marook Kenja wrote:
>
>> If PHP iCalendar is under GPL, shouldn't there be a free non-=20
>> commersial
>> version of Tasks Pro as long as they use this software in it????
>
> There is nothing in the GPL which prohibits anyone from charging for
> software, providing they release the source code of any changes they
> make. It's free as in freedom, not free as in beer.
>
> Ben
>

Re: [PHPiCalendar-DEV] What License does PHP iCalendar use?

[Ben F. <li...@hi...>]

Marook Kenja wrote:

> If PHP iCalendar is under GPL, shouldn't there be a free non-commersial
> version of Tasks Pro as long as they use this software in it????

There is nothing in the GPL which prohibits anyone from charging for
software, providing they release the source code of any changes they
make. It's free as in freedom, not free as in beer.

Ben

[PHPiCalendar-DEV] What License does PHP iCalendar use?

[Marook K. <ma...@cr...>]

Hi All,

Was surfing around tonight and saw a new version of 'Tasks Pro' from =20
King Design.

It's a commercial ($125-$500..) piece of PHP software, that 'bundles' =20=

PHP iCalendar, and I was wondering if this is even allowed - or are =20
someone in the developer group affiliated with King Design?

If PHP iCalendar is under GPL, shouldn't there be a free non-=20
commersial version of Tasks Pro as long as they use this software in =20
it????

Sorry about the non-code question..  ;-)


     Jakob Peterh=E4nsel

'I don't have to try to be a sex bomb, I am one!'
- Kylie Minogue

Email:     ja...@hj...
AIM:         Marook
Phone:     +45 22684961

[PHPiCalendar-DEV] cpath security, default getdate, and 2.2

[Jim Hu <ji...@ta...>]

Wesley makes a good point.  That's why I asked!  I uploaded changes  
to strip .. from cpath.  I used str_replace, so if anyone names a  
directory as this..directory, they're in trouble.  However, after  
uploading one change, I realized that someone might actually use  
this.directory as a directory name...so that's why there are two  
rapid CVS uploads in a row from me.  Sorry!

I also changed the default time calculation to

     $getdate = date('Ymd', time() + $second_offset);

from a version that used strtotime("now + $second_offset seconds).  I  
think this is slightly more efficient and that it might
I also changed calendar_functions so that instead of using substr 
(basename($calpath),0,-4), I use

  	return basename($cal_path,".ics");

The prior version truncates the calendar names in the rss feeds.
Chad...I think 2.2 is good to go...while there are still minor bugs,  
it seems like there were a lot of more major ones with 2.1.  Even  
without the patches I just did, I think we caught most of the things  
that led to the installation failures being posted on the bbs.

publish.php is giving people the usual number of problems, but I'm  
not sure if there's anything useful to do in the short run.

Jim



> Message: 4
> From: Wesley Miaw <we...@we...>
> Subject: Re: [PHPiCalendar-DEV] Easy solution for customizing
> Date: Mon, 28 Nov 2005 15:57:39 -0800
> To: php...@li...
> Reply-To: php...@li...
>
> Hi Jim,
>
> Unfortunately, that's a bad idea because it opens a major security
> hole. I know from previous devel list mail that some people are using
> PHP iCalendar in multi-user environments. Letting those users put a
> cpath_config.php file into their personal calendar directories makes
> it possible for those users to do lots of bad things.
>
> Also, some $cpath security logic needs to get put in. For example to
> remove any instances of .. or non-directory characters. Probably a
> good idea to make sure it always falls into a subdirectory of the
> main calendar directory, or something similar.
>
> I don't think we should ever make it possible for an end-user instead
> of a sysadmin to make server-side customizations. The $cpath is
> already pretty dangerous in my opinion, but at least it only allows
> access to *.ics files because of how it is used.
>
> On Nov 28, 2005, at 7:43 AM, Jim Hu wrote:
>
>> Last night I was wondering about customizing the webcalendars in
>> different subdirectories specified by cpath.  I just realized this
>> is unbelievably easy.  I can add this under the code in
>> init.inc.php that sets cpath
>>
>> #this allows you to place a file within a calendar subdirectory to
>> override global settings, or execute local code...e.g. to secure a
>> particular subdirectory.
>> if(is_file("$calendar_path/cpath_config.php")){
>> 	include ("$calendar_path/cpath_config.php");
>> }
>>
>> Then you can just drop a config file into that directory to
>> override whatever you want, insert login code, etc.  I think
>> something like this would be useful for anyone who wants to set up
>> a calendar server service.
>> What do you think?  Should I add this to CVS?  Or is there a better
>> way to do this?
>
> --
> Wesley Miaw
> we...@we...

Re: [PHPiCalendar-DEV] Real admin page

[Marook K. <ma...@cr...>]

Hi Nicolas,

Well, it was just a suggestion for an easy solution, so you didn't =20
have to include XML parsing functions, or write your own parser - or =20
at least a very simple write function.

As the 'parser' would be a simple 'include "path/to/file.inc.php";'
and the write could simply run through the defined variables, maybe =20
in an array, it should be Very simple.

But if you wanna play around with parsing & writing XML files (or =20
plain text), then fine with me - it's just raising the implementation =20=

level... ;-)


Best,

     Jakob Peterh=E4nsel

'I don't have to try to be a sex bomb, I am one!'
- Kylie Minogue

Email:     ja...@hj...
AIM:         Marook
Phone:     +45 22684961

On 29/11/2005, at 11:12, Nicolas Contamin wrote:

> On 11/29/05, Marook Kenja <ma...@cr...> wrote:
>> Hi All,
>>
>> Why not write a PHP constant definition file insted?
>>
>> Then you only need to Write the file, not parse it back, as it would
>> be simple
>>
>> define ('theSettingName', 'theValue');
>> lines. Would that not be easier, or?
>
> I hardly find the interest of a static page in a script format.
> When I'll click on the 'save' button, I'll have to rewrite a php file
> ? Sound strange to me.
>
> Would mind to explain a little bit more ?
> Parsing is not a real charge for the server according to the =20
> current process.
>
>
> Nicolas.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through =20
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD =20
> SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel