wondering if we should call this sort of thing "formats" instead of file types.
annoying close to forms/formatting. how about "file format" ?
--John Abbe.....Wed Feb 16 13:00:32 -0800 2011
there it is :)
--Ethan McCutchen.....Wed Feb 16 13:24:56 -0800 2011
leave links double-bracketed, or remove?
or maybe if "read more about wombats" here is a link:
Kangaroos have also been known to befriend wombats (read more about wombats).
...you get:
Kangaroos also hate wombats (read more about wombats [1]).
...and then at the end of the document there's a list of links (they're autonumbered):
[1] |URL|
--John Abbe.....Mon Feb 21 11:37:03 -0800 2011
dramatically easier to render links as inline urls, just like images: Kangaroos also hate wombats [http://....] I've also seen that in a bunch of places (esp emails)
Standard conversion is to ignore pretty much all other markup. Agree we might eventually do other formats later.
Re current .txt, in the proposed web api, you could do this with /name.txt?raw I'm figuring that's good enough, no?
--Ethan McCutchen.....Mon Mar 07 17:03:25 -0800 2011
Re markup, updated solution to ignore bold/italic, made some other changes/suggestions.
Re /name.txt?raw -- I guess that works. So, we're saying that naming a view in the URL overrides any view implicit in the file format? In this case, you get the MIME type expected for a .txt file, but the raw content, with markup and without inclusions being rendered.
And /name.pdf?raw would give the MIME type for a .pdf, and the raw content as a PDF file?
Would be nice if this works, and can't think why it won't. This way we don't have to come up with a unique file ending for raw. You can just get it in whatever file type you want.
--John Abbe.....Tue Mar 08 01:04:19 -0800 2011
yup, that's what I'm figuring.
--Ethan McCutchen.....Tue Mar 08 09:05:00 -0800 2011
we could also consider the case of making a default *format* associated with a view if only a view is specified. eg, /name?raw would implicitly give text. I think that may be contemplating things unnecessarily (and potentially confusingly), but throwing it out there.
--Ethan McCutchen.....Tue Mar 08 09:07:01 -0800 2011
Gut response is wanting to stick with .html as default - you got a use case where something else is compelling? (Where the file ending isn't a more friendly URL, e.g., /name.pdf vs. /name?pdf )
--John Abbe.....Tue Mar 08 15:02:39 -0800 2011
we'd never do /name?pdf, that would be using a format as a view. I could clarify, but I don't really like the idea that much anyway, so unless you really want more explanation, I'm happy to drop it.
--Ethan McCutchen.....Tue Mar 08 17:42:35 -0800 2011
I think we're awfully close on this.
--Ethan McCutchen.....2013-03-21 16:23:51 +0000
Wanna tag it with a release?
--John Abbe.....2013-03-21 22:28:39 +0000
no, not a priority, and the work that was done was done a long time ago.
--Ethan McCutchen.....2013-03-22 03:22:34 +0000
Maybe we should tag it to a release, just not a really soon one, or tolerate moving it back. It does seem like this just needs a little work to complete it.
just looked at http://wagn.org/Tickets_By_Status.txt
Not good. perhaps that can be a test case?