Neko server instead of AMFPHP/Fluorine gateway

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

Neko server instead of AMFPHP/Fluorine gateway

sventunus
Hi guys,

I've been traditionally always using AMFPHP or Fluorine to do remoting with Flash.
Now for my next project I finally want to take the leap and write the whole shizzle in haXe (compiling the client to a player 10 SWF).

Reading this page: http://haxe.org/doc/remoting/client_server explains quite well how to connect from Flash to Neko, but I have  questions left:

1. The "Server" class adds itself to a context to be available for clients. If I have multiple server classes I want to be able to access from the Flash client, would it be enough to keep Server.hx as it is and just add other classes to the context?
e.g.:
ctx.addObject("BitmapOperations",new BitmapOperations());
ctx.addObject("VideoOperations",new VideoOperations());
etc...

2. The consuming method in the example, static function display(v), doesn't specify a type for what is to be displayed. If a call to foo would return for example a User.hx SPOD-object, will the return value effectively be an instance of User.hx?

Thanks for your advice!
Sven
I'm a haXe target!
Reply | Threaded
Open this post in threaded view
|

Re: Neko server instead of AMFPHP/Fluorine gateway

Simon Krajewski
Am 30.05.2011 16:55, schrieb sventunus:
> 1. The "Server" class adds itself to a context to be available for clients.
> If I have multiple server classes I want to be able to access from the Flash
> client, would it be enough to keep Server.hx as it is and just add other
> classes to the context?
> e.g.:
> ctx.addObject("BitmapOperations",new BitmapOperations());
> ctx.addObject("VideoOperations",new VideoOperations());
> etc...

Yes, that's the idea. The clients will be able to use

cnx.BitmapOperations.yourMethod();
cnx.VideoOperations.yourMethod();

>
> 2. The consuming method in the example, static function display(v), doesn't
> specify a type for what is to be displayed. If a call to foo would return
> for example a User.hx SPOD-object, will the return value effectively be an
> instance of User.hx?

The haxe remoting mechanism uses serialization in order to pass data
between different execution environments. If a server-side method
returns a user-defined object like your User, it is essentially
serialized to a string (something like "o:your.package.UserO") which the
receiving end can unserialize back to an object. Note that:

1. The receiving side must know the definition of the object, that is
User.hx or a compatible variant must be imported on both sides.
2. Two consecutive calls will return two different instances of the
object, i.e. the unserializer creates a new instance every time.

On a related note, your may want to check out [1] as an example of how
proxies can be used to retain type safety while remoting (though I'm not
sure if there are official macro versions of the magic proxy classes yet).

Regards
Simon

[1] http://haxe.org/doc/flash/chat


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

Re: Neko server instead of AMFPHP/Fluorine gateway

sventunus
Vielen Dank für die Klärung Simon! :-)

It makes sense that serialization/deserialization takes place when using remoting, but I'm glad that you pointed this out.
My initial thought whas that if you're using haXe on the client side as well as on the server side, no ser/deser would happen since it "stays in the family".
But that is of course no longer true if the client has been compiled to run in the Flash Player, and not on Neko.

So the paragraph on object cache in the SPOD documentation (http://haxe.org/doc/neko/spod) is not valid when using remoting I guess?
If I call a service method to return an object and save that object to a variable, then call the same service method and save the result to another variable, and then update one of both variables, the other one won't be changed as well?

Kind regards,
Sven


On Mon, May 30, 2011 at 5:44 PM, Simon Krajewski <[hidden email]> wrote:
Am 30.05.2011 16:55, schrieb sventunus:

1. The "Server" class adds itself to a context to be available for clients.
If I have multiple server classes I want to be able to access from the Flash
client, would it be enough to keep Server.hx as it is and just add other
classes to the context?
e.g.:
ctx.addObject("BitmapOperations",new BitmapOperations());
ctx.addObject("VideoOperations",new VideoOperations());
etc...

Yes, that's the idea. The clients will be able to use

cnx.BitmapOperations.yourMethod();
cnx.VideoOperations.yourMethod();



2. The consuming method in the example, static function display(v), doesn't
specify a type for what is to be displayed. If a call to foo would return
for example a User.hx SPOD-object, will the return value effectively be an
instance of User.hx?

The haxe remoting mechanism uses serialization in order to pass data between different execution environments. If a server-side method returns a user-defined object like your User, it is essentially serialized to a string (something like "o:your.package.UserO") which the receiving end can unserialize back to an object. Note that:

1. The receiving side must know the definition of the object, that is User.hx or a compatible variant must be imported on both sides.
2. Two consecutive calls will return two different instances of the object, i.e. the unserializer creates a new instance every time.

On a related note, your may want to check out [1] as an example of how proxies can be used to retain type safety while remoting (though I'm not sure if there are official macro versions of the magic proxy classes yet).

Regards
Simon

[1] http://haxe.org/doc/flash/chat



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


--
haXe - an open source web programming language
http://haxe.org
I'm a haXe target!
Reply | Threaded
Open this post in threaded view
|

Re: Neko server instead of AMFPHP/Fluorine gateway

Simon Krajewski
Am 30.05.2011 20:08, schrieb Sven Dens:

> Vielen Dank für die Klärung Simon! :-)
>
> It makes sense that serialization/deserialization takes place when using
> remoting, but I'm glad that you pointed this out.
> My initial thought whas that if you're using haXe on the client side as
> well as on the server side, no ser/deser would happen since it "stays in
> the family".
> But that is of course no longer true if the client has been compiled to
> run in the Flash Player, and not on Neko.
>
> So the paragraph on object cache in the SPOD documentation
> (http://haxe.org/doc/neko/spod) is not valid when using remoting I guess?
> If I call a service method to return an object and save that object to a
> variable, then call the same service method and save the result to
> another variable, and then update one of both variables, the other one
> won't be changed as well?

I never used SPOD, but remoting SPOD objects (which subclass
neko.db.Object) to flash platform sounds rather interesting [1]. Even if
you manage to pull it off (say by using #if neko extends neko.db.Object
#end on your objects), my guess is that your assumption is correct and
you end up with inconsistent object states after the unserializer
created two different SPOD instances.

Regards
Simon

[1] Quite possibly the kind of interesting that makes you spend a few
hours trying to figure out a way to handle it before realizing it was a
stupid idea to begin with.



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

Re: Neko server instead of AMFPHP/Fluorine gateway

sventunus
Do I smell a little sarcasm in your last reply, Simon?

I'm just trying to understand why it would be a stupid idea to use SPOD/Neko on the server side to remote to Flash?
The idea of using Neko instead of AMFPHP is that Neko would be a lot faster, and since client/server using haXe is perfectly possible (http://haxe.org/doc/remoting/client_server), and haXe client code can target the Flash Player, why would it be a stupid idea to compile the server to Neko using SPOD and the client to Flash?

How would you implement a haXe Flash client and "a" haXe server then?
I mean, if not compiling the server to Neko, how would you use haXe remoting in combination with Flash?
Would you code the server to compile to JS and return data in JSON-format, then read that data on the client side?
Surely you would not write haXe code to target PHP to create AMFHP-services, would you?

Would love for you to explain yourself a bit more after that last answer.
And if anyone else has some tips for me, please share them too! :-)

Thanks!

Sven


On Mon, May 30, 2011 at 10:25 PM, Simon Krajewski <[hidden email]> wrote:
Am 30.05.2011 20:08, schrieb Sven Dens:

Vielen Dank für die Klärung Simon! :-)

It makes sense that serialization/deserialization takes place when using
remoting, but I'm glad that you pointed this out.
My initial thought whas that if you're using haXe on the client side as
well as on the server side, no ser/deser would happen since it "stays in
the family".
But that is of course no longer true if the client has been compiled to
run in the Flash Player, and not on Neko.

So the paragraph on object cache in the SPOD documentation
(http://haxe.org/doc/neko/spod) is not valid when using remoting I guess?
If I call a service method to return an object and save that object to a
variable, then call the same service method and save the result to
another variable, and then update one of both variables, the other one
won't be changed as well?

I never used SPOD, but remoting SPOD objects (which subclass neko.db.Object) to flash platform sounds rather interesting [1]. Even if you manage to pull it off (say by using #if neko extends neko.db.Object #end on your objects), my guess is that your assumption is correct and you end up with inconsistent object states after the unserializer created two different SPOD instances.

Regards
Simon

[1] Quite possibly the kind of interesting that makes you spend a few hours trying to figure out a way to handle it before realizing it was a stupid idea to begin with.




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


--
haXe - an open source web programming language
http://haxe.org
I'm a haXe target!
Reply | Threaded
Open this post in threaded view
|

Re: Neko server instead of AMFPHP/Fluorine gateway

Krzysztof Różalski
Hi,

I usually use SPOD behid the haxe remoting services layer for persistence and it works really nice. But SPOD objects should not be used as transfer-objects (http://martinfowler.com/eaaCatalog/dataTransferObject.html). I usually create some typedefs to act as transfer objects so I reuse them on both server and the client. Unfortunately if you want to use AMF instead of haxe remoting you can not use typedefs unless you don't care about class mapping.

If the project is big enough and there is a complex domain logic I would advice to add another "domain" layer that could be used across platforms so you could run some parts of the logic on both client and server and just send some notification that something has changed instead of the whole data to update. This way you can create a nice, smooth application that does not need to wait for the server to respond.

My two cents ;)
Cheers!

On Mon, May 30, 2011 at 11:01 PM, Sven Dens <[hidden email]> wrote:
Do I smell a little sarcasm in your last reply, Simon?

I'm just trying to understand why it would be a stupid idea to use SPOD/Neko on the server side to remote to Flash?
The idea of using Neko instead of AMFPHP is that Neko would be a lot faster, and since client/server using haXe is perfectly possible (http://haxe.org/doc/remoting/client_server), and haXe client code can target the Flash Player, why would it be a stupid idea to compile the server to Neko using SPOD and the client to Flash?

How would you implement a haXe Flash client and "a" haXe server then?
I mean, if not compiling the server to Neko, how would you use haXe remoting in combination with Flash?
Would you code the server to compile to JS and return data in JSON-format, then read that data on the client side?
Surely you would not write haXe code to target PHP to create AMFHP-services, would you?

Would love for you to explain yourself a bit more after that last answer.
And if anyone else has some tips for me, please share them too! :-)

Thanks!

Sven



On Mon, May 30, 2011 at 10:25 PM, Simon Krajewski <[hidden email]> wrote:
Am 30.05.2011 20:08, schrieb Sven Dens:

Vielen Dank für die Klärung Simon! :-)

It makes sense that serialization/deserialization takes place when using
remoting, but I'm glad that you pointed this out.
My initial thought whas that if you're using haXe on the client side as
well as on the server side, no ser/deser would happen since it "stays in
the family".
But that is of course no longer true if the client has been compiled to
run in the Flash Player, and not on Neko.

So the paragraph on object cache in the SPOD documentation
(http://haxe.org/doc/neko/spod) is not valid when using remoting I guess?
If I call a service method to return an object and save that object to a
variable, then call the same service method and save the result to
another variable, and then update one of both variables, the other one
won't be changed as well?

I never used SPOD, but remoting SPOD objects (which subclass neko.db.Object) to flash platform sounds rather interesting [1]. Even if you manage to pull it off (say by using #if neko extends neko.db.Object #end on your objects), my guess is that your assumption is correct and you end up with inconsistent object states after the unserializer created two different SPOD instances.

Regards
Simon

[1] Quite possibly the kind of interesting that makes you spend a few hours trying to figure out a way to handle it before realizing it was a stupid idea to begin with.




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


--
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: Neko server instead of AMFPHP/Fluorine gateway

Simon Krajewski
In reply to this post by sventunus
Am 30.05.2011 23:01, schrieb Sven Dens:
> Do I smell a little sarcasm in your last reply, Simon?

I was just suggesting that SPOD objects, which are designed to map
objects to a database using quite some "magic", are not exactly
tailormade to be remoted to other platforms. If you want to do it, you'd
have to make sure the objects you define can be imported in both flash
and neko, which is why I gave you the #if neko idea. Also you probably
want to handle serialization and unserialization by yourself using
hxSerialize and hxUnserialize [1] in order to ignore SPOD specific
fields that the client could not create properly.

> How would you implement a haXe Flash client and "a" haXe server then?
> I mean, if not compiling the server to Neko, how would you use haXe
> remoting in combination with Flash?

I never questioned the use of neko as server target, my doubts went to
your idea of remoting SPOD objects directly. It seems much easier to
define simple data classes and handle server-side persistence in a
different layer.

Regards
Simon

[1] http://haxe.1354130.n2.nabble.com/Custom-Serialization-td5385904.html


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

Re: Neko server instead of AMFPHP/Fluorine gateway

sventunus
In reply to this post by Krzysztof Różalski
Hey Christopher,

I don't want to do AMF. In fact, I've been doing AMF forever and want to take this opportunity to break out of my old habits and use haXe all the way, both for the server and the client. I still don't understand however how to abstract the SPOD-objects to typedefs to exchange them between Neko and Flash.
I also don't understand how that domain layer could collaborate with Neko and Flash in a way standard haXe client/server could not?
Could you provide a really really simple example to demonstrate how you would return a SPOD-object from Neko to haXe Flash?

I realise that I'm asking n00b questions here, but there's no shame in trying to learn I think?

Thanks! :-)
Sven


2011/5/30 Krzysztof Różalski <[hidden email]>
Hi,

I usually use SPOD behid the haxe remoting services layer for persistence and it works really nice. But SPOD objects should not be used as transfer-objects (http://martinfowler.com/eaaCatalog/dataTransferObject.html). I usually create some typedefs to act as transfer objects so I reuse them on both server and the client. Unfortunately if you want to use AMF instead of haxe remoting you can not use typedefs unless you don't care about class mapping.

If the project is big enough and there is a complex domain logic I would advice to add another "domain" layer that could be used across platforms so you could run some parts of the logic on both client and server and just send some notification that something has changed instead of the whole data to update. This way you can create a nice, smooth application that does not need to wait for the server to respond.

My two cents ;)
Cheers!

On Mon, May 30, 2011 at 11:01 PM, Sven Dens <[hidden email]> wrote:
Do I smell a little sarcasm in your last reply, Simon?

I'm just trying to understand why it would be a stupid idea to use SPOD/Neko on the server side to remote to Flash?
The idea of using Neko instead of AMFPHP is that Neko would be a lot faster, and since client/server using haXe is perfectly possible (http://haxe.org/doc/remoting/client_server), and haXe client code can target the Flash Player, why would it be a stupid idea to compile the server to Neko using SPOD and the client to Flash?

How would you implement a haXe Flash client and "a" haXe server then?
I mean, if not compiling the server to Neko, how would you use haXe remoting in combination with Flash?
Would you code the server to compile to JS and return data in JSON-format, then read that data on the client side?
Surely you would not write haXe code to target PHP to create AMFHP-services, would you?

Would love for you to explain yourself a bit more after that last answer.
And if anyone else has some tips for me, please share them too! :-)

Thanks!

Sven



On Mon, May 30, 2011 at 10:25 PM, Simon Krajewski <[hidden email]> wrote:
Am 30.05.2011 20:08, schrieb Sven Dens:

Vielen Dank für die Klärung Simon! :-)

It makes sense that serialization/deserialization takes place when using
remoting, but I'm glad that you pointed this out.
My initial thought whas that if you're using haXe on the client side as
well as on the server side, no ser/deser would happen since it "stays in
the family".
But that is of course no longer true if the client has been compiled to
run in the Flash Player, and not on Neko.

So the paragraph on object cache in the SPOD documentation
(http://haxe.org/doc/neko/spod) is not valid when using remoting I guess?
If I call a service method to return an object and save that object to a
variable, then call the same service method and save the result to
another variable, and then update one of both variables, the other one
won't be changed as well?

I never used SPOD, but remoting SPOD objects (which subclass neko.db.Object) to flash platform sounds rather interesting [1]. Even if you manage to pull it off (say by using #if neko extends neko.db.Object #end on your objects), my guess is that your assumption is correct and you end up with inconsistent object states after the unserializer created two different SPOD instances.

Regards
Simon

[1] Quite possibly the kind of interesting that makes you spend a few hours trying to figure out a way to handle it before realizing it was a stupid idea to begin with.




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


--

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


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


--
haXe - an open source web programming language
http://haxe.org
I'm a haXe target!
Reply | Threaded
Open this post in threaded view
|

Re: Neko server instead of AMFPHP/Fluorine gateway

jlm@justinfront.net
Only looked at this once so totally out of my field but, well with haXe you can compile a class to both targets...
so if you Relect through a class grab ing property fields and dumping them on a an object or typedef then you can serialize that..

Serializer.run( sendObject )
and then send it.

and then use reflection or some field iteration to reassign it back to the same class the other side.

var recieved = Unserializer.run( recieveString );
for( all in Type.getInstanceFields( Type.getClass( myspod ) ) )
{
...
}

the serialize and deserialize can be the same data class both sides and can easily be fairly generic to pass different spod class data across?

Not sure if that's correct but seems plausible, with flash just {} maybe cheaper ( but less typed ) than typedef but same principle I think.

If I am totally wrong well maybe by me defining my understanding the explanation will make sure I follow despite being a db newbie.


Cheers ;j


On 30 May 2011, at 23:57, Sven Dens wrote:

Hey Christopher,

I don't want to do AMF. In fact, I've been doing AMF forever and want to take this opportunity to break out of my old habits and use haXe all the way, both for the server and the client. I still don't understand however how to abstract the SPOD-objects to typedefs to exchange them between Neko and Flash.
I also don't understand how that domain layer could collaborate with Neko and Flash in a way standard haXe client/server could not?
Could you provide a really really simple example to demonstrate how you would return a SPOD-object from Neko to haXe Flash?

I realise that I'm asking n00b questions here, but there's no shame in trying to learn I think?

Thanks! :-)
Sven


2011/5/30 Krzysztof Różalski <[hidden email]>
Hi,

I usually use SPOD behid the haxe remoting services layer for persistence and it works really nice. But SPOD objects should not be used as transfer-objects (http://martinfowler.com/eaaCatalog/dataTransferObject.html). I usually create some typedefs to act as transfer objects so I reuse them on both server and the client. Unfortunately if you want to use AMF instead of haxe remoting you can not use typedefs unless you don't care about class mapping.

If the project is big enough and there is a complex domain logic I would advice to add another "domain" layer that could be used across platforms so you could run some parts of the logic on both client and server and just send some notification that something has changed instead of the whole data to update. This way you can create a nice, smooth application that does not need to wait for the server to respond.

My two cents ;)
Cheers!

On Mon, May 30, 2011 at 11:01 PM, Sven Dens <[hidden email]> wrote:
Do I smell a little sarcasm in your last reply, Simon?

I'm just trying to understand why it would be a stupid idea to use SPOD/Neko on the server side to remote to Flash?
The idea of using Neko instead of AMFPHP is that Neko would be a lot faster, and since client/server using haXe is perfectly possible (http://haxe.org/doc/remoting/client_server), and haXe client code can target the Flash Player, why would it be a stupid idea to compile the server to Neko using SPOD and the client to Flash?

How would you implement a haXe Flash client and "a" haXe server then?
I mean, if not compiling the server to Neko, how would you use haXe remoting in combination with Flash?
Would you code the server to compile to JS and return data in JSON-format, then read that data on the client side?
Surely you would not write haXe code to target PHP to create AMFHP-services, would you?

Would love for you to explain yourself a bit more after that last answer.
And if anyone else has some tips for me, please share them too! :-)

Thanks!

Sven



On Mon, May 30, 2011 at 10:25 PM, Simon Krajewski <[hidden email]> wrote:
Am 30.05.2011 20:08, schrieb Sven Dens:

Vielen Dank für die Klärung Simon! :-)

It makes sense that serialization/deserialization takes place when using
remoting, but I'm glad that you pointed this out.
My initial thought whas that if you're using haXe on the client side as
well as on the server side, no ser/deser would happen since it "stays in
the family".
But that is of course no longer true if the client has been compiled to
run in the Flash Player, and not on Neko.

So the paragraph on object cache in the SPOD documentation
(http://haxe.org/doc/neko/spod) is not valid when using remoting I guess?
If I call a service method to return an object and save that object to a
variable, then call the same service method and save the result to
another variable, and then update one of both variables, the other one
won't be changed as well?

I never used SPOD, but remoting SPOD objects (which subclass neko.db.Object) to flash platform sounds rather interesting [1]. Even if you manage to pull it off (say by using #if neko extends neko.db.Object #end on your objects), my guess is that your assumption is correct and you end up with inconsistent object states after the unserializer created two different SPOD instances.

Regards
Simon

[1] Quite possibly the kind of interesting that makes you spend a few hours trying to figure out a way to handle it before realizing it was a stupid idea to begin with.




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


--

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


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

--
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: Neko server instead of AMFPHP/Fluorine gateway

Quickform | Marcus Bergstrom
Hi Sven,

Your initial idea of using #if neko... works just fine. I have been doing that forever. The advantage being having less classes.
But you need to sort out the serializer. I have pasted an example for you here: http://pastebin.com/1hTYeXEq.
I haven't tested any of this with the new macro-ed SPOD yet.

Best of luck with haxe/neko.

Regards,

Marcus Bergstrom
[hidden email]
--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Neko server instead of AMFPHP/Fluorine gateway

Krzysztof Różalski
In reply to this post by sventunus
Hi Sven,

I don't have any magic way to convert SPOD to transfer objects and back. And to be honest I don't even look for it usually because I like things to be explicit in code with as less magic going on as possible. Of course this approach was a huge disadvantage in the amount of boilerplate code (copy state between objects) but sometimes I prefer to do it this way and having a clear separation of concepts inside my code. 
I add this additional domain-model layer (=even more boilerplate code....) only if the client can run the "business logic" of the application independently without having to wait for server feedback. So the client run the logic all by itself and notifies the server (in the background) that something has change so the server runs the same logic again, converts model object to SPOD one and persists the result. But this is just for projects that was pretty complex logic and implanting the logic itself in Plain-Old-Haxe-Objects + unit test for it makes sense. The big drawback is that you have a lot of similar classes (SPODs, models, transfer objects..) and need to write some boilerplate code..
For many cases using #if neko and sending SPOD objects directly will probably work. But you need to be careful in order not to expose to much... For me it just feels a little wrong but I am pervert-purist in this kind of things ;-)

Regards,
Christopher

On Mon, May 30, 2011 at 11:57 PM, Sven Dens <[hidden email]> wrote:
Hey Christopher,

I don't want to do AMF. In fact, I've been doing AMF forever and want to take this opportunity to break out of my old habits and use haXe all the way, both for the server and the client. I still don't understand however how to abstract the SPOD-objects to typedefs to exchange them between Neko and Flash.
I also don't understand how that domain layer could collaborate with Neko and Flash in a way standard haXe client/server could not?
Could you provide a really really simple example to demonstrate how you would return a SPOD-object from Neko to haXe Flash?

I realise that I'm asking n00b questions here, but there's no shame in trying to learn I think?

Thanks! :-)
Sven


2011/5/30 Krzysztof Różalski <[hidden email]>
Hi,

I usually use SPOD behid the haxe remoting services layer for persistence and it works really nice. But SPOD objects should not be used as transfer-objects (http://martinfowler.com/eaaCatalog/dataTransferObject.html). I usually create some typedefs to act as transfer objects so I reuse them on both server and the client. Unfortunately if you want to use AMF instead of haxe remoting you can not use typedefs unless you don't care about class mapping.

If the project is big enough and there is a complex domain logic I would advice to add another "domain" layer that could be used across platforms so you could run some parts of the logic on both client and server and just send some notification that something has changed instead of the whole data to update. This way you can create a nice, smooth application that does not need to wait for the server to respond.

My two cents ;)
Cheers!

On Mon, May 30, 2011 at 11:01 PM, Sven Dens <[hidden email]> wrote:
Do I smell a little sarcasm in your last reply, Simon?

I'm just trying to understand why it would be a stupid idea to use SPOD/Neko on the server side to remote to Flash?
The idea of using Neko instead of AMFPHP is that Neko would be a lot faster, and since client/server using haXe is perfectly possible (http://haxe.org/doc/remoting/client_server), and haXe client code can target the Flash Player, why would it be a stupid idea to compile the server to Neko using SPOD and the client to Flash?

How would you implement a haXe Flash client and "a" haXe server then?
I mean, if not compiling the server to Neko, how would you use haXe remoting in combination with Flash?
Would you code the server to compile to JS and return data in JSON-format, then read that data on the client side?
Surely you would not write haXe code to target PHP to create AMFHP-services, would you?

Would love for you to explain yourself a bit more after that last answer.
And if anyone else has some tips for me, please share them too! :-)

Thanks!

Sven



On Mon, May 30, 2011 at 10:25 PM, Simon Krajewski <[hidden email]> wrote:
Am 30.05.2011 20:08, schrieb Sven Dens:

Vielen Dank für die Klärung Simon! :-)

It makes sense that serialization/deserialization takes place when using
remoting, but I'm glad that you pointed this out.
My initial thought whas that if you're using haXe on the client side as
well as on the server side, no ser/deser would happen since it "stays in
the family".
But that is of course no longer true if the client has been compiled to
run in the Flash Player, and not on Neko.

So the paragraph on object cache in the SPOD documentation
(http://haxe.org/doc/neko/spod) is not valid when using remoting I guess?
If I call a service method to return an object and save that object to a
variable, then call the same service method and save the result to
another variable, and then update one of both variables, the other one
won't be changed as well?

I never used SPOD, but remoting SPOD objects (which subclass neko.db.Object) to flash platform sounds rather interesting [1]. Even if you manage to pull it off (say by using #if neko extends neko.db.Object #end on your objects), my guess is that your assumption is correct and you end up with inconsistent object states after the unserializer created two different SPOD instances.

Regards
Simon

[1] Quite possibly the kind of interesting that makes you spend a few hours trying to figure out a way to handle it before realizing it was a stupid idea to begin with.




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


--

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


--

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


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


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