Spod usage..

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Spod usage..

sledorze
Just think as speaking..

while looking at nodejs code of the facebook app; I saw this:


session.restCall('fql.query', {
  query: 'SELECT uid, name, is_app_user, pic_square FROM user WHERE uid in (SELECT uid2 FROM friend WHERE uid1 = me()) AND is_app_user = 1',
  format: 'json'
})(function(result) {
...

I am wondering, as I dunno facebook well, if the query could not be deduced from some part of code involved into SPod currently (provided that we define a facebook model).

Have I missed something about it? (do not plan to make it right now, but would like to know what I should put beside it on my *long* ideas list)

Thanks,
Stephane



Reply | Threaded
Open this post in threaded view
|

Re: Spod usage..

Juraj Kirchheim
They way SPOD is right now, there's one key aspect that makes it
unusable on node.js: It's based on synchronous queries.
It shouldn't be too much work to create an async SPOD layer to work
with node.js though.
Without looking at the code, I suppose what you actually need to do is
to replace most of Object's and Manager's methods to be asynchronous.
The rest should hopefully work as is.

greetz
back2dos

On Thu, Oct 13, 2011 at 2:33 PM, sledorze <[hidden email]> wrote:

> Just think as speaking..
>
> while looking at nodejs code of the facebook app; I saw this:
>
>
> session.restCall('fql.query', {
>  query: 'SELECT uid, name, is_app_user, pic_square FROM user WHERE uid in
> (SELECT uid2 FROM friend WHERE uid1 = me()) AND is_app_user = 1',
>  format: 'json'
> })(function(result) {
> ...
>
> I am wondering, as I dunno facebook well, if the query could not be deduced
> from some part of code involved into SPod currently (provided that we define
> a facebook model).
>
> Have I missed something about it? (do not plan to make it right now, but
> would like to know what I should put beside it on my *long* ideas list)
>
> Thanks,
> Stephane
>
>
>
>
>
> --
> View this message in context: http://haxe.1354130.n2.nabble.com/Spod-usage-tp6888731p6888731.html
> Sent from the Haxe mailing list archive at Nabble.com.
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Spod usage..

sledorze
Didn't realized it was a blocking solution.
That's said, I've never used an haxe backed server until very recently with my nodejs experiments.

however I can imagine that making it async would change the API, either by bringing a lot of callbacks over the place or more elegantly if some continuation support is integrated in haxe in some way (I recall Nicolas was talking about it in one of his blog post about nodeJs).

So I may assume the refactor would be more involving than just some low level methods.

Stephane
Reply | Threaded
Open this post in threaded view
|

Re: Spod usage..

Juraj Kirchheim
> So I may assume the refactor would be more involving than just some low
> level methods.
>
> Stephane

Well, actually not that much. All the code building the SQL queries
and building objects from result sets is entirely reusable.
The real difference is, that the ultimate cnx.request calls in the
manager are blocking and need to be replaced (and granted cnx.quote,
but I suppose that could be implemented in haXe).
So getting something up and running should work quickly. Of course for
a clean solution, there should be a partition of Manager into the
reusable SQL-mangling part and the part actually executing the queries
and evaluating the results.

--
haXe - an open source web programming language
http://haxe.org