[pmwiki-users] Content/Music - extremly long access-path via URL
Patrick Ogay
lists at basel-inside.ch
Wed Feb 13 01:10:22 CST 2008
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 <lists at basel-inside.ch> 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
>
>
>
>
More information about the pmwiki-users
mailing list