[CalendarX-users] CalendarX sponsorship: features request

[+lupa+]

Well folks,
Several of you have raised (or seconded) the question about potentially
helping to sponsor some fresh development in CalendarX. I have to admit
that I've been lax since January... I owe a bugfix release with new
translations (0.6.7), and I have been promising for even longer to
incorporate some of the advanced and wonderful features of the 0.5 branch
into the latest stable branch so that we have a more capable calendar
product than ever before. Coupled with some of the rapidly advancing new
Event-related products (such as Max's cool mxmCalendarTypes and Shaddox's
work toward recurrent events), calendar making in Plone could be poised for
some very nice advances.

Primarily, I have been busy elsewhere. I teach full time and have
essentially zero recurring consulting work to keep me occupied with Plone,
despite my love for the beast and the coding. However, teaching's main
rewards are other than a tall paycheck, and frankly a sponsorship of some
work on CalendarX could sway me to dive back in (and would make my wife
happier, I do think).

That said, before I put any price on my life's work, I'd like to ask
one more time (haven't asked this for months), for any and all interested
to put your two cents in here and describe
1) what features in the 0.5 branch you most want to see in a new 0.7 branch
2) what new features you most want to see released in a new 0.7 branch
3) optional: what you think this sponsorship might be worth.

#3 is the hardest for me. When in the past I consulted in CalendarX
development (there has been no new consulting in many months... I have made
it too easy to learn, apparently), I charged $50/hour (USD) for work that
could be put back into the GPL'd CalendarX code base. Potentially there
are a lot of hours here, and I don't realistically expect to make that much
from this. But if you have any thoughts, I'd appreciate them. Feel free
to send your comments to the list, or to me privately if you'd prefer.

I think I'll take your suggestions, add some of my own, prioritize them
in a list, and then figure out how to put some sort of price tag on it,
return it to the list for advice, and we'll get this started! I'm eager to
do some calendar work again, let's make this next one a good one.

Lines are open, operators are standing by...
+lupa+

[David Diskin]

here's some parts of previous messages copied/pasted: first is
comment on proposed version 1.0 from last year.
========================================================================
=

lupa -

Overall, this sounds very good. It is great that the 0.5 querying
capabilities will not lose any functionaity. I rely on those a lot.

I have initially these 2 concerns:

1. No portlets. This will be a problem for me as I am using CalX
portlets to give me the same events (depends on the role of the
person) as with the Calendar views. So this is the #1 Most
Important Feature I can't Live Without.

2. Scaling with VERY large number of events. When you say "All the
events....will be loaded into CalX at once", does this mean every
event in the plone site (subject to query screening)? So, if I have
2 years' of events, all 2 years' will be sucked up? This could be a
problem for me.

That's it right now. Thanks.

David

lupa -
Will the 1.0 version have all the capabilities of the 0.5.x branch?
That's what I rely on for my site. Thanks,
David

Hi David,
Answer is: both more and less capabilities.
There's two parts to the implementation: views and queries.
Views. there is a view template plus a large block of JS code that
drives the views. It has a very similar look/feel to the existing
CalendarX. Currently it has five calendar-style views plus five
listing-style views (day, weekbyhour, weekbyday, month, multiple
months), plus a help view. It manages categories in a very similar
fashion to the current CalendarX. It also allows you to select
among two or more calendars, or sets of events (this is new to
CalendarX users, but reflects anticipated eventual ability to
import several iCalendars and switch among them).
Queries. This is the process of bringing in events to populate
CalendarX. I'm designing the 1.0 branch to be independent of
Plone, so the background querying mechanism here will be built in
Plone/Zope/CMF. I expect to use the 0.5 branch querying tools down
here to allow full control over what events are pulled into CalendarX.
So, to actually address your question with respect to the very
1) in the viewing arena, the new CalendarX will be very similar,
but constructed in an entirely different fashion and will not have
precisely the same available options as we have in the current
branches... at least not at first. I don't see anything impossible
to implement, but I can't get it all done for 1.0.
2) in the querying arena, the new CalendarX should have all the
capabilities of the 0.5 branch (which is a superset of the 0.4/0.6
branches), and so it should not lose any capabilities there.
3) there will not initially be a "subcalendar" capability that is
comparable to what exists now in CalendarX. I have done no work
yet toward the type of functionality that would accompany a
"resource scheduling" calendar. It should be possible, but it has
not been my priority. The multiple calendar capability that 1.0
now has may be usable as a subcalendar proxy, but I haven't
investigated it toward that use case.
4) I am working on i18n functionality, but no guarantees for the
first release. expect minimal functionality here, if any.
5) the views will not be as readily customizable as they are
currently... no property sheets controlling variables, etc. There
will be some customizable choices, and CalendarX will have its own
CSS style sheet.
6) currently the test version has no rollover highlighting or
rollover popup text blocks. I want this, but haven't implemented
it yet.
7) no portlets. at least not any planned.
A) Platform Independence: By separating viewing from querying
completely, we get the possibility that CalendarX can be integrated
with other CMS packages and website creation tools, based in any
language or on any database. All that is required is a template to
hold the CalendarX div and a querying call to the backend that
holds the events. I currently develop this branch from a folder on
my desktop with no CMS at all behind it (it generates random events
for testing purposes).
B) Speed. All the events that you have in your calendar will be
loaded into CalendarX at once. Then CalendarX creates the views on
the client side using Javascript instead of Python and ZPT on the
server. So the CalendarX user never needs to hit the server again
as long as the calendar view is in the browser.
C) Scaling. Part B may lead to problems on sites with VERY large
collections of events. So the 1.0 branch will (not at first, but
eventually) include AJAX functions to bring the most current events
in first, so that the calendar becomes viewable, and then gradually
downloads the other events in the background. Preliminary tests
suggest this will only be necessary for VERY large calendars (>
several hundred events).
D) Eventual iCalendar with recurring events. This is the version
where I will build in iCalendar and recurring events
functionality. Eventually.
That's all. You will like it. The 1.0 release will NOT be
considered "STABLE". It will be more of a Technology Preview.
Some folks will be able to just use it right out of the box. Most
others will want to wait until it matures, but will rightly pester
me with requests for features. That is what I would like to happen.
So even now (this means you, David), write me with your "Most
Important Features I Cannot Live Without" ideas, and I'll keep them
in mind as I work toward 1.0.
Meanwhile, I should quit writing about it and get back to
developing so that it does not remain vaporware forever... I'm
sure I've left some ideas out here, but it's something to chew on.
+lupa+

