ActionScript library available using REST-version?

[David_Welch]

I need to access ALCS services via Flex/ActionScript, but, cannot use remote objects, i.e. all REST calls.  Basically, I need the functionality of AFCS.java (which uses http services) in ActionScript.  I know there is an open source version of the AFCS.java, so, I'm looking for something along these lines, except written in AS3.

I'll be using the code in a Flex application, just can't use remoting.

Anyone know if this has already been done or, if not, what might be the best approach?

Thanks!

[Former Community Member]

Hi there,

Unfortunately, I don't think you can make this work - we don't provide a

way to have the server push messages to you via REST. What's the reason for

this requirement?

FWIW, we don't use remote object in LCCS - we use simple netconnection

RPCs.

nigel

[David_Welch]

Hi Nigel:

Thanks for the quick response.  The reason I need this is the Flex SDK I must use is a very much whittled down version, only supports a limited NetConnection api.  Primarily, Netconnection.call() is not supported, which rules out most of the standard delivered AFCS api, I believe.  The Flex SDK I must use only provides AS3 HttpService and URLLoader for accessing remote data.  The SDK is used in a tool called OpenPlug (you are probably familiar with it), which I'm attempting to use to write iPhone and Android interfaces into my AFCS-based application.

I don't need server push from AFCS, but, I do need to inspect the room objects (i.e. getRoomInfo() and getNodes() in AFCS.java), and, it would be GREAT if I could actually publish objects to AFCS (although I suspect this isn't possible with HttpService or URLLoader).

In a quick proof of concept I've been able to connect and query (by partially rewriting AFCS.java in ActionScript), but, only using the authenticated method.  Still having problems using guest login (using the shared secret) though.

Any help GREATLY appreciated.

Regards,

David

[Former Community Member]

Hi David,

What you're asking for doesn't exist today. But, for the next release, we

are going to open up APIs so that you will be able to publish via HTTP. This

is primarily so that a server you host can contact our server - you need to

login with developer credentials, so it's not something we'd recommend for

use straight from your client, but you could have your Flex client contact

your server over HTTP, then have your server publish to us (logged in as the

developer), also via HTTP. What's more, your server will be able to

subscribe to us over HTTP as well (your client definitely will not).

It's coming soon (think weeks, not months)!

nigel

[David_Welch]

Nigel:

A primary advantage I see in using AFCS (and, I'm sure of many others see this also) is that it's a cloud, and, you don't have to use your own server to act as an "in-between" client just to "relay" messages.  I'm not sure why some of my clients (i.e. mobile devices) shouldn't be able to subscribe directly.  Can you give me some insight on this ?

Also, the Connect Pro mobile application does not require an "in-between" client.  So, why is AFCS different?

Regarding the usage of the developer account, I really don't understand the reasoning for a limitation on using the account shared secret to access rooms.  If the developer is okay with using this approach, why wouldn't this be allowed?  There are tools provided that allow monitoring of your account, and, if there is abuse (have you seen frequent abuse this way?), an administrator could address it.  After all, they're paying the bill and would be inclined to monitor it.  I think many AFCS applications are not "generally" available to the public, and are corporate-based, so, I'm not sure what would motivate abuse.  Have you seen widespread abuse in this way?

Great to hear that you're close to providing http service access, I'd be happy to be a beta tester.

Thanks again for your help.. keep up the great work!

Regards,

David

[Raff_]

David,

I am not sure I understand your use case. You say you have an ActionScript client (Flash/Flex client) but you can't use the standard LCCS messaging ?

If you have a fixed number of rooms (i.e. you don't need to do any server-side room management) you can have your (Flash/Flex/ActionScript) clients connect to the room with no intermiediary. That's how the LCCS messaging works (and that's how the ConnectPro mobile application, that is a Flex application compiled natively for the iPhone, works).

The purpose of the server-side APIs is mainly for account / room management. And we are adding new APIs that will allow a server-side application to publish to a room and to receive event notification, again, mainly for account / room management (so that you can do, for example, your own room monitoring, or force clients to leave the room, or even participate in a room as a "robot" - non-human participant and do things like modify messages on the fly, trigger server-side operations when a particular event occur or a particular message is received, or do things like an automated card dealer for card games).

And, yes, you could potentially use these API from a client, but for most of them it doesn't make sense. They require "account owner" permission, that defeats the permission scheme available in LCCS, and you can't really "receive" any event from a client, unless you can address the client (i.e. since we'll send events as HTTP POST messages, you'll need a web server in order to receive a message).

[Former Community Member]

Hi David,

FWIW, ConnectPro works by having the client connect via RTMP =).

Essentially, you're kind of making an argument that you want it both ways.

You want us to reimplement what we've done for RTMP over HTTP, but this just

isn't practical for us in a few ways - mostly, we've built our user/security

model in the RTMP-connected cases, and are leery of porting it to HTTP (it's

a lot of work, and we haven't really had demand for it). So the new HTTP

server APIs we are about to release have a really simple user model - you're

either the developer, or not able to use them. If we hear tons of desire to

go further, we can look into it, but right now it's not really on the radar.

A primary advantage I see in using AFCS (and, I'm sure of many others see this

also) is that it's a cloud, and, you shouldn't have to use your own server to

act as an "in-between" client just to "relay" messages.  I'm not sure why some

of my clients (i.e. a mobile devices) shouldn't be able to subscribe

directly.  Can you give me some insight on this position?

The only way a client can subscribe over HTTP is via long-polling

("comet-style") connections. We've made the explicit choice not to support

this, since it's hard to scale, and we'd rather focus on optimizing the core

value proposition, which is via RTMP. A server can subscribe by using

something like "webhooks", which is much easier for us to support.

As to your security question, certainly, there's nothing stopping you from

building your app this way, but you'd be a bit insane to do so - any hacker

worth his salt would have your dev credentials within minutes, and could do

anything he wants to your account. And nope, we haven't seen this kind of

abuse, because people don't build their apps this way =). Most of the apps

we see are public-facing, since the cloud and core functionality we offer is

most valuable when exposed to consumers (see Rosetta Stone, for example).

hope this clarifies - if you can give us a little more context from your

side about what you're trying to accomplish (ie, on which client platform?),

we might have more reason to support this in the future.

nigel

[David_Welch]

@Raff/Nigel:

Not sure if you are aware how the api I'm using works, but, as I mentioned earlier it's a platform from OpenPlug, and, it's definitely a little unusual.  Basically, they have a Flex/Air generator for mobile apps that, in the final build, generates native code for a mobile platform, sort of similar to the way the "Export to iPhone" works in Flash CS5.  So, for iPhone, you can build an app using their limited Flex SDK, but, when it actually builds, they map all the objects/code to native objects/code.  But, the OpenPlug Api doesn't support RTMP or remoting in any way, only http service.  So, this is why I'm looking only to use http service in a Flex client.  You develop using Flex, but, the end result is NOT a Flex client, it's a native (i.e. on iPhone xcode) client.

@Nigel:

I certainly understand why you've approached everything from the currently available Flex client, using RTMP, etc.  And, I've already used this extensively to write my primary AIR/Flex clients for my AFCS application (and I love using this approach!).  I'm just trying to see if I can fit this OpenPlug approach with AFCS.  I know it's a reach, and, I'll probably bag it and just wait for Flash CS5 to build the ActionScript client iPhone version (and try to learn Flash, ugh!).  Or, wait even longer for Slider.

But, I'm still not clear how the hack is so easy for authenticated clients, maybe I need to spend some more time with the server api.  Aren't the requests sent using https?