ical output plugin - sitemap feedback wanted

[Sjur Moshagen]

Hello all,

For a long time our project group has been using an ical output  
project module that I'm now converting to a real plugin, which I  
intend to add to the whiteboard. For historical reasons, the url  
pattern matched against presupposes a certain file naming scheme, as  
follows:

<!--   Will match weekly meeting files {2}, and extract the tasks for  
the
person in {3}, returning the task list as an iCal TODO list -->
<map:match pattern="**/Tasks_*_*.ics">
     <map:generate src="cocoon://{1}/Meeting_{2}.xml" />
     <map:transform src="{lm:ical.transform.document.ics}">
         <map:parameter name="date" value="{2}" />
         <map:parameter name="person" value="{3}" />
     </map:transform>
     <map:serialize type="ical" />
</map:match>

That is, the meeting date is encoded in the filename, and the person  
for which the ical file should be created is encoded in the URL in  
addition to the date. Also, the filename is fixed to the pattern  
"Meeting_{DATE}.xml (or actually *.jspwiki in our case). Is this ok,  
or should I change to a more general pattern? One reasoning is that it  
doesn't make sense to create an ical file for a non-meeting document,  
and this dependency is expressed in the URL and filename patterns. But  
then again, the whole plugin depends on certain conventions in the  
source document, so you can anyway add non-working links (ie link to  
meeting documents that do not follow these conventions).

Comments on the URL or filename patterns? Other comments?

General note:

This is an excellent example of the flexibility and usefulness of  
Forrest. We (a project team geographically distributed) have regular  
meetings using voicechat software + a collaborative editor (usually  
SubEthaEdit because we are on Macs, but Gobby will do fine), we write  
in jspwiki format, ie structured, plain text (the KISS principle),  
which is transformed by Forrest to online meeting memos (pdf, html)  
and task lists in iCal format using the plugin described above.

Best regards,
Sjur

[David Crossley]

Sjur Moshagen wrote:

> Hello all,
>
> For a long time our project group has been using an ical output  
> project module that I'm now converting to a real plugin, which I  
> intend to add to the whiteboard. For historical reasons, the url  
> pattern matched against presupposes a certain file naming scheme, as  
> follows:
>
> <!--   Will match weekly meeting files {2}, and extract the tasks for  
> the
> person in {3}, returning the task list as an iCal TODO list -->
> <map:match pattern="**/Tasks_*_*.ics">
>     <map:generate src="cocoon://{1}/Meeting_{2}.xml" />
>     <map:transform src="{lm:ical.transform.document.ics}">
>         <map:parameter name="date" value="{2}" />
>         <map:parameter name="person" value="{3}" />
>     </map:transform>
>     <map:serialize type="ical" />
> </map:match>
>
> That is, the meeting date is encoded in the filename, and the person  
> for which the ical file should be created is encoded in the URL in  
> addition to the date. Also, the filename is fixed to the pattern  
> "Meeting_{DATE}.xml (or actually *.jspwiki in our case). Is this ok,  
> or should I change to a more general pattern? One reasoning is that it  
> doesn't make sense to create an ical file for a non-meeting document,  
> and this dependency is expressed in the URL and filename patterns. But  
> then again, the whole plugin depends on certain conventions in the  
> source document, so you can anyway add non-working links (ie link to  
> meeting documents that do not follow these conventions).
>
> Comments on the URL or filename patterns? Other comments?

This is exiting. That seems like a fine approach to me.

> General note:
>
> This is an excellent example of the flexibility and usefulness of  
> Forrest. We (a project team geographically distributed) have regular  
> meetings using voicechat software + a collaborative editor (usually  
> SubEthaEdit because we are on Macs, but Gobby will do fine), we write  
> in jspwiki format, ie structured, plain text (the KISS principle),  
> which is transformed by Forrest to online meeting memos (pdf, html)  
> and task lists in iCal format using the plugin described above.

This is very interesting. Thanks so much for sharing a
situation for how you use Forrest. That should encourage.

This is very timely for me. I need to help with forming a
co-operative and they will need to conduct their first meeting
of distributed members.

I did a net search and found some of your explanations
at divvun.no ... will see what tips i can glean. Thanks.

-David

[rgardler]

2009/8/19 David Crossley <crossley@...>:

