Thanks very much, Martin, for your quick reply. I personally didn't have problemes, using Mozilla 1.78 and Firefox 2x (Win2k and Linux). But "Exsultate justi" definitely made problems (in Moz) and I changed it to (:music:) again.
I had some feedback from "typical end users" (which I can't reach at the moment), who mailed me the **midi links didn't work**. Now I have to find out, whether it's an URL-problem (particularly in mac environment). There is a platform and pmwiki test user (readonly) tunes/ tunes http://www.wprj.net/chor/index.php/Tunes/ViadanaExsultateJusti *** I'm also investigating for further developement. In a further step, I like to generate mp3 for some purposes (burn a CD for my chorus, which now is complicated) I hope I can add pre- (abcpp) and postprocessing (mp3 generation) in the script. For some usage (web playlist), it would be nice anyway to have "nice url-names" for the tunes. ** thanks very much for your interesst Patrick P.S. I will open the site, when it's finished, there is also a ABC documentation part. There is a lack on german documentation. May be some ABC-peoples are interested in a docu and collection platform. Patrick Martin Fick wrote: >--- Patrick Ogay <[EMAIL PROTECTED]> wrote: > > >>I use the music recipe, which users the content >>recipe. >>Sometimes I have problems to access the midi-File >>because the access-URL >>ist to long, problems seem to be also browser >>dependent. >>The length of this access-key seems to be dependent >>of the size of the >>music-track. >> >>Is there a way that the content-key could be >>changed? >>May be a hash could be used instead. >> >> > >Hmm, part of the design idea of the content recipe was >to actually avoid most of these long URLs through the >use of "content paths" (similar to your hash idea) >which are used to reference the large data sections >embedded in the wiki pages. But, this obviously >requires that this data already be saved in the wiki >page and so this does not work for previews. > >For previews, with every viewing this temporary data >must be resent to the server, this is probably where >you are seeing the really long URLS? If this is not >the case, please let me know. If this is the case, I >am not sure that I have any good solutions to reduce >this. The only methods that I can think of probably >have other drawbacks that the long URL method does not >have. But, I would be willing to add those as >configuration options to the Content recipe for those >who prefer them. This would make the recipe more >flexible as an API for developers to use knowing that >they do not have to switch APIs just to switch >implementations. > >Some of the methods that I can think of, session data, > cookie data, and perhaps some javascript tricks to >post the data instead. Session data would essentially >mean temporary server files which take up space and >must be cleaned up on a time basis (php easily takes >care of this). While these risk expiring while users >are editing, data will not be lost, the editors could >simply repost the page. Cookie data has a few gotchas >to work out so that multi tab editing works well >without pages interfering with each other and may also >have size restrictions? The javascript tricks will >obviously restrict editing to certain clients. > >First, please let me know if this problem is indeed a >preview only problem? If so, and you would like to >try one of the other 3 methods that I mentioned above, >let me know which one and I will try to implement it, > >-Martin > >P.S. I cannot view anything on your site because it >is password protected. > > > > > ____________________________________________________________________________________ >Be a better friend, newshound, and >know-it-all with Yahoo! Mobile. Try it now. >http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ > > > > _______________________________________________ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users