Hi Gary.

I've run the */st* tests on my account and except for the one above they 
all are doing well.


Reading path ggsm://log/mylog.txt<br/>Warning: fopen(ggslog://mylog.txt): 
failed to open stream: "garyamort\github_io\stream\syslog::stream_open" call 
failed in 
/base/data/home/apps/s~woodzu123/2.372788013017868220/gae/libraries/garyamort/github_io/stream/morpher.php
 on line 162Warning: file_get_contents(ggsm://log/mylog.txt): failed to open 
stream: "garyamort\github_io\stream\morpher::stream_open" call failed in 
/base/data/home/apps/s~woodzu123/2.372788013017868220/gae/demo/streamtest.php 
on line 156

I've got both the 'log' folder as well as the mylog.txt file in it. Both 
created manually and assigned "Owner" permissions for the GAE application 
in *log/mylog.txt*.

One suggestion I'd have is to use something more obvious for the schema 
names, maybe:
gs+sm:// or gs+joomla:// for the default wrapper
gs+log:// for the log wrapper

According to RFC 1738 the following characters are allowed:

- letters "a"--"z"
- digits
- plus ("+")
- period (".")
- hyphen ("-")


How are you getting on with adding this to the cms? Let me know if I can 
test anything for you.

And what are you thoughts on including media/images folders in the wrapper?
I was thinking of adding an option to the installer (the GAE one) to copy 
both folders over to the Google Storage.

The images folder is used to store all dynamic data for Joomla such as 
images for articles and other components, so it should be fine as is but 
all of the default contents in media folder are core assets. Unfortunatelly 
some 3rd party extensions by default use media to store all dynamic data in 
it
such as forum attachments in Kunena, some K2 files, avatars in 
CommunityBuilder and who knows what else.

One idea is to copy both images and media to the Storage, rewrite the urls 
and use a post-deployment script to update/override them. Less hassle.

The other idea is to keep a list of folders which should be kept on the 
Storage. Example:
/cache
/tmp
/media/kunena
/media/k2

Or even two lists eg. the default one that comes with the joomla-gae repo 
and a custom one, user defined, gitignored file.
This way we can have a file for known folders used dynamically by 
extensions and dev/admins would have an option to add custom folders they 
need write access to.


On Tuesday, December 31, 2013 10:47:10 AM UTC, Gary Mort wrote:
>
> While working on getting Joomla to work without core file hacks on App 
> Engine, I ran into some trouble where it attempts to build paths based on 
> the path the index.php file is in.
>
> Specifically, it tries to send media files[images] to JPATH_BASE.'/media', 
> cache files to JPATH_BASE.'/cache', and some log files to JPATH_BASE.'/log',
>
> Rather then running with all that code imported from google cloud storage, 
> I instead setup a stream morpher/wrapper.  By default it can self register 
> itself to handle all streams beginning with ggsm:// and it can be assigned 
> a set of simple pattern matching rules to access a different stream.
>
> IE for any file that begins with ggsm://log/$pathname it will instead 
> access ggslog://$pathname 
> For anything going to ggsm://cache/$pathname it will instead use 
> gggs://bucketname/$pathname
>
> Where ggslog is the protocol string assigned to a simple syslog wrapper so 
> all data sent to a log file will instead be routed to syslog and use the 
> google logging api.
>
> By the same token, gggs is routed to my own custom copy of the google 
> cloud storage stream handler - the only changes there being that instead of 
> a final class, my stream class is a public class that can be extended for 
> other functionality - and I added append mode support for opening 
> files[which I discovered on App Engine requires using the 
> GoogleStorageClient classes in order to retrieve the data to append - you 
> can't open a read stream to a path if you are in the middle of opening a 
> write stream].
>  
> I've dumped the classes into a github repo if anyone else needs them:
> https://github.com/garyamort/Stream-Morpher
>
> One thing I'd like to do is expand the Google Cloud Storage class to use 
> APC caching[as long as it is available] in addition to memcached.  I am 
> thinking that for APC caching I would limit it to only 1 second - the files 
> I am using don't generally change more quickly then once a second, and if 
> they do it's ok when multiple instances are running for seperate instances 
> to have stale data.  Since a single user will generally be routed to the 
> same instance, anything cached in APC for them will be available there 
> immediately - while memcached can provide up to 15 minutes of caching as a 
> fallback, and if those fail the slower load from GS can be done.
>
> Also it is relatively simple to support file locking and such via GS 
> metadata.  Since each request has a unique request id assigned to it, it's 
> easy to store GS metadata with the request id and time of file lock.  The 
> lock function can limit honoring of locks to a small timeframe[say 5 
> seconds] and if the lock was performed more then 5 seconds ago - there are 
> a number of special metadata update parameters that can be set so that it 
> will only update if the current data matches the previous data.
>
> IE:  lockRequestId=1,lockedAt=12/12/12 12:12:12
>
> The second request could try to update the meta data to:
> lockRequestId=2, lockedAt=12/12/12 12:22/01 only if 
> lockRequestId=1,lockedAt=12/12/12 12:12:12
>
> So with competing requests attempting file locks, only the first one gets 
> the lock - the second will fail and have to wait again.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to