>>>>> "Christian" == Christian Ridderström <[EMAIL PROTECTED]> writes:
> If you'd really want to do the simple thing for a single file, then > I can explain the API for working with the wiki servers' pages. Why > the pages? Well, since .lyx is plain text, it could just be stored > directly in a wiki page, see further down. Anyway: > * To download a page source: > curl 'http://wiki.lyx.org/Group/File?action=source' > File.lyx > * To upload I don't have in my head, it's a HTTP POST and quite > easy. It get's a _little_ bit more complicated if you want to > detect that someone else has edited the document in between > (which you should!). >> But if the access method were, say, scp or webdav or something, >> then this is do-able. But, as you say, I'm not sure LyX (or, for >> that matter, anything) needs this kind of immediate visibility. > I agree. You really need to think through how and when to allow people > to access the document. > /Christian > PS. Having written the above, you could actually do the following: That sounds very interesting let me try to make some comments. > * Store the .lyx-file in a wiki page as the following "wiki markup": > (:LyX-file:) > <LyX file goes here> > (:LyX-fileend:) Precisely. > * When such a wiki page is rendered by the wiki server, it doesn't > actually have to show the LyX source. There are several options (not > exclusive): On criteria should also be to make it as possible for different users on different OS with different browsers to use it, with fiddeling some javascripts or the like. > ** Insert a [PDF] link for the (:LyX-file:)...(:LyX-fileend:). > When you click that link you get a PDF version of the LyX document. > The server can maintain a cached copy of the PDF to speed things up. That is a solution seems most intuitive to me. > ** Use a thumbnail image of a page from the LyX document as link text. > Clicking this image could then e.g. show the PDF. > ** Insert a [Source] link, clicking it returns the .lyx-file > ** Insert a special [LyX edit] link, clicking on it launches the process > described above. You'd probably have to do something with your browser > to get this to work. That looks like the second best solution > A lot of this is quite easy to implement, but you will also have a lot > of disadvantages (external image files, lot's of people may edit it > etc) Could you try it on one server? Or is this too much to ask. Frankly that looks to me a very GOOD starting point. I don't think one should start with a perfect solution. In my experience collaborative editing, would usually consist of - up to five collaborates - a document which is around 50 pages So if we leave out the question of pictures for the moment and concentrate on the simultaneous editing, then I would say at most people would edit _different_ section at the same time and may they would not do this very often. So resolving editing conflicts might be important for *huge* projects with a lot of authors, like wikipedia or software projects, but are in my opinion not utmost important for scientific collaboration say in Mathematics. Thanks very much Uwe Brauer