> Sjur Moshagen wrote:
>> Hello all,
>>
>> For a long time our project group has been using an ical output
>> project module that I'm now converting to a real plugin, which I
>> intend to add to the whiteboard. For historical reasons, the url
>> pattern matched against presupposes a certain file naming scheme, as
>> follows:
>>
>> <!--   Will match weekly meeting files {2}, and extract the tasks for
>> the
>> person in {3}, returning the task list as an iCal TODO list -->
>> <map:match pattern="**/Tasks_*_*.ics">
>>     <map:generate src="cocoon://{1}/Meeting_{2}.xml" />
>>     <map:transform src="{lm:ical.transform.document.ics}">
>>         <map:parameter name="date" value="{2}" />
>>         <map:parameter name="person" value="{3}" />
>>     </map:transform>
>>     <map:serialize type="ical" />
>> </map:match>
>>
>> That is, the meeting date is encoded in the filename, and the person
>> for which the ical file should be created is encoded in the URL in
>> addition to the date. Also, the filename is fixed to the pattern
>> "Meeting_{DATE}.xml (or actually *.jspwiki in our case). Is this ok,
>> or should I change to a more general pattern? One reasoning is that it
>> doesn't make sense to create an ical file for a non-meeting document,
>> and this dependency is expressed in the URL and filename patterns. But
>> then again, the whole plugin depends on certain conventions in the
>> source document, so you can anyway add non-working links (ie link to
>> meeting documents that do not follow these conventions).
>>
>> Comments on the URL or filename patterns? Other comments?
>
> This is exiting. That seems like a fine approach to me.

I agree that it's great to see some new work here. I don't quite agree
that the URL patterns is a "fine approach" though. But don't worry,
it's a small change I am going to propose and it is backward
compatible with your current scheme.

Basically, some time ago we decided that fixed url patterns were a bad
idea since it creates potential clashes in peoples applications. We
therefore implemented the new (although not officially released) XML
properties system to allow the sitemap to be easily configured without
having to edit the plugin files (actually that was a side effect, but
that's not relevant right now).

You can see an example of this approach in use in the Daisy input
plugin (whiteboard):

input.xmap:

      <map:match
pattern="{properties:daisy.pathPrefix}*{properties:daisy.fileExt}.xml">
        <map:call resource="daisy-to-document">
          <map:parameter name="docID" value="{1}"/>
          <map:parameter name="path" value="{0}"/>
        </map:call>
      </map:match>

forrest.properties.xml:

<property name="daisy.pathPrefix" value=""/>
...
<property name="daisy.fileExt" value=".daisy"/>

Now the project can override these properties in its local
forrest.properties.xml if it needs to do so, or it can leave them at
their defaults for the same behaviour as your existing sitemap.

Ross

[Sjur Moshagen]

Den 19. aug. 2009 kl. 16.30 skrev David Crossley:

>> General note:
>>
>> This is an excellent example of the flexibility and usefulness of
>> Forrest. We (a project team geographically distributed) have regular
>> meetings using voicechat software + a collaborative editor (usually
>> SubEthaEdit because we are on Macs, but Gobby will do fine), we write
>> in jspwiki format, ie structured, plain text (the KISS principle),
>> which is transformed by Forrest to online meeting memos (pdf, html)
>> and task lists in iCal format using the plugin described above.
>
> This is very interesting. Thanks so much for sharing a
> situation for how you use Forrest. That should encourage.

:)

> This is very timely for me. I need to help with forming a
> co-operative and they will need to conduct their first meeting
> of distributed members.
>
> I did a net search and found some of your explanations
> at divvun.no ...

Nice to know that our documentation is being read by someone:)

> will see what tips i can glean. Thanks.

You are welcome:)

One reason I'm turning this local adaption of Forrest into a plugin is  
that it needs improvements. I had hoped that the improvement process  
would benefit from feedback from the community - and this has already  
happened in the form of the suggestion from Ross about using our xml  
properties system (see the other reply in this thread). Also the  
encouragement I get from the above comments helps a lot:)

Presently the ical plugin presupposes that all tasks are summarised in  
the last section of the document. This makes it easy to parse, xml-
wise, but it has turned out to not work that well in the meetings. We  
basically have to maintain a status of each task at two places: under  
each topic we discuss, and at the end of the document.

I will try to enhance the plugin to be able to automacially extract  
and collect all tasks for the relevant person directly from the  
topics' todo lists. This will make the task summary at the end  
superfluous - it is really only a reflection of my xsl capabilities  
(and time constraints) at the time when I wrote the original code.

This enhancement will of course make the xsl code more complicated,  
but it will support a more logical meeting flow, and also encourage  
the use of the ical task lists by the team members. Up until now  
several team members have just copied the list at the end of the  
document, instead of using the ical feature. When there is no list to  
copy, they *have to* use the ical task list;)

Another enhancement I plan is to add support for explicit deadlines  
for each task. At the moment each task is given a default execution  
time of one week, ie until the next meeting, which isn't very flexible.

Finally, I would like to be able to generate some sort of stable ID,  
to make it possible to update tasks imported into calendaring apps. As  
it is now, each time an ical task list is imported, all tasks are  
added as new tasks, even though the majority of them are only updates  
(or even copies) of already existing tasks. I'll see what is possible  
within the limits of of the ical format.

