| Brian Lesser 2005-12-15, 5:45 pm |
| Hi Pritham,
Well, first off I like both ideas. I think it would be great to be able
to inject a developer created id into the logs that is also available as
part of the admin api. That would be powerful and would give each
developer the choice to format/manage IDs in a way that made sense for
each application. It would be great!
But, even if that was implemented, I would still like to see the
internal ID reflected in the client object. For my purposes a unique id
within an instance's lifetime is sufficient and I have no problem with
internal IDs being reused after an instance is garbage collected.
Yours truly,
-Brian
Pritham Shetty wrote:
>Exposing the client id is simple. We had some concerns in terms of
>supporting it future versions and also what the end user expectations
>would be on the id. One of the things in the current id generation
>scheme, an id can be reused immediately after a client has disconnected.
>If script is using this for unique mapping and it is still holding onto
>disconnected clients you can run into problems.
>
>One other problem is in FMS 2 edge-origin deployment, client id's on the
>origin can be different from the id's on the edge. Creating a unique
>id's across multiple servers is a challenge.
>
>Let me ask a couple of questions on what you want this id to be:
>
>1) unique across all application instances on a given server
>2) id's are never reused.
>3) unique only for the application instance.
>
>Would it be better if we provided a mechanism where you can set a FMS
>defined property before you call accept or reject connection and we log
>this as one of the fields in access log and also return it as part of
>admin commands?
>
>
>Pritham.
>
>
>
>
>-----Original Message-----
>From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
>[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of Brian
>Lesser
>Sent: Thursday, December 15, 2005 7:09 AM
>To: FlashComm Mailing List
>Subject: Re: [FlashComm] How to link between internal IDs and SS
>Client/Netstream objects ?
>
>Thanks Pritham,
>That's helpful and good to know. But I don't think it is simple. I
>really think that, unless there are technical hurdles, that you should
>expose the internal client id as a property of the client object in a
>future updater or later relase. It should be trivially simple for an
>application developer to match client object to internal id as
>necessary.
>It's too bad optionally catching publishing events could do so much
>damage in an origin setup. Maybe one day we can push filtering code that
>
>can manage those events out to the edge.
>Thanks again,
>-Brian
>
>Pritham Shetty wrote:
>
>
>
>access
>
>
>to
>
>
>in
>
>
>any
>
>
>a
>
>
>
>
>
>
--
________________________________________
______________________________
Brian Lesser
Assistant Director, Teaching and Technology Support
Computing and Communications Services
Ryerson University
350 Victoria St.
Toronto, Ontario Phone: (416) 979-5000 ext. 6835
M5B 2K3 Fax: (416) 979-5220
Office: AB48D E-mail: blesser-6s6ziW1YCwCw5LPnMra/2Q@public.gmane.org
(Enter through LB66) Web: http://www.ryerson.ca/~blesser
________________________________________
______________________________
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
|