Hi Paul,
So the abstraction layer already exists it's good.
Ok, so merging my changes to the original repository should not be that
hard. I'll check out how to do it and mail you when it's ready to be done.
I understand it will be annoying for people that have to choose between
the two ical framework. But, as I said before I'm ok to do some
improvements but only concerning the pharo side... Well, for this
library it shouldn't be that hard to use non-specific stuff I guess.
I'll keep you informed of what I'm doing :)
Regards,
Julien
On 16/05/15 17:04, Paul DeBruicker wrote:
Hi Julien,
The only reason I mind that you forked it is that you now force every person
that isn't yet using iCal in their project, but that wants to adopt it, to
have to decide and evaluate both projects to see which one to adopt for
their own use. So instead of you adopting the burden of integrating your
changes with what exists you've pushed that decision onto all future
potential users of iCal in Pharo. Which seems suboptimal.
That being said it is MIT licensed code, and you can do whatever you want
with it.
What I did say to you on April 3 after giving you commit access to the iCal
repo (which was not public because I forgot to flip the bit for that, fixed
now tho) was:
"Right now it runs on Squeak, Pharo, and GemStone.
Please don't break them with your changes ;)
You should be able to ensure that the Pharo 4 specific stuff only loads into
Pharo 4 without too much trouble."
I see now that that was vague. I was thinking that with the proper design &
Metacello configuration your changes should be loadable no problem without
breaking all the other dialects.
By the way, I've had a HTTPClient/Url cross dialect compatability package
I've been maintaining here:
http://smalltalkhub.com/#!/~pdebruic/HTTPAPIClient
It could certainly use some attention but may have been helpful to your work
on iCal.
Glad your making progress with the GTInspector and docs though. That ical
spec (https://tools.ietf.org/html/rfc5545) is long and boring.
Julien Delplanque wrote
Hi everyone,
I took a little time to enhance the ICal library and to make it work
with Pharo 4!
So I forked the one on smalltalkhub
(http://smalltalkhub.com/#!/~pdebruic/iCal) and put all the modified
code on github https://github.com/juliendelplanque/pharo-ical.
Why did I forked? Well, I wanted to make it work on pharo 4 first, so I
contacted the owner of the smalltalkhub repository. He wanted to keep it
working on other smalltalk than Pharo. The problem was that the lib used
Url class that were deprecated in Pharo 3 and even removed on Pharo 4!
So I managed to repair the package using ZnUrl. Since I don't know if
the owner of this lib on Smalltalkhub have time to manage the problem to
keep the lib "multi-smalltalk", I have chosen to fork it so he can keep
his version compatible.
Good news are that I plan to keep it alive as long as I can, write some
documentation for it when I have time and even try to enhance it.
I already added a GTInspector extension to have better representation
of iCalendar when inspecting them in Pharo.
The version on master branch is supported by Pharo 2-3-4 (didn't check
with Pharo 1).
Regards,
Julien
--
View this message in context:
http://forum.world.st/Enhancing-ICal-library-tp4825990p4826767.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
