[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

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

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.


Martin Fick wrote:

>--- Patrick Ogay <lists at basel-inside.ch> wrote:
>>I use the music recipe, which users the content
>>Sometimes I have problems to access the midi-File
>>because the access-URL 
>>ist to long, problems seem to be also browser
>>The length of this access-key seems to be dependent
>>of the size of the 
>>Is there a way that the content-key could be
>>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
>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,
>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