Content-Talk

Summary: Talk page for Content.

Users: (View ? / Edit)

This space is for User-contributed commentary and notes. Please include your name and a date along with your comment.

Comments

Potential Future Changes/Enhancements

I am fixing the recipe to properly handle multiple paths to the same type. Currently, the first one defined is chosen. (in progress)
I am expanding the directive type= and list= option processing to understand cpath expressions instead of just simple types. (in progress)

Cpath Expressions

A Cpath Expression is a cpath pattern matching markup which can match sets of types. For example: text simply describes the type text, but text/ps describes both the text type and the ps type that can be derived from a text type.

Cpath expressions can also use wildcards to express an even greater set of types. For example: ../gif denotes all the types which can yield a gif type, this includes types which must first be converted to other types. This may include all the types in the following cpath: text/ps/ppm/gif. Wildcards may also be used between and after types, so text..gif denotes all the types from text to gif. Similarly, ps.. denotes all the types from ps onwards.

Lastly, cpath expressions may include parenthesized assertions. These assertions are required for a cpath match, but they are not enough to create a match by themselves. For example the cpath expression (ps..)gif will match any gif type if and only if it was created from a ps type at some point.

I may implement cpath signing (similar to preview signing) to allow author written cpaths only. This may be a security risk reduction, especially once converters can receive arguments from URLs. The more I think about this one, the more I don't like it. It seems to go against much of the primary motivations of writting this recipe: easy/simple/logical URLs. I also tink that little is to gain from this restriction unless it were tied to the source which now makes URLs changeable when the source changes, exactly what we don't want. I think that I am going to scratch this idea.
It might make sense to have a default source for each page. With a default source, a pagelist could easily reference default content from a series of pages. The default source could be marked so with a default= option to its directive defaulting to the first source on a page if no content directive contains a default= option. The default source could then be referenced by leaving the name blank but including the ''~'' like this: {$/../gif~}. What do we do with multipaths then? If I want the default gif from and abcpp source, did it come via abcm or abctab?
I may add some mechanism for output type ordering. Currently things are ordered according to conversion order except that embedded and inline content is put first. Someone mentioned that perhaps they would like the links displayed before the images. Maybe something like: order=embed,links,inline?
I would like to improve caching control. I envision the ability to turn off caching for certain types. This would be particularly useful for types which are not displayed but are used as intermediate types for conversions (ppm in the music recipe). I am not sure if there is a good way to automate this? Certainly it could be a per type configuration option. Is this something that an author would ever want to control? i.e.cache=-wav
I would make sense to also add a web converter which could take a URL and cache the output of the web page. A post version and perhaps even a web service version might also make sense. With a web converter it would be possible for people to use converters hosted by others without imposing much of a load on the host site since the output would be cached locally! This would also eliminate reader dependence on the host site.
A proxy web converter could be specifically designed to work with the content recipe hosted elsewhere and could eliminate the necessity for custom glue code! To enhance proxy web converters it may make sense to build smart mechanisms which allow the content recipe to know that it can perform conversions through the proxy from a source through a transitional type to an output type in one stage. This would allow hosts to use transitional types for which it would not trust external sources. (experimenting with)
Previews could use some work to deal with extremely long previews:
- Workarounds for long previews URLS:
  1. session data would essentially mean temporary server files which take up space and must be cleaned up on a time basis (php/apache easily takes care of this though). While these risk expiring while users are editing, data will not be lost, the editors could simply repost the page.
  2. cookie data has a few gotchas to work out so that multi tab editing works well without pages interfering with each other and cookies may also have size restrictions?
  3. javascript tricks to post the data instead. These tricks will obviously restrict editing to certain clients.
- Currently, caching during previews uses a temp dir which is deleted as soon as the page is generated
  1. sessions could improve caching further which could also solve long URL problems above

Talk page for the Content recipe (users ?).