i


another message:

=============================================================
In addition to allowing choice of which categories/subjects to
include, also provide capability to exclude categories.

Here's a use case. In my main calendar, i will display school events
for members. But, i'm anticipating that many members will want to
'turn off' school events. It would be nice if they could just check
the exclude box for school.

So i could imagine the calendar choices portlet could now look like
this (you may have a better UI idea):

Include Exclude
box All
box Meeting box
box School box
box Social box

(no box to exclude All - makes no sense)
So, I could foresee user checking the include box for "All" and the
exclude box for School

==============================

Yes please, if you would resend, and post it to the list, that
would be a great start for others. Thanks David!
+lupa+

lupa -
i have previously given my 0.5 feature list that i wish would be
migrated to new branhc. let me know if you need me to resend.
david

==============================
David Diskin, ***@verizon.net

[George Lee]

My main request is that CalendarX move to some solidly clean code using
Zope3 concepts. I worry that it is going to be outdated soon and that other
calendar products will replace it otherwise.

Peace,
George

Post by David Diskin
here's some parts of previous messages copied/pasted: first is
comment on proposed version 1.0 from last year.
========================================================================
=
lupa -
Overall, this sounds very good. It is great that the 0.5 querying
capabilities will not lose any functionaity. I rely on those a lot.
1. No portlets. This will be a problem for me as I am using CalX
portlets to give me the same events (depends on the role of the
person) as with the Calendar views. So this is the #1 Most
Important Feature I can't Live Without.
2. Scaling with VERY large number of events. When you say "All the
events....will be loaded into CalX at once", does this mean every
event in the plone site (subject to query screening)? So, if I have
2 years' of events, all 2 years' will be sucked up? This could be a
problem for me.
That's it right now. Thanks.
David

Post by David Diskin
lupa -
Will the 1.0 version have all the capabilities of the 0.5.x branch?
That's what I rely on for my site. Thanks,
David

