Thanks! UI is based on WebKit. Pandoc's license is GPL so I don't think I'll be embedding it.
As for Markdown parts – Texts 0.3 supports only blocks of plain text, headers (setext), unordered lists, code and math blocks (pandoc extension) and intervals of bold, italic, code, math and links. Only simple links (<URL>) are supported for now.
The idea is to expand syntax gradually, focusing on simplicity of user interaction. There are too many flavours of Markdown out there and several ways of writing the same structure in Gruber's Markdown is not a good thing, IMHO. There is no real need to decide between _italic_ and italic.
The object model of the text that is implemented is as simple as possible: blocks and spans (without nested spans). It shouldn't be a problem to implement essential parts of AsciiDoc and other plain text markups. When these formats get into the product depends on the interest from users. I'm planning to expose an API to allow implementation of formats as plugins.
You could "package" it by creating a separate component that's simply a pandoc process and have the two parts talk via one of the various serialization protocols on hackage (after all, web browsers need not be gpl just because the web server is). Itd be a shame to have to redo stuff that pandoc already does very nicely.
I am almost sure that this is covered by the gpl. Servers source code is protected because it is not distributed to the end user, not because there is some kind of a bridge between gpl code & your code.
Comments
Thanks! UI is based on WebKit. Pandoc's license is GPL so I don't think I'll be embedding it.
As for Markdown parts – Texts 0.3 supports only blocks of plain text, headers (setext), unordered lists, code and math blocks (pandoc extension) and intervals of bold, italic, code, math and links. Only simple links (<URL>) are supported for now.
The idea is to expand syntax gradually, focusing on simplicity of user interaction. There are too many flavours of Markdown out there and several ways of writing the same structure in Gruber's Markdown is not a good thing, IMHO. There is no real need to decide between _italic_ and italic.
The object model of the text that is implemented is as simple as possible: blocks and spans (without nested spans). It shouldn't be a problem to implement essential parts of AsciiDoc and other plain text markups. When these formats get into the product depends on the interest from users. I'm planning to expose an API to allow implementation of formats as plugins.
You could "package" it by creating a separate component that's simply a pandoc process and have the two parts talk via one of the various serialization protocols on hackage (after all, web browsers need not be gpl just because the web server is). Itd be a shame to have to redo stuff that pandoc already does very nicely.
I am almost sure that this is covered by the gpl. Servers source code is protected because it is not distributed to the end user, not because there is some kind of a bridge between gpl code & your code.
One way to include pandoc support would be to expose it via a webservice on your server.