Ape Gurus,

1.  I love APE, it is amazing,
2.  I'm working on a project to correct some shoddy popup behavior,
and I'd love to use APE to make things more stable and scalable.  (did
I mention that I love ape?)

For all you airheads out there, all my code runs in the unrestricted
sandbox.  That way it has access to the systray and can pop up
notifications.  It uses mostly XMLHttpRequests to interact with
external webservices running on servers here.

Since I can't load dynamic code and remain in the unrestricted
sandbox, I can't really use the APE JS libraries.
It looks like it is leveraging iframes rather than XMLHttpRequests.
(When air opens up an iframe to load code not on the domain, it forces
it to run in the restricted sandbox.)


This caused me to write up some quick XMLHttpRequests to interact with
the APE daemon.

I wrote:

Login - works fine
Channel Join - works fine (I use channels as a way to identify my
clients in our network.  The client has a session ID from its normal
login, and I just have it join a channel of the same name, so that the
server can locate him by sending to his channel.)

Then I have my problem.  The APE protocol depends on the client to
"CHECK" every 20 seconds or so.  (Then the server closes the previous
"CHECK", that way there is a nice overlap and no lapse in
connectivity.)

Well, adobe air forbids the use of anything on a timer as a security
hole.  i.e. no setTimeout or setInterval.

So I think my questions are:

1.  Has anyone ever attempted to make APE run inside an adobe air
application?
2.  Has anyone ever made APE run via XMLHttpRequest?
3.  Did any of this make sense? or can I provide more information to
help?
4.  Is there a server side setting which would cause APE to just
respond after 20 seconds, so I can grab that and re-CHECK the
connection?  (i.e. having the timer exist via the server...)

oh, FYI, currently we manage our push messages via a custom developed
java application that pushes via a long poll XMLHttpRequest:

1.  Client XMLHttpRequests
2.  Server sits on the response for a set number of seconds, or until
a message is ready to pop.  (it either sends a keep-alive or an actual
popup message)
3.  Client receives either the keep-alive message or a popup message
causing step 4:
4.  Client re requests.

It just doesn't seem to work just right, and I think APE is a better
way to go.

-- 
You received this message because you are subscribed to the Google
Groups "APE Project" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/ape-project?hl=en
---
APE Project (Ajax Push Engine)
Official website : http://www.ape-project.org/
Git Hub : http://github.com/APE-Project/

Reply via email to