True. Wouldn't <app, stream, key> uniquely identify a event sent to a particular PE prototype in an app? Will it be more appropriate to create a new object (something that extends event) everytime we send an Event to a PE?
I might be missing something fundamental here. Please point if I am. Thanks much, Karthik On Fri, Oct 14, 2011 at 3:40 PM, Leo Neumeyer <[email protected]> wrote: > Remember that an event may be dispatched with several keys. That's why we > tie the key to the stream which delivers to a specific PE prototype. Let me > think a bit more. > > -leo > > > On Oct 14, 2011, at 12:03, Karthik Kambatla <[email protected]> > wrote: > > > Also, if we make Key a first class member of Event, do we really need > other > > classes - Key and KeyFinder - to determine the value of key of a > particular > > event? > > > > Thanks > > Karthik > > > > On Fri, Oct 14, 2011 at 1:01 PM, Karthik Kambatla < > [email protected]>wrote: > > > >> Hello > >> > >> Given that every event has an associated key (e.g. CountEvent.key), > >> wouldn't it make sense to add it to the Event class itself? > >> > >> The key in every Event, can be used directly for routing decisions. > Also, I > >> believe it will prove to be very handy if people consider each PE > instance > >> serving multiple keys (for scalability) or want to write their own > >> extensions for persisting the events. > >> > >> Implementation: To facilitate different types of keys (Strings, Ints > etc.), > >> we might want to make Event generic - Event<Key> with certain properties > on > >> key. > >> > >> Thanks > >> Karthik > >> >