Hi David,
Answer is: both more and less capabilities.
There's two parts to the implementation: views and queries.
Views. there is a view template plus a large block of JS code that
drives the views. It has a very similar look/feel to the existing
CalendarX. Currently it has five calendar-style views plus five
listing-style views (day, weekbyhour, weekbyday, month, multiple
months), plus a help view. It manages categories in a very similar
fashion to the current CalendarX. It also allows you to select
among two or more calendars, or sets of events (this is new to
CalendarX users, but reflects anticipated eventual ability to
import several iCalendars and switch among them).
Queries. This is the process of bringing in events to populate
CalendarX. I'm designing the 1.0 branch to be independent of
Plone, so the background querying mechanism here will be built in
Plone/Zope/CMF. I expect to use the 0.5 branch querying tools down
here to allow full control over what events are pulled into CalendarX.
So, to actually address your question with respect to the very
1) in the viewing arena, the new CalendarX will be very similar,
but constructed in an entirely different fashion and will not have
precisely the same available options as we have in the current
branches... at least not at first. I don't see anything impossible
to implement, but I can't get it all done for 1.0.
2) in the querying arena, the new CalendarX should have all the
capabilities of the 0.5 branch (which is a superset of the 0.4/0.6
branches), and so it should not lose any capabilities there.
3) there will not initially be a "subcalendar" capability that is
comparable to what exists now in CalendarX. I have done no work
yet toward the type of functionality that would accompany a
"resource scheduling" calendar. It should be possible, but it has
not been my priority. The multiple calendar capability that 1.0
now has may be usable as a subcalendar proxy, but I haven't
investigated it toward that use case.
4) I am working on i18n functionality, but no guarantees for the
first release. expect minimal functionality here, if any.
5) the views will not be as readily customizable as they are
currently... no property sheets controlling variables, etc. There
will be some customizable choices, and CalendarX will have its own
CSS style sheet.
6) currently the test version has no rollover highlighting or
rollover popup text blocks. I want this, but haven't implemented
it yet.
7) no portlets. at least not any planned.
A) Platform Independence: By separating viewing from querying
completely, we get the possibility that CalendarX can be integrated
with other CMS packages and website creation tools, based in any
language or on any database. All that is required is a template to
hold the CalendarX div and a querying call to the backend that
holds the events. I currently develop this branch from a folder on
my desktop with no CMS at all behind it (it generates random events
for testing purposes).
B) Speed. All the events that you have in your calendar will be
loaded into CalendarX at once. Then CalendarX creates the views on
the client side using Javascript instead of Python and ZPT on the
server. So the CalendarX user never needs to hit the server again
as long as the calendar view is in the browser.
C) Scaling. Part B may lead to problems on sites with VERY large
collections of events. So the 1.0 branch will (not at first, but
eventually) include AJAX functions to bring the most current events
in first, so that the calendar becomes viewable, and then gradually
downloads the other events in the background. Preliminary tests
suggest this will only be necessary for VERY large calendars (>
several hundred events).
D) Eventual iCalendar with recurring events. This is the version
where I will build in iCalendar and recurring events
functionality. Eventually.
That's all. You will like it. The 1.0 release will NOT be
considered "STABLE". It will be more of a Technology Preview.
Some folks will be able to just use it right out of the box. Most
others will want to wait until it matures, but will rightly pester
me with requests for features. That is what I would like to happen.
So even now (this means you, David), write me with your "Most
Important Features I Cannot Live Without" ideas, and I'll keep them
in mind as I work toward 1.0.
Meanwhile, I should quit writing about it and get back to
developing so that it does not remain vaporware forever... I'm
sure I've left some ideas out here, but it's something to chew on.
+lupa+

i
=============================================================
In addition to allowing choice of which categories/subjects to
include, also provide capability to exclude categories.
Here's a use case. In my main calendar, i will display school events
for members. But, i'm anticipating that many members will want to
'turn off' school events. It would be nice if they could just check
the exclude box for school.
So i could imagine the calendar choices portlet could now look like
Include Exclude
box All
box Meeting box
box School box
box Social box
(no box to exclude All - makes no sense)
So, I could foresee user checking the include box for "All" and the
exclude box for School
==============================

Yes please, if you would resend, and post it to the list, that
would be a great start for others. Thanks David!
+lupa+

Post by David Diskin
lupa -
i have previously given my 0.5 feature list that i wish would be
migrated to new branhc. let me know if you need me to resend.
david

==============================
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
CalendarX-users mailing list
https://lists.sourceforge.net/lists/listinfo/calendarx-users

[+lupa+]

I second this! But I would need someone to hold my hand, help me get
started. The current state of affairs inside CalendarX
(templates/macros/scripts) is a hodgepodge of accumulated addons to make it
do what I wanted it to. It still works, but Z3 views, etc and an
Archetypes base are definitely needed.

In short, I need a simple base product that uses Z3 concepts to start from,
to rebuild CalendarX. Anybody have suggestions?

+lupa+

Post by George Lee
My main request is that CalendarX move to some solidly clean code using
Zope3 concepts. I worry that it is going to be outdated soon and that
other calendar products will replace it otherwise.
Peace,
George
On 7/30/06, David Diskin

Post by David Diskin
here's some parts of previous messages copied/pasted: first is
comment on proposed version 1.0 from last year.
========================================================================
=
lupa -
Overall, this sounds very good. It is great that the 0.5 querying
capabilities will not lose any functionaity. I rely on those a lot.
1. No portlets. This will be a problem for me as I am using CalX
portlets to give me the same events (depends on the role of the
person) as with the Calendar views. So this is the #1 Most
Important Feature I can't Live Without.
2. Scaling with VERY large number of events. When you say "All the
events....will be loaded into CalX at once", does this mean every
event in the plone site (subject to query screening)? So, if I have
2 years' of events, all 2 years' will be sucked up? This could be a
problem for me.
That's it right now. Thanks.
David

Post by David Diskin
lupa -
Will the 1.0 version have all the capabilities of the 0.5.x branch?
That's what I rely on for my site. Thanks,
David

Hi David,
Answer is: both more and less capabilities.
There's two parts to the implementation: views and queries.
Views. there is a view template plus a large block of JS code that
drives the views. It has a very similar look/feel to the existing
CalendarX. Currently it has five calendar-style views plus five
listing-style views (day, weekbyhour, weekbyday, month, multiple
months), plus a help view. It manages categories in a very similar
fashion to the current CalendarX. It also allows you to select
among two or more calendars, or sets of events (this is new to
CalendarX users, but reflects anticipated eventual ability to
import several iCalendars and switch among them).
Queries. This is the process of bringing in events to populate
CalendarX. I'm designing the 1.0 branch to be independent of
Plone, so the background querying mechanism here will be built in
Plone/Zope/CMF. I expect to use the 0.5 branch querying tools down
here to allow full control over what events are pulled into CalendarX.
So, to actually address your question with respect to the very
1) in the viewing arena, the new CalendarX will be very similar,
but constructed in an entirely different fashion and will not have
precisely the same available options as we have in the current
branches... at least not at first. I don't see anything impossible
to implement, but I can't get it all done for 1.0.
2) in the querying arena, the new CalendarX should have all the
capabilities of the 0.5 branch (which is a superset of the 0.4/0.6
branches), and so it should not lose any capabilities there.
3) there will not initially be a "subcalendar" capability that is
comparable to what exists now in CalendarX. I have done no work
yet toward the type of functionality that would accompany a
"resource scheduling" calendar. It should be possible, but it has
not been my priority. The multiple calendar capability that 1.0
now has may be usable as a subcalendar proxy, but I haven't
investigated it toward that use case.
4) I am working on i18n functionality, but no guarantees for the
first release. expect minimal functionality here, if any.
5) the views will not be as readily customizable as they are
currently... no property sheets controlling variables, etc. There
will be some customizable choices, and CalendarX will have its own
CSS style sheet.
6) currently the test version has no rollover highlighting or
rollover popup text blocks. I want this, but haven't implemented
it yet.
7) no portlets. at least not any planned.
A) Platform Independence: By separating viewing from querying
completely, we get the possibility that CalendarX can be integrated
with other CMS packages and website creation tools, based in any
language or on any database. All that is required is a template to
hold the CalendarX div and a querying call to the backend that
holds the events. I currently develop this branch from a folder on
my desktop with no CMS at all behind it (it generates random events
for testing purposes).
B) Speed. All the events that you have in your calendar will be
loaded into CalendarX at once. Then CalendarX creates the views on
the client side using Javascript instead of Python and ZPT on the
server. So the CalendarX user never needs to hit the server again
as long as the calendar view is in the browser.
C) Scaling. Part B may lead to problems on sites with VERY large
collections of events. So the 1.0 branch will (not at first, but
eventually) include AJAX functions to bring the most current events
in first, so that the calendar becomes viewable, and then gradually
downloads the other events in the background. Preliminary tests
suggest this will only be necessary for VERY large calendars (>
several hundred events).
D) Eventual iCalendar with recurring events. This is the version
where I will build in iCalendar and recurring events
functionality. Eventually.
That's all. You will like it. The 1.0 release will NOT be
considered "STABLE". It will be more of a Technology Preview.
Some folks will be able to just use it right out of the box. Most
others will want to wait until it matures, but will rightly pester
me with requests for features. That is what I would like to happen.
So even now (this means you, David), write me with your "Most
Important Features I Cannot Live Without" ideas, and I'll keep them
in mind as I work toward 1.0.
Meanwhile, I should quit writing about it and get back to
developing so that it does not remain vaporware forever... I'm
sure I've left some ideas out here, but it's something to chew on.
+lupa+

i
=============================================================
In addition to allowing choice of which categories/subjects to
include, also provide capability to exclude categories.
Here's a use case. In my main calendar, i will display school events
for members. But, i'm anticipating that many members will want to
'turn off' school events. It would be nice if they could just check
the exclude box for school.
So i could imagine the calendar choices portlet could now look like
Include Exclude
box All
box Meeting box
box School box
box Social box
(no box to exclude All - makes no sense)
So, I could foresee user checking the include box for "All" and the
exclude box for School
==============================

Yes please, if you would resend, and post it to the list, that
would be a great start for others. Thanks David!
+lupa+

Post by David Diskin
lupa -
i have previously given my 0.5 feature list that i wish would be
migrated to new branhc. let me know if you need me to resend.
david

==============================
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net 's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
<http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
CalendarX-users mailing list
https://lists.sourceforge.net/lists/listinfo/calendarx-users