[Free] Server features to be discussed

[Ashvin Savani - Arckid]

We can also work with vnc2swf. And I guess we should also add one feature
called Screen Sharing. 

 

Best Regards,

 

Ashvin Savani - Arckid

Freelance Developer - Arckid.com <http://www.arckid.com/blog/> 

CTO - Avinashi.com <http://www.avinashi.com/> 

Team Macromedia Member - Flash

User's Group Manager - Gujarat

  _____  

From: Free-bounces at osflash.org [mailto:Free-bounces at osflash.org] On Behalf
Of john grden
Sent: Friday, September 09, 2005 5:14 PM
To: Free at osflash.org
Subject: Re: [Free] Server features to be discussed

 

Yes, the idea is to reproduced the same client / server relationship the
Flash player has with Flash Communication Server.

although, in yesterday's discussions, we had touched on later
implementations being able to stream other media types as well (OGG, MOV,
WMV etc), which could very well mean a different client.

On 9/9/05, Ashvin Savani - Arckid <me at arckid.com> wrote: 

Hi all,

 

I just want to confirm that will FREE based on flash player?

 

One more thing I can do for our team is I can give my personal license to
group for testing purpose, till they need it. You guys deserve it :-) 

 

Best Regards,

 

Ashvin Savani - Arckid

Freelance Developer - Arckid.com <http://www.arckid.com/blog/> 

CTO - Avinashi.com <http://www.avinashi.com/> 

Team Macromedia Member - Flash

User's Group Manager - Gujarat 

  _____  

From: Free-bounces at osflash.org [mailto: <mailto:Free-bounces at osflash.org>
Free-bounces at osflash.org] On Behalf Of john grden
Sent: Thursday, September 08, 2005 10:33 PM
To: Free at osflash.org
Subject: Re: [Free] Server features to be discussed

 



On 8 Sep 2005 16:49:01 -0000, grant at bluetube.com <grant at bluetube.com> wrote:

    "You can handle this at the container/configration level so the "key" is
validated on every call or at a predetermined session age or for certain
components that require the identity of the user to be verified.  The client
will never do any decoding or decrypting it will just need to pass the key,
kinda like how cookies work, the browser has them but the server actually
reads the cookie."

that's perfect, I was thinking the client would have some work to do

    "You can have session recovery where the "session" is persisted to a
backend such as database/filesystem/database but you are talking about quite
a sophisitcated feature which I'd be inclined to use a J2EE server for.  The
potential complexities when you have a server with 1000 clients that goes
belly up and needs to restart all 1000 clients and restore their server
state could be very difficult to implement, we can take a look at how much
of that you'd want to implement.  Session back/replication is expensive as
every change to the users "session" that could restore to a previous state
requires a write or change to a backing store and if replicated its
duplicated across servers.  What we generally do is if the server goes down
the user is tranfered to another server but they have to restart their
session (log back in) as session replication with 1000's of users it too
expensive for the servers/network and the application architecture."

Yes, this makes sense.  I don't know that I was thinking that every users's
state/action would be stored, I was thinking more at the Room/application
level.  Users in a room really and maybe general properties that you
designate as persistant to the room.  I would think that would be a minimal
write scenario to a DB/log, but then again, maybe not enough to justify as a
part of the server.  Maybe some hooks that allow this to happen if the
developer wants this level of failover?

   " what your asking for is built into a J2EE server, say you have an
application packaged as an ear or war file, this application can be deployed
to multiple servers setup as a cluster, so the room instance would exist on
one or more servers but its physical location is transparent to the caller.
If you want to deploy a room "application" to 1 server only you can target
it as non clustered but then you have lost your failover ability."

ah ok, then, that's exactly what i was asking about, thanks for taking time
on that one Grant, appreciate that.



Thanks Grant!


-- 
John Grden - Blitz 


_______________________________________________
Free mailing list
Free at osflash.org
http://osflash.org/mailman/listinfo/free_osflash.org






-- 
John Grden - Blitz 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/free_osflash.org/attachments/20050909/2037edf2/attachment.htm