[pmwiki-users] Content/Music - extremly long access-path via URL

Martin Fick mogulguy at yahoo.com
Tue Feb 12 11:56:22 CST 2008

--- 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

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