[Red5] SharedObject general info Thread

[Tyler Kocheran]

Yes, I think that's what I was saying. When a SharedObject is created, it
resides in the scope (or path) in which it was created. Therefore, if you
run something like this:
connection.connect("rtmp://localhost/myapp");
...
sharedObject = SharedObject.getRemote("mySO", nc.uri, false);

you are creating a different SharedObject than if you called something like
this:
connection.connect("rtmp://localhost/myapp/1");
...
sharedObject = SharedObject.getRemote("mySO", nc.uri, false);

This way, you can effectively have "rooms" under each child scope of your
applications. You can keep a SharedObject named "index" under each scope
without worrying about whether it will interfere or overwrite another
scope's "index" SharedObject. Very nice.

On Tue, Mar 17, 2009 at 10:00 AM, Daniel Elliott
<danelliottster at gmail.com>wrote:

> Great intro.  I have a question that may be worthy of this thread...
>
> Shared objects implement the basic scope.  However, the "Scopes and
> Contexts" portion of the wiki notes that basic scopes cannot be
> connected to.  So, when you say connected to below, are you referring
> to the scope that the shared object is within?
>
> Thanks.
>
> - dan
>
> On Fri, Mar 6, 2009 at 1:45 PM, Tyler Kocheran <rfkrocktk at gmail.com>
> wrote:
> > Ok, these questions come up a lot in the mailing list, so I'm going to
> > address them head on. It's easy to ignore people asking for help when
> you've
> > answered the question so many times in the past, so the hope is that
> rather
> > than explaining everything every time, we can direct people to this
> thread.
> > Here goes nothing.
> >
> > 1. "I created a (transient) SharedObject on appStart and the data's all
> gone
> > when I connect to it."
> >
> > Ok, here's the deal. Red5 treats transient SharedObjects like live
> grenades,
> > if the pin is out (if there's nobody connected to it), Red5 will chuck it
> > like nobody's business. After all, it's a grenade! In comparison to Red5,
> > FMS treats transient SharedObjects like a 2 year old would treat
> something.
> > It's only a matter of time before the transient SharedObject is chucked,
> but
> > it's not really certain when. I've had FMS hold transient SharedObjects
> > (with no one attached to it) for up to 5 minutes before, but this is
> > unreliable, and it shouldn't be this way. Red5 gets rid of them,
> enforcing
> > the fact that they're transient, they don't stick around. If there aren't
> > any users connected to the transient SharedObject, it's as good as dead
> if
> > you haven't acquire()'d it.
> >
> > The solution is to call ISharedObject.acquire() on the SharedObject. This
> > will ensure that Red5 does not chuck itas soon as possible. In the
> > documentation, it is said that "Each call to acquire() must be followed
> by a
> > call to release() so that the SharedObject isn't held forever." So, the
> best
> > thing to do would be to add a listener to the SharedObject, via
> > ISharedObject.addSharedObjectListener() and in that listener's
> > onSharedObjectConnect method, call sharedObject.release(). What this does
> is
> > it ensures that you can hold the SharedObject in memory until the first
> > person connects to it. After that, it's fair game. Because of the way
> that
> > the whole acquire() and release() system works, you could also create a
> > in-memory SharedObject that only loses its data on server shutdown. This
> is
> > nice if you don't want information to persist across server restarts as
> is
> > the case with persistent SharedObjects.
> >
> > 2. "I created a (transient) SharedObject on appStart with a
> > ISharedObjectListener on it, and the listeners aren't getting fired."
> >
> > See the solution above. You must acquire() the SharedObject so that it
> isn't
> > killed.
> >
> > 3. "Is it more effective to store data in the SharedObject or use the
> send()
> > method?"
> >
> > It depends on what you're doing. The "send()" method is appropriately
> named.
> > If you need to send a message (or even a method call) to all subscribed
> > clients, use this method. The point is that this method will send data
> once
> > across the SharedObject. Actually, here's what not to do. Don't use
> > SharedObject attributes to track a conversation. SharedObject attributes
> are
> > to ensure that everyone viewing the SharedObject at any time are seeing
> the
> > same thing. The shared Red5 logo (not ball, Art...) demo gives a great
> idea
> > of what to do with SharedObject attributes. For example, it's not usually
> > extremely important that all newly connecting users see the entire
> history
> > of the conversation, but it is necessary for them to see that the logo is
> at
> > x: 15 and y: 100. Another example of using SharedObject attributes could
> be
> > found in a gauge that tells everyone connected how 'happy' a user is. The
> > user changes a slider to show their happiness or anger level, and that is
> > updated in real time across all connected clients. You can watch him get
> > mad.
> >
> > There's a lot more points to be made, but yeah, I can't really give all
> of
> > them here and now. However, for those of you who are interested, I have
> been
> > working on an extensive Red5 course for training on advanced topics
> > including SharedObject configuration in every way possible, advanced
> > streaming, remoting, data objects, etc. If you're interested, email me
> off
> > list for more information and for a timeline on when it'll be done,
> > hopefully soon.
> >
> > If anyone has any other generic SharedObject problems and solutions, feel
> > free to tack 'em on to the end of this one. I hope this has been helpful.
> >
> >  - TK
> >
> > --
> > And do this, knowing the time, that now it is high time to awake out of
> > sleep;
> > for now our salvation is nearer than when we first believed.
> >
> > _______________________________________________
> > Red5 mailing list
> > Red5 at osflash.org
> > http://osflash.org/mailman/listinfo/red5_osflash.org
> >
> >
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>



-- 
And do this, knowing the time, that now it is high time to awake out of
sleep;
for now our salvation is nearer than when we first believed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://osflash.org/pipermail/red5_osflash.org/attachments/20090317/760d232f/attachment-0001.html>