Best regards,
Sjur

[Sjur Moshagen]

Den 19. aug. 2009 kl. 23.25 skrev Ross Gardler:

> 2009/8/19 David Crossley <crossley@...>:
>>> Comments on the URL or filename patterns? Other comments?
>>
>> This is exiting. That seems like a fine approach to me.
>
> I agree that it's great to see some new work here.

:)

> I don't quite agree
> that the URL patterns is a "fine approach" though. But don't worry,
> it's a small change I am going to propose and it is backward
> compatible with your current scheme.

:)

> input.xmap:
>
>      <map:match
> pattern
> ="{properties:daisy.pathPrefix}*{properties:daisy.fileExt}.xml">
>        <map:call resource="daisy-to-document">
>          <map:parameter name="docID" value="{1}"/>
>          <map:parameter name="path" value="{0}"/>
>        </map:call>
>      </map:match>
>
> forrest.properties.xml:
>
> <property name="daisy.pathPrefix" value=""/>
> ...
> <property name="daisy.fileExt" value=".daisy"/>
>
> Now the project can override these properties in its local
> forrest.properties.xml if it needs to do so, or it can leave them at
> their defaults for the same behaviour as your existing sitemap.

Thanks for the suggestion and reminder about the xml properties, Ross.  
I had completely forgotten about them, even though I used them  
extensively in the work I did on the pdf output plugin.

This will also make it easy to add other properties for more  
flexibility in other areas.

Best regards,
Sjur

[David Crossley]

Sjur Moshagen wrote:

> skrev David Crossley:
> >Sjur Moshagen wrote:
> >>General note:
> >>
> >>This is an excellent example of the flexibility and usefulness of
> >>Forrest. We (a project team geographically distributed) have regular
> >>meetings using voicechat software + a collaborative editor (usually
> >>SubEthaEdit because we are on Macs, but Gobby will do fine), we write
> >>in jspwiki format, ie structured, plain text (the KISS principle),
> >>which is transformed by Forrest to online meeting memos (pdf, html)
> >>and task lists in iCal format using the plugin described above.
> >
> >This is very interesting. Thanks so much for sharing a
> >situation for how you use Forrest. That should encourage.
>
> :)

Many thanks for adding the initial iCal output plugin Sjur.

I had a quick look and it works for me.

I did a few minor tweaks and house-keeping stuff.

There are some strange unreadable characters next to links
in the *.jspwiki sample files.

By the way, this new proposal at Apache Incubator might
be of interest.
[PROPOSAL] Apache OpenMeetings incubator for Web Conferencing
http://markmail.org/message/aahmijcb5dsjlxiv

-David

[Sjur Moshagen]

Den 30. okt. 2009 kl. 06.43 skrev David Crossley:

> Sjur Moshagen wrote:
>> skrev David Crossley:
>>> Sjur Moshagen wrote:
>>>> General note:
>>>>
>>>> This is an excellent example of the flexibility and usefulness of
>>>> Forrest. We (a project team geographically distributed) have  
>>>> regular
>>>> meetings using voicechat software + a collaborative editor (usually
>>>> SubEthaEdit because we are on Macs, but Gobby will do fine), we  
>>>> write
>>>> in jspwiki format, ie structured, plain text (the KISS principle),
>>>> which is transformed by Forrest to online meeting memos (pdf, html)
>>>> and task lists in iCal format using the plugin described above.
>>>
>>> This is very interesting. Thanks so much for sharing a
>>> situation for how you use Forrest. That should encourage.
>>
>> :)
>
> Many thanks for adding the initial iCal output plugin Sjur.

:)

> I had a quick look and it works for me.

Nice to hear.

> I did a few minor tweaks and house-keeping stuff.

I saw that, thanks a lot for cleaning the bits I didn't notice.

> There are some strange unreadable characters next to links
> in the *.jspwiki sample files.

Those are UTF-8 encoded non-breaking spaces (NBSP). The wiki parser  
has some interesting whitespace processing - in some cases spaces are  
inserted where there were none in the source (e.g. around boldface or  
italic), in some cases spaces are removed, like after URL's, which  
makes the following text run into the URL. NBSP is treated as a  
regular character, and isn't touched, making the final output look  
like intended.

We use only UTF-8, so I had forgotten to change it to Latin-1. It is  
changed now.

I know the NBSP trick is really a hack, but I haven't had time to dig  
into the wiki parser code. I'm not sure the present behaviour is  
easily fixed.

> By the way, this new proposal at Apache Incubator might
> be of interest.
> [PROPOSAL] Apache OpenMeetings incubator for Web Conferencing
> http://markmail.org/message/aahmijcb5dsjlxiv

Thanks for the pointer.

Best,
Sjur