Home » Archived » Eclipse Communications Framework (ECF) » ECF + EMF
| | |
| Re: ECF + EMF [message #618297 is a reply to message #618294] |
Fri, 27 April 2007 17:07   |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
James Willans wrote:
> We are exploring technology for supporting the collaborative editing of
> EMF models. Is there any specific examples of using ECF to support this?
>
> Thanks,
>
> James
>
Hi James.
Yes, in 2005 we built a simple shared EMF graphical editor using EMF/SDO
(for serialization), ECF (for messaging/state synchronization and
model replication), and GEF (for a simple graphical model editor). This
was before GMF even, so we weren't able to use that.
These 3 plugins still exist in CVS
/cvsroot/technology/org.eclipse.ecf/plugins
org.eclipse.ecf.sdo
org.eclipse.ecf.example.sdo.editor
org.eclipse.ecf.example.sdo.gefeditor
As I recall (I didn't do most of the programming for this myself, rather
it was done by Peter Nehrer and Boris Bokowski), there were two
editors...one based upon the simple editor created from EMF, and
modified to synchronize state changes via ECF (and I believe this is
what's in org.eclipse.ecf.example.sdo.editor), and the graphical 'node'
editor in (org.eclipse.ecf.example.sdo.gefeditor).
The reason we stopped maintaining these was:
1) We didn't want to have a dependency on EMF in any of the ECF core
plugins, so that we could be used in other environments (e.g. eRCP, etc)
and at the time this wasn't the case with EMF/SDO (it might be able to
run in some form in such environments now...I don't know).
2) We didn't have the resources to maintain/build/deploy/support them
But these plugins are still there, and can probably still be used. If
you (James or others) specifically would like us to begin (again)
testing, maintaining, and including these plugins in the ECF
distribution please just post an enhancement request to that effect and
we will do what we can.
> James,
>
> Eike Stepper has worked on such a thing with CDO:
>
> http://www.eclipse.org/emft/projects/cdo/
>
> I think he's currently reworking the design. Scott and he have been chatting, but I'm not sure where things are at...
I would like to see the CDO plugins become an ECF provider (i.e. an
implementation of some of the ECF APIs...e.g. datashare, sharedobject,
possibly others). If this were to happen, then it would make EMF/ECF
integration even easier than it already is and we would have another
excellent transport supported.
I've not been able to do this work myself over the last few months, as
I've been occupied with other ECF and personal matters, but perhaps Eike
and I can work together on this in the future. From what I understand
of CDO I don't believe this would be technically difficult.
>
> Have you seen http://www2.sys-con.com/java/readerschoice2004/frameliveupda te.cfm?BType=11 and considered voting? :-)
Wow Ed...I guess my voting 500 times for EMF really helped ;-).
Scott
|
|
|
| Re: ECF + EMF [message #618298 is a reply to message #618297] |
Fri, 27 April 2007 16:23 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Scott,
EMF works even stand alone and so do the generated models and generated
item providers. It's always supported that. The most significant
shortcoming is that we only have one big feature that includes
everything rather than smaller features for things like an RCP core
runtime, but we will be working on that issue next week and hope to have
smaller features available for Europa.
Scott Lewis wrote:
> James Willans wrote:
>> We are exploring technology for supporting the collaborative editing
>> of EMF models. Is there any specific examples of using ECF to
>> support this?
>>
>> Thanks,
>>
>> James
>>
>
> Hi James.
>
> Yes, in 2005 we built a simple shared EMF graphical editor using
> EMF/SDO (for serialization), ECF (for messaging/state synchronization
> and model replication), and GEF (for a simple graphical model
> editor). This was before GMF even, so we weren't able to use that.
>
> These 3 plugins still exist in CVS
>
> /cvsroot/technology/org.eclipse.ecf/plugins
>
> org.eclipse.ecf.sdo
> org.eclipse.ecf.example.sdo.editor
> org.eclipse.ecf.example.sdo.gefeditor
>
> As I recall (I didn't do most of the programming for this myself,
> rather it was done by Peter Nehrer and Boris Bokowski), there were two
> editors...one based upon the simple editor created from EMF, and
> modified to synchronize state changes via ECF (and I believe this is
> what's in org.eclipse.ecf.example.sdo.editor), and the graphical
> 'node' editor in (org.eclipse.ecf.example.sdo.gefeditor).
>
> The reason we stopped maintaining these was:
>
> 1) We didn't want to have a dependency on EMF in any of the ECF core
> plugins, so that we could be used in other environments (e.g. eRCP,
> etc) and at the time this wasn't the case with EMF/SDO (it might be
> able to run in some form in such environments now...I don't know).
>
> 2) We didn't have the resources to maintain/build/deploy/support them
>
> But these plugins are still there, and can probably still be used. If
> you (James or others) specifically would like us to begin (again)
> testing, maintaining, and including these plugins in the ECF
> distribution please just post an enhancement request to that effect
> and we will do what we can.
>
>> James,
>>
>> Eike Stepper has worked on such a thing with CDO:
>>
>> http://www.eclipse.org/emft/projects/cdo/
>>
>> I think he's currently reworking the design. Scott and he have been
>> chatting, but I'm not sure where things are at...
>
>
> I would like to see the CDO plugins become an ECF provider (i.e. an
> implementation of some of the ECF APIs...e.g. datashare, sharedobject,
> possibly others). If this were to happen, then it would make EMF/ECF
> integration even easier than it already is and we would have another
> excellent transport supported.
>
> I've not been able to do this work myself over the last few months, as
> I've been occupied with other ECF and personal matters, but perhaps
> Eike and I can work together on this in the future. From what I
> understand of CDO I don't believe this would be technically difficult.
>
>
>>
>> Have you seen
>> http://www2.sys-con.com/java/readerschoice2004/frameliveupda te.cfm?BType=11
>> and considered voting? :-)
>
>
> Wow Ed...I guess my voting 500 times for EMF really helped ;-).
>
> Scott
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: ECF + EMF [message #618529 is a reply to message #618526] |
Thu, 03 May 2007 12:59 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Denis,
Is this change model you refer to related to
org.eclipse.emf.ecore.change? In case not, a ChangeRecorder can be
attached to any ResourceSet, Resource, or EObject and will record all
changes by monitoring all notifications. This can then be converted to
a ChangeDescription (endRecording/summarize) which can be serialized
just like any other EMF model instance. The change description produced
this way represents a delta from the current state to the original
state, so often what folks want to do is do is call applyAndReverse,
send that delta, which becomes a forward delta from the original state
to the changed state, and then call apply again to get the model back
into the final/changed state again...
I think I need to spend some time with Scott to understand what we might
be able to do to collaborate better...
Denis Jouvin wrote:
> James Willans wrote:
>
>> Thanks for all the info guys - especially Scott. We are currently
>> information gathering, it is unclear what direction we will go right
>> now (it is not clear what our requirements are).
>
>> James
>
> Hi all,
>
> We are currently (at my company, elycee) using the following approach
> for sharing EMF models using ECF:
> We have build a change model (based on EMF notifications) using EMF
> itself, then everytime a change on the source EMF model instance
> occurs, it is converted to an "EMF-ied change", serialized as XML and
> sent through the ECF XMPP provider.
>
> What would really be great would be to have an
> "EMFSharedObjectContainer" that does the job. Instead of using normal
> Java introspection as with standard SharedObject, it could benefit
> from EMF generated metadata.
>
> I don't know if there is a generic way of expressing an EMF model
> instance change using EMF itself, but that would facilitate this kind
> of approach.
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: ECF + EMF [message #618531 is a reply to message #618529] |
Thu, 03 May 2007 17:33 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
Ed Merks wrote:
> Denis,
>
> Is this change model you refer to related to
> org.eclipse.emf.ecore.change? In case not, a ChangeRecorder can be
> attached to any ResourceSet, Resource, or EObject and will record all
> changes by monitoring all notifications. This can then be converted to
> a ChangeDescription (endRecording/summarize) which can be serialized
> just like any other EMF model instance. The change description produced
> this way represents a delta from the current state to the original
> state, so often what folks want to do is do is call applyAndReverse,
> send that delta, which becomes a forward delta from the original state
> to the changed state, and then call apply again to get the model back
> into the final/changed state again...
This is great. I didn't know that EMF had an 'applyAndReverse' operation.
ECF currently doesn't have any replicated state conflict
detection/resolution algorithms built in (it's up to apps to do their
own synch for replicated state at this point...and we and others have
done some fairly naive implementations for examples)...BUT we very much
want to build in extension points around the notion of 'operational
transforms' described and referenced by this work of Mustafa's for last
year's SOC project:
http://wiki.eclipse.org/index.php/RT_Shared_Editing
The idea would be that a particular kind of editor could define a set of
relevant operations/changes of the model (e.g. insert/delete/etc), and a
set of operational transforms for maintaining consistency of the
replicated model as it changes. Those rules would, I expect, locally
use the EMF operations like 'applyAndReverse' at the appropriate times
to maintain consistency of the replicated model. There could be
extension points for both defining relevant operations for a given type
of model, and for creating operational transforms.
It seems to me that this would be what Denis is fundamentally suggesting
WRT an EMFSharedObjectContainer...i.e. a extension type of container
that 'knows' what operations can be performed on a given model, and how
to transform those operations in real time to maintain consistency (and
to know what consistency is for a given model).
Does this seem right?
Unfortunately, I can't promise immediate work on this idea for
myself...as much as I would like to as I find this area (shared model
editing) particularly interesting. ECF is approaching 1.0.0 and
participating in Europa and my project lead responsibilities have
address those immediate requirements.
But if we can generate enough interest in persuing this then perhaps we
can get some resources to support (aka additional committers to work on
this specifically) and/or work on this jointly within the EMF and ECF
communities. And if a community effort was/could be started (a
cross-ECF and EMF incubator project?) then I would love to support it in
any way I could...I find this area personally very interesting/exciting.
Scott
>
> I think I need to spend some time with Scott to understand what we might
> be able to do to collaborate better...
>
>
> Denis Jouvin wrote:
>> James Willans wrote:
>>
>>> Thanks for all the info guys - especially Scott. We are currently
>>> information gathering, it is unclear what direction we will go right
>>> now (it is not clear what our requirements are).
>>
>>> James
>>
>> Hi all,
>>
>> We are currently (at my company, elycee) using the following approach
>> for sharing EMF models using ECF:
>> We have build a change model (based on EMF notifications) using EMF
>> itself, then everytime a change on the source EMF model instance
>> occurs, it is converted to an "EMF-ied change", serialized as XML and
>> sent through the ECF XMPP provider.
>>
>> What would really be great would be to have an
>> "EMFSharedObjectContainer" that does the job. Instead of using normal
>> Java introspection as with standard SharedObject, it could benefit
>> from EMF generated metadata.
>>
>> I don't know if there is a generic way of expressing an EMF model
>> instance change using EMF itself, but that would facilitate this kind
>> of approach.
>>
>>
>>
|
|
|
| Re: ECF + EMF [message #618536 is a reply to message #618531] |
Thu, 03 May 2007 20:15 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Scott,
My comments are inline below.
Scott Lewis wrote:
> Hi Ed,
>
> Ed Merks wrote:
>> Denis,
>>
>> Is this change model you refer to related to
>> org.eclipse.emf.ecore.change? In case not, a ChangeRecorder can be
>> attached to any ResourceSet, Resource, or EObject and will record all
>> changes by monitoring all notifications. This can then be converted
>> to a ChangeDescription (endRecording/summarize) which can be
>> serialized just like any other EMF model instance. The change
>> description produced this way represents a delta from the current
>> state to the original state, so often what folks want to do is do is
>> call applyAndReverse, send that delta, which becomes a forward delta
>> from the original state to the changed state, and then call apply
>> again to get the model back into the final/changed state again...
>
> This is great. I didn't know that EMF had an 'applyAndReverse'
> operation.
We're just full of surprises. :-)
>
> ECF currently doesn't have any replicated state conflict
> detection/resolution algorithms built in (it's up to apps to do their
> own synch for replicated state at this point...and we and others have
> done some fairly naive implementations for examples)...BUT we very
> much want to build in extension points around the notion of
> 'operational transforms' described and referenced by this work of
> Mustafa's for last year's SOC project:
>
> http://wiki.eclipse.org/index.php/RT_Shared_Editing
>
> The idea would be that a particular kind of editor could define a set
> of relevant operations/changes of the model (e.g. insert/delete/etc),
> and a set of operational transforms for maintaining consistency of the
> replicated model as it changes. Those rules would, I expect, locally
> use the EMF operations like 'applyAndReverse' at the appropriate times
> to maintain consistency of the replicated model. There could be
> extension points for both defining relevant operations for a given
> type of model, and for creating operational transforms.
>
> It seems to me that this would be what Denis is fundamentally
> suggesting WRT an EMFSharedObjectContainer...i.e. a extension type of
> container that 'knows' what operations can be performed on a given
> model, and how to transform those operations in real time to maintain
> consistency (and to know what consistency is for a given model).
>
> Does this seem right?
Yes this seems right.
>
> Unfortunately, I can't promise immediate work on this idea for
> myself...as much as I would like to as I find this area (shared model
> editing) particularly interesting. ECF is approaching 1.0.0 and
> participating in Europa and my project lead responsibilities have
> address those immediate requirements.
What? You aren't made of spare time like all the rest of us? Just
kidding!!
>
> But if we can generate enough interest in persuing this then perhaps
> we can get some resources to support (aka additional committers to
> work on this specifically) and/or work on this jointly within the EMF
> and ECF communities.
I think it's cool and is closely related to which Eike Stepper has been
doing. (But he's been really quiet lately.)
> And if a community effort was/could be started (a cross-ECF and EMF
> incubator project?) then I would love to support it in any way I
> could...I find this area personally very interesting/exciting.
Yes, I will support that too. It's a matter of having warm bodies to do
the work.
>
>
> Scott
>
>
>>
>> I think I need to spend some time with Scott to understand what we
>> might be able to do to collaborate better...
>>
>>
>> Denis Jouvin wrote:
>>> James Willans wrote:
>>>
>>>> Thanks for all the info guys - especially Scott. We are currently
>>>> information gathering, it is unclear what direction we will go
>>>> right now (it is not clear what our requirements are).
>>>
>>>> James
>>>
>>> Hi all,
>>>
>>> We are currently (at my company, elycee) using the following
>>> approach for sharing EMF models using ECF:
>>> We have build a change model (based on EMF notifications) using EMF
>>> itself, then everytime a change on the source EMF model instance
>>> occurs, it is converted to an "EMF-ied change", serialized as XML
>>> and sent through the ECF XMPP provider.
>>>
>>> What would really be great would be to have an
>>> "EMFSharedObjectContainer" that does the job. Instead of using
>>> normal Java introspection as with standard SharedObject, it could
>>> benefit from EMF generated metadata.
>>>
>>> I don't know if there is a generic way of expressing an EMF model
>>> instance change using EMF itself, but that would facilitate this
>>> kind of approach.
>>>
>>>
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: ECF + EMF [message #618539 is a reply to message #618536] |
Wed, 02 May 2007 20:40 |
|
Ed Merks schrieb:
> Scott,
>
> My comments are inline below.
>
> Scott Lewis wrote:
>> Hi Ed,
>>
>> Ed Merks wrote:
>>> Denis,
>>>
>>> Is this change model you refer to related to
>>> org.eclipse.emf.ecore.change? In case not, a ChangeRecorder can be
>>> attached to any ResourceSet, Resource, or EObject and will record all
>>> changes by monitoring all notifications. This can then be converted
>>> to a ChangeDescription (endRecording/summarize) which can be
>>> serialized just like any other EMF model instance. The change
>>> description produced this way represents a delta from the current
>>> state to the original state, so often what folks want to do is do is
>>> call applyAndReverse, send that delta, which becomes a forward delta
>>> from the original state to the changed state, and then call apply
>>> again to get the model back into the final/changed state again...
>>
>> This is great. I didn't know that EMF had an 'applyAndReverse'
>> operation.
> We're just full of surprises. :-)
>>
>> ECF currently doesn't have any replicated state conflict
>> detection/resolution algorithms built in (it's up to apps to do their
>> own synch for replicated state at this point...and we and others have
>> done some fairly naive implementations for examples)...BUT we very
>> much want to build in extension points around the notion of
>> 'operational transforms' described and referenced by this work of
>> Mustafa's for last year's SOC project:
>>
>> http://wiki.eclipse.org/index.php/RT_Shared_Editing
>>
>> The idea would be that a particular kind of editor could define a set
>> of relevant operations/changes of the model (e.g. insert/delete/etc),
>> and a set of operational transforms for maintaining consistency of the
>> replicated model as it changes. Those rules would, I expect, locally
>> use the EMF operations like 'applyAndReverse' at the appropriate times
>> to maintain consistency of the replicated model. There could be
>> extension points for both defining relevant operations for a given
>> type of model, and for creating operational transforms.
>>
>> It seems to me that this would be what Denis is fundamentally
>> suggesting WRT an EMFSharedObjectContainer...i.e. a extension type of
>> container that 'knows' what operations can be performed on a given
>> model, and how to transform those operations in real time to maintain
>> consistency (and to know what consistency is for a given model).
>>
>> Does this seem right?
> Yes this seems right.
>>
>> Unfortunately, I can't promise immediate work on this idea for
>> myself...as much as I would like to as I find this area (shared model
>> editing) particularly interesting. ECF is approaching 1.0.0 and
>> participating in Europa and my project lead responsibilities have
>> address those immediate requirements.
> What? You aren't made of spare time like all the rest of us? Just
> kidding!!
>>
>> But if we can generate enough interest in persuing this then perhaps
>> we can get some resources to support (aka additional committers to
>> work on this specifically) and/or work on this jointly within the EMF
>> and ECF communities.
> I think it's cool and is closely related to which Eike Stepper has been
> doing. (But he's been really quiet lately.)
Hey guys, I'm really sorry about that.
It's partly due to an important customer engagement until mid of the year.
On the other hand I've made impressive progress with the new version of CDO.
The new version of Net4j is already finished and I remember that I talked
with Scott about it. Both technologies are completely rewritten and that took
me several months fulltime work. I'm really looking forward to give some
presentation when time comes (for CDO, Net4j is ready).
Please feel free to contact me if you'd like to have some discussion earlier ;-)
Cheers
/Eike
>> And if a community effort was/could be started (a cross-ECF and EMF
>> incubator project?) then I would love to support it in any way I
>> could...I find this area personally very interesting/exciting.
> Yes, I will support that too. It's a matter of having warm bodies to do
> the work.
>>
>>
>> Scott
>>
>>
>>>
>>> I think I need to spend some time with Scott to understand what we
>>> might be able to do to collaborate better...
>>>
>>>
>>> Denis Jouvin wrote:
>>>> James Willans wrote:
>>>>
>>>>> Thanks for all the info guys - especially Scott. We are currently
>>>>> information gathering, it is unclear what direction we will go
>>>>> right now (it is not clear what our requirements are).
>>>>
>>>>> James
>>>>
>>>> Hi all,
>>>>
>>>> We are currently (at my company, elycee) using the following
>>>> approach for sharing EMF models using ECF:
>>>> We have build a change model (based on EMF notifications) using EMF
>>>> itself, then everytime a change on the source EMF model instance
>>>> occurs, it is converted to an "EMF-ied change", serialized as XML
>>>> and sent through the ECF XMPP provider.
>>>>
>>>> What would really be great would be to have an
>>>> "EMFSharedObjectContainer" that does the job. Instead of using
>>>> normal Java introspection as with standard SharedObject, it could
>>>> benefit from EMF generated metadata.
>>>>
>>>> I don't know if there is a generic way of expressing an EMF model
>>>> instance change using EMF itself, but that would facilitate this
>>>> kind of approach.
>>>>
>>>>
>>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: ECF + EMF [message #618541 is a reply to message #618539] |
Thu, 03 May 2007 22:26 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
Any chance we could get CDO/net4j work implemented as an ECF
provider...implementing ECF's datashare and sharedobject APIs?
Actually, if it can be made to implement the sharedobject API then
datashare comes for free on top of that (as datashare can be/is already
implemented on sharedobject API).
I'll help with that if desired...the short tech story is to have a
class/classes that implement: IContainer and
ISharedObjectContainer...simple.
Scott
Eike Stepper wrote:
>
>
> Ed Merks schrieb:
>> Scott,
>>
>> My comments are inline below.
>>
>> Scott Lewis wrote:
>>> Hi Ed,
>>>
>>> Ed Merks wrote:
>>>> Denis,
>>>>
>>>> Is this change model you refer to related to
>>>> org.eclipse.emf.ecore.change? In case not, a ChangeRecorder can be
>>>> attached to any ResourceSet, Resource, or EObject and will record
>>>> all changes by monitoring all notifications. This can then be
>>>> converted to a ChangeDescription (endRecording/summarize) which can
>>>> be serialized just like any other EMF model instance. The change
>>>> description produced this way represents a delta from the current
>>>> state to the original state, so often what folks want to do is do is
>>>> call applyAndReverse, send that delta, which becomes a forward delta
>>>> from the original state to the changed state, and then call apply
>>>> again to get the model back into the final/changed state again...
>>>
>>> This is great. I didn't know that EMF had an 'applyAndReverse'
>>> operation.
>> We're just full of surprises. :-)
>>>
>>> ECF currently doesn't have any replicated state conflict
>>> detection/resolution algorithms built in (it's up to apps to do their
>>> own synch for replicated state at this point...and we and others have
>>> done some fairly naive implementations for examples)...BUT we very
>>> much want to build in extension points around the notion of
>>> 'operational transforms' described and referenced by this work of
>>> Mustafa's for last year's SOC project:
>>>
>>> http://wiki.eclipse.org/index.php/RT_Shared_Editing
>>>
>>> The idea would be that a particular kind of editor could define a set
>>> of relevant operations/changes of the model (e.g. insert/delete/etc),
>>> and a set of operational transforms for maintaining consistency of
>>> the replicated model as it changes. Those rules would, I expect,
>>> locally use the EMF operations like 'applyAndReverse' at the
>>> appropriate times to maintain consistency of the replicated model.
>>> There could be extension points for both defining relevant operations
>>> for a given type of model, and for creating operational transforms.
>>>
>>> It seems to me that this would be what Denis is fundamentally
>>> suggesting WRT an EMFSharedObjectContainer...i.e. a extension type of
>>> container that 'knows' what operations can be performed on a given
>>> model, and how to transform those operations in real time to maintain
>>> consistency (and to know what consistency is for a given model).
>>>
>>> Does this seem right?
>> Yes this seems right.
>>>
>>> Unfortunately, I can't promise immediate work on this idea for
>>> myself...as much as I would like to as I find this area (shared model
>>> editing) particularly interesting. ECF is approaching 1.0.0 and
>>> participating in Europa and my project lead responsibilities have
>>> address those immediate requirements.
>> What? You aren't made of spare time like all the rest of us? Just
>> kidding!!
>>>
>>> But if we can generate enough interest in persuing this then perhaps
>>> we can get some resources to support (aka additional committers to
>>> work on this specifically) and/or work on this jointly within the EMF
>>> and ECF communities.
>> I think it's cool and is closely related to which Eike Stepper has
>> been doing. (But he's been really quiet lately.)
>
> Hey guys, I'm really sorry about that.
> It's partly due to an important customer engagement until mid of the year.
> On the other hand I've made impressive progress with the new version of
> CDO.
> The new version of Net4j is already finished and I remember that I talked
> with Scott about it. Both technologies are completely rewritten and that
> took
> me several months fulltime work. I'm really looking forward to give some
> presentation when time comes (for CDO, Net4j is ready).
> Please feel free to contact me if you'd like to have some discussion
> earlier ;-)
>
> Cheers
> /Eike
>
>>> And if a community effort was/could be started (a cross-ECF and EMF
>>> incubator project?) then I would love to support it in any way I
>>> could...I find this area personally very interesting/exciting.
>> Yes, I will support that too. It's a matter of having warm bodies to
>> do the work.
>>>
>>>
>>> Scott
>>>
>>>
>>>>
>>>> I think I need to spend some time with Scott to understand what we
>>>> might be able to do to collaborate better...
>>>>
>>>>
>>>> Denis Jouvin wrote:
>>>>> James Willans wrote:
>>>>>
>>>>>> Thanks for all the info guys - especially Scott. We are currently
>>>>>> information gathering, it is unclear what direction we will go
>>>>>> right now (it is not clear what our requirements are).
>>>>>
>>>>>> James
>>>>>
>>>>> Hi all,
>>>>>
>>>>> We are currently (at my company, elycee) using the following
>>>>> approach for sharing EMF models using ECF:
>>>>> We have build a change model (based on EMF notifications) using EMF
>>>>> itself, then everytime a change on the source EMF model instance
>>>>> occurs, it is converted to an "EMF-ied change", serialized as XML
>>>>> and sent through the ECF XMPP provider.
>>>>>
>>>>> What would really be great would be to have an
>>>>> "EMFSharedObjectContainer" that does the job. Instead of using
>>>>> normal Java introspection as with standard SharedObject, it could
>>>>> benefit from EMF generated metadata.
>>>>>
>>>>> I don't know if there is a generic way of expressing an EMF model
>>>>> instance change using EMF itself, but that would facilitate this
>>>>> kind of approach.
>>>>>
>>>>>
>>>>>
|
|
|
| Re: ECF + EMF [message #618544 is a reply to message #618541] |
Thu, 03 May 2007 05:36 |
|
Hi Scott,
Regarding CDO I'm not that sure how it could work.
With the new design it is much easier now to exchange
the backend so that it doesn't map the models to an
RDB but simply keeps them in memory for the duration
of a shared session and distributes changes to all
members of this shared session. A conceptual issue
exists on the client side since CDOResource does
not assume that it has an associated representation
in the local file system. Nevertheless it can import
resources from there and export back.
Personally I'm more keen on integrating CDO with SDO
by providing an SDO Data Mediator on top of CDO. Not
sure when I'll have time for that.
With Net4j chances are really good that we can manage
to integrate with ECF since they basically serve the
same purpose: communicatons. I can't work on this
actively before I finish the redesign of CDO which
is really pressing. If you want I can send you a
Team Project Set file to quickly checkout Net4j
(and CDO as an example of Net4j usage) or even a
zipped workspace. In addition I'll prepare some
UML diagrams to illustrate the architecture.
Cheers
/Eike
Scott Lewis schrieb:
> Hi Eike,
>
> Any chance we could get CDO/net4j work implemented as an ECF
> provider...implementing ECF's datashare and sharedobject APIs? Actually,
> if it can be made to implement the sharedobject API then datashare comes
> for free on top of that (as datashare can be/is already implemented on
> sharedobject API).
>
> I'll help with that if desired...the short tech story is to have a
> class/classes that implement: IContainer and
> ISharedObjectContainer...simple.
>
> Scott
>
> Eike Stepper wrote:
>>
>>
>> Ed Merks schrieb:
>>> Scott,
>>>
>>> My comments are inline below.
>>>
>>> Scott Lewis wrote:
>>>> Hi Ed,
>>>>
>>>> Ed Merks wrote:
>>>>> Denis,
>>>>>
>>>>> Is this change model you refer to related to
>>>>> org.eclipse.emf.ecore.change? In case not, a ChangeRecorder can be
>>>>> attached to any ResourceSet, Resource, or EObject and will record
>>>>> all changes by monitoring all notifications. This can then be
>>>>> converted to a ChangeDescription (endRecording/summarize) which can
>>>>> be serialized just like any other EMF model instance. The change
>>>>> description produced this way represents a delta from the current
>>>>> state to the original state, so often what folks want to do is do
>>>>> is call applyAndReverse, send that delta, which becomes a forward
>>>>> delta from the original state to the changed state, and then call
>>>>> apply again to get the model back into the final/changed state
>>>>> again...
>>>>
>>>> This is great. I didn't know that EMF had an 'applyAndReverse'
>>>> operation.
>>> We're just full of surprises. :-)
>>>>
>>>> ECF currently doesn't have any replicated state conflict
>>>> detection/resolution algorithms built in (it's up to apps to do
>>>> their own synch for replicated state at this point...and we and
>>>> others have done some fairly naive implementations for
>>>> examples)...BUT we very much want to build in extension points
>>>> around the notion of 'operational transforms' described and
>>>> referenced by this work of Mustafa's for last year's SOC project:
>>>>
>>>> http://wiki.eclipse.org/index.php/RT_Shared_Editing
>>>>
>>>> The idea would be that a particular kind of editor could define a
>>>> set of relevant operations/changes of the model (e.g.
>>>> insert/delete/etc), and a set of operational transforms for
>>>> maintaining consistency of the replicated model as it changes.
>>>> Those rules would, I expect, locally use the EMF operations like
>>>> 'applyAndReverse' at the appropriate times to maintain consistency
>>>> of the replicated model. There could be extension points for both
>>>> defining relevant operations for a given type of model, and for
>>>> creating operational transforms.
>>>>
>>>> It seems to me that this would be what Denis is fundamentally
>>>> suggesting WRT an EMFSharedObjectContainer...i.e. a extension type
>>>> of container that 'knows' what operations can be performed on a
>>>> given model, and how to transform those operations in real time to
>>>> maintain consistency (and to know what consistency is for a given
>>>> model).
>>>>
>>>> Does this seem right?
>>> Yes this seems right.
>>>>
>>>> Unfortunately, I can't promise immediate work on this idea for
>>>> myself...as much as I would like to as I find this area (shared
>>>> model editing) particularly interesting. ECF is approaching 1.0.0
>>>> and participating in Europa and my project lead responsibilities
>>>> have address those immediate requirements.
>>> What? You aren't made of spare time like all the rest of us? Just
>>> kidding!!
>>>>
>>>> But if we can generate enough interest in persuing this then perhaps
>>>> we can get some resources to support (aka additional committers to
>>>> work on this specifically) and/or work on this jointly within the
>>>> EMF and ECF communities.
>>> I think it's cool and is closely related to which Eike Stepper has
>>> been doing. (But he's been really quiet lately.)
>>
>> Hey guys, I'm really sorry about that.
>> It's partly due to an important customer engagement until mid of the
>> year.
>> On the other hand I've made impressive progress with the new version
>> of CDO.
>> The new version of Net4j is already finished and I remember that I talked
>> with Scott about it. Both technologies are completely rewritten and
>> that took
>> me several months fulltime work. I'm really looking forward to give some
>> presentation when time comes (for CDO, Net4j is ready).
>> Please feel free to contact me if you'd like to have some discussion
>> earlier ;-)
>>
>> Cheers
>> /Eike
>>
>>>> And if a community effort was/could be started (a cross-ECF and EMF
>>>> incubator project?) then I would love to support it in any way I
>>>> could...I find this area personally very interesting/exciting.
>>> Yes, I will support that too. It's a matter of having warm bodies to
>>> do the work.
>>>>
>>>>
>>>> Scott
>>>>
>>>>
>>>>>
>>>>> I think I need to spend some time with Scott to understand what we
>>>>> might be able to do to collaborate better...
>>>>>
>>>>>
>>>>> Denis Jouvin wrote:
>>>>>> James Willans wrote:
>>>>>>
>>>>>>> Thanks for all the info guys - especially Scott. We are
>>>>>>> currently information gathering, it is unclear what direction we
>>>>>>> will go right now (it is not clear what our requirements are).
>>>>>>
>>>>>>> James
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> We are currently (at my company, elycee) using the following
>>>>>> approach for sharing EMF models using ECF:
>>>>>> We have build a change model (based on EMF notifications) using
>>>>>> EMF itself, then everytime a change on the source EMF model
>>>>>> instance occurs, it is converted to an "EMF-ied change",
>>>>>> serialized as XML and sent through the ECF XMPP provider.
>>>>>>
>>>>>> What would really be great would be to have an
>>>>>> "EMFSharedObjectContainer" that does the job. Instead of using
>>>>>> normal Java introspection as with standard SharedObject, it could
>>>>>> benefit from EMF generated metadata.
>>>>>>
>>>>>> I don't know if there is a generic way of expressing an EMF model
>>>>>> instance change using EMF itself, but that would facilitate this
>>>>>> kind of approach.
>>>>>>
>>>>>>
>>>>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: ECF + EMF [message #618548 is a reply to message #618546] |
Fri, 04 May 2007 22:18 |
|
Hey Scott,
Scott Lewis schrieb:
> Hi Eike,
>
> Eike Stepper wrote:
>> Hi Scott,
>>
>> Regarding CDO I'm not that sure how it could work.
>> With the new design it is much easier now to exchange
>> the backend so that it doesn't map the models to an
>> RDB but simply keeps them in memory for the duration
>> of a shared session and distributes changes to all
>> members of this shared session. A conceptual issue
>> exists on the client side since CDOResource does
>> not assume that it has an associated representation
>> in the local file system. Nevertheless it can import
>> resources from there and export back.
>>
>> Personally I'm more keen on integrating CDO with SDO
>> by providing an SDO Data Mediator on top of CDO. Not
>> sure when I'll have time for that.
>
> OK. I frankly don't understand the added value of CDO over SDO + a
> messaging/state replication framework like ECF (with communications
> providers like net4j), but that's probably just my limited knowledge
> of what CDO is intended to address.
Indeed CDO has a slightly different focus than SDO: CDO is a distributed
shared model repository. The main difference is that SDO is positioned
around the concept of diconnected (from the central repository) object
graphs while CDO (as its long name says ;-) )aims to provide Connected
Data Objects.
Apart from this difference I didn't think about added values when I
started the project because neither SDO nor ECF existed at that time ;-)
>
>>
>> With Net4j chances are really good that we can manage
>> to integrate with ECF since they basically serve the
>> same purpose: communicatons. I can't work on this
>> actively before I finish the redesign of CDO which
>> is really pressing. If you want I can send you a
>> Team Project Set file to quickly checkout Net4j
>> (and CDO as an example of Net4j usage) or even a
>> zipped workspace. In addition I'll prepare some
>> UML diagrams to illustrate the architecture.
>
> Sure, that would be great. Please do send the team project set file
> and any diagrams/docs you have/can produce. I assume you've got
> javadocs for everything too? And maybe a simple example app (not all
> of CDO, just a trivial app)?
Cool, I'll send the infos asap to you. And yes, Ill provide fency
JavaDocs ;-))
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: ECF + EMF [message #618552 is a reply to message #618548] |
Tue, 08 May 2007 06:18 |
|
This is a multi-part message in MIME format.
--------------070703010105090208000605
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi Scott,
I've attached a Team Project Set File for Net4j and CDO each as well as some diagrams for Net4j.
The types in org.eclipse.net4j.transport have proper JavaDocs (more to follow).
The four main interfaces of the transport layer are IBuffer, IChannel, IConnector and IProtocol.
A good starting point is org.eclipse.net4j.tests.TCPTransportTest.createContainer() to see how it all works.
The transport layer is the lowest layer in Net4j. It is asynchronous, buffer-oriented, non-blocking, fast
but somewhat inconvenient for clients that are stream-oriented. I suggest that we use a SignalProtocol
to integrate with ECF. SignalProtocols are sets of Signals that can be exchanged between two peers (IChannels).
For each logical signal two classes have to be implemented, one for the sending party (RequestWithConfirmation)
and one for the receiving party (IndicationWithResponse). In each of these classes two methods have to be
implemented:
org.eclipse.net4j.signal.RequestWithConfirmation.requesting( ExtendedDataOutputStream)
org.eclipse.net4j.signal.RequestWithConfirmation.confirming( ExtendedDataInputStream)
org.eclipse.net4j.signal.IndicationWithResponse.indicating(E xtendedDataInputStream)
org.eclipse.net4j.signal.IndicationWithResponse.responding(E xtendedDataOutputStream)
In addition to these synchronous signals there is also an asynchronous version available:
org.eclipse.net4j.signal.Request.requesting(ExtendedDataOutp utStream)
org.eclipse.net4j.signal.Indication.indicating(ExtendedDataI nputStream)
A very simple example for such a SignalProtocol is in org.eclipse.net4j.tests.SignalTest.
Complex examples for user supplied protocols are the packages org.eclipse.emf.internal.cdo.protocol and
org.eclipse.emf.cdo.internal.server.protocol. I'll provide a simpler example application for Net4j ASAP.
I plan to develop a remoting layer on top of SignalProtocols that integrates with the OSGi service registry
as well as a publish/subscribe framework that integrates with the OSGi EventAdmin. But that has not top priority.
Please tell me if you have questions or if I can help otherwise.
Cheers
/Eike
Eike Stepper schrieb:
> Hey Scott,
>
>
> Scott Lewis schrieb:
>> Hi Eike,
>>
>> Eike Stepper wrote:
>>> Hi Scott,
>>>
>>> Regarding CDO I'm not that sure how it could work.
>>> With the new design it is much easier now to exchange
>>> the backend so that it doesn't map the models to an
>>> RDB but simply keeps them in memory for the duration
>>> of a shared session and distributes changes to all
>>> members of this shared session. A conceptual issue
>>> exists on the client side since CDOResource does
>>> not assume that it has an associated representation
>>> in the local file system. Nevertheless it can import
>>> resources from there and export back.
>>>
>>> Personally I'm more keen on integrating CDO with SDO
>>> by providing an SDO Data Mediator on top of CDO. Not
>>> sure when I'll have time for that.
>>
>> OK. I frankly don't understand the added value of CDO over SDO + a
>> messaging/state replication framework like ECF (with communications
>> providers like net4j), but that's probably just my limited knowledge
>> of what CDO is intended to address.
> Indeed CDO has a slightly different focus than SDO: CDO is a distributed
> shared model repository. The main difference is that SDO is positioned
> around the concept of diconnected (from the central repository) object
> graphs while CDO (as its long name says ;-) )aims to provide Connected
> Data Objects.
>
> Apart from this difference I didn't think about added values when I
> started the project because neither SDO nor ECF existed at that time ;-)
>
>>
>>>
>>> With Net4j chances are really good that we can manage
>>> to integrate with ECF since they basically serve the
>>> same purpose: communicatons. I can't work on this
>>> actively before I finish the redesign of CDO which
>>> is really pressing. If you want I can send you a
>>> Team Project Set file to quickly checkout Net4j
>>> (and CDO as an example of Net4j usage) or even a
>>> zipped workspace. In addition I'll prepare some
>>> UML diagrams to illustrate the architecture.
>>
>> Sure, that would be great. Please do send the team project set file
>> and any diagrams/docs you have/can produce. I assume you've got
>> javadocs for everything too? And maybe a simple example app (not all
>> of CDO, just a trivial app)?
> Cool, I'll send the infos asap to you. And yes, Ill provide fency
> JavaDocs ;-))
>
> Cheers
> /Eike
--------------070703010105090208000605
Content-Type: text/xml;
name="net4j.psf"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="net4j.psf"
<?xml version="1.0" encoding="UTF-8"?>
<psf version="2.0">
<provider id="org.eclipse.team.cvs.core.cvsnature">
<project reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse. emft/net4j/plugins/org.eclipse.net4j,org.eclipse.net4j "/>
<project reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse. emft/net4j/plugins/org.eclipse.net4j.debug,org.eclipse.net4j .debug "/>
<project reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse. emft/net4j/plugins/org.eclipse.net4j.jvm,org.eclipse.net4j.j vm "/>
<project reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse. emft/net4j/plugins/org.eclipse.net4j.tcp,org.eclipse.net4j.t cp "/>
<project reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse. emft/net4j/tests/org.eclipse.net4j.tests,org.eclipse.net4j.t ests "/>
<project reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse. emft/net4j/plugins/org.eclipse.net4j.ui,org.eclipse.net4j.ui "/>
</provider>
</psf>
--------------070703010105090208000605
Content-Type: text/xml;
name="cdo2.psf"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="cdo2.psf"
<?xml version="1.0" encoding="UTF-8"?>
<psf version="2.0">
<provider id="org.eclipse.team.cvs.core.cvsnature">
<project reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse. emft/cdo/plugins/cdo2,cdo2 "/>
<project reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse. emft/cdo/plugins/cdo2.server,cdo2.server "/>
<project reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse. emft/cdo/plugins/org.eclipse.emf.cdo.protocol,org.eclipse.em f.cdo.protocol "/>
<project reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse. emft/cdo/tests/org.eclipse.emf.cdo.tests.model1,org.eclipse. emf.cdo.tests.model1 "/>
<project reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse. emft/cdo/tests/org.eclipse.emf.cdo.tests.model1.edit,org.ecl ipse.emf.cdo.tests.model1.edit "/>
<project reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse. emft/cdo/tests/org.eclipse.emf.cdo.tests.model1.editor,org.e clipse.emf.cdo.tests.model1.editor "/>
<project reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse. emft/cdo/tests/org.eclipse.emf.cdo.tests.tdd,org.eclipse.emf .cdo.tests.tdd "/>
<project reference=" 1.0,:extssh:dev.eclipse.org:/cvsroot/technology,org.eclipse. emft/cdo/plugins/org.eclipse.emf.cdo.ui,org.eclipse.emf.cdo. ui "/>
</provider>
</psf>
--------------070703010105090208000605
Content-Type: image/jpeg;
name="CommunicationProcess.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="CommunicationProcess.jpg"
/9j/4AAQSkZJRgABAQEAYABgAAD/4QAWRXhpZgAATU0AKgAAAAgAAAAAAAD/ 2wBDAAUDBAQE
AwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEPERETFhwXExQaFRERGCEYGh0d Hx8fExciJCIe
JBweHx7/2wBDAQUFBQcGBw4ICA4eFBEUHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4e
Hh4eHh4eHh4eHh4eHh4eHh4eHh7/wAARCALmA4sDASIAAhEBAxEB/8QAHAAB AQEBAQEBAQEA
AAAAAAAAAAYFBwQDAggB/8QAURAAAQQBAgIDDQUGBAQEBQMFAAECAwQFBhEH EhchdhMUFTE2
QVFXlZa10tQiN1VhtBYjMlZxckJUlNUzUmKBJCVTYwg1g5GhJjSlRGR1gvD/ xAAbAQEAAgMB
AQAAAAAAAAAAAAAABAYBAwUHAv/EAC0RAQABAgIJAwUBAQEAAAAAAAABAgMG EQQFMTIzNHGB
wRJBsRMUIVHwYSNC/9oADAMBAAIRAxEAPwD+ywAAAAAAztSZzD6bw0+Zz2Sq 43H103lsWJEY
xu/Uibr41VepETrVVRE6wNEEPR4saFtXqFN+Uu0JMi5GUn5PE26MVly+Jscs 8TGOVfMiKqr5
ty4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA
AAAAAAAc4yNGtqDj/DVy8kc9bTuCgyWOpSJu1bVieeN9jbxOdGyBrWqv8Pdn KmyrudHI7X+k
L2XyOP1LpnKR4fVGLY+OtZliWWCzA9UV9awxFRXROVrVRUVHMciOb50UKPP4 fGZ/C28NmaMN
7H3I1isV5m7te1f/APt0VOtFRFTrJXgTat2eGNCO5kn5R9K1dxzLr3czrMVa 3NXjkcv+JXMi
aqr51Xfzk7BkOK2s5cvptHab0pHjLjcflcnj7k1uy5XV4bCrVY+KNsaqydre d6uVq82zV2RV
6RpjB4zTWnqGAw1ZK2PoQNggjRVXZqJ51XrVV8aqvWqqqqBpAAAAAAAAAAAA AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8WbxOKzmLmxe bxlLJ0J+XutW
5A2aKTlcjk5mORUXZyIqbp40RSZ6J+Fnq00Z7CrfIWYAjOifhZ6tNGewq3yD on4WerTRnsKt
8hZgDkGheGXDazqjX0Njh7pKaKrqCKGuyTDV3NhYuMoPVjEVn2W873u2Tq3c 5fGqlZ0T8LPV
poz2FW+QcPPK7iP2kh+E44swIzon4WerTRnsKt8h96HDLhtQvV71Hh7pKrbr Stmgnhw1dkkT
2ru17XIzdrkVEVFTrRUKwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAD5XLMFOpNbtTMhrwRuklkeuzWNam6uVfMiIm59 Tm3HqeXJ4jEc
PKUzo7esLyUJljfyvjoMRZbj0/8ApNWP+srQJPgTns43XVq5qF8kdTiLWk1F h4pVaiwLE5Ik
g6v4nLT7yf8A/wCr/Qd1OccdsbNT0NV1Rg6v/mGjbUeXqQw7M54Imq2xAnV1 NdXdK3lTxry+
gvsXeqZTGVcnQnbYqW4WTwSt8Ukb2o5rk/JUVFA9IAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHNNEb6q4w6o1e93PQ wLf2bxXWu3dG
q2S7Jyr1brJ3OLdP/QUpOKupn6P4fZfP14FsXYIe50YEarlntSOSOCPZOtea R7E6vSfvhjpl
NHaBw+nFmWxPUrp31Orlcs9h6q+aVVXr+3I57uv/AJgKN7WvYrHtRzXJsqKm 6KhzfgY92Fhz
/DixI50mlb6x0eZXOc7GzostReZfHytV8PV4u4nSTmnERF0xxU0jrmNqpUyD v2Zyyojl2ZO7
nqSL5kRs6cm6/wCYUDpYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAkda6Xu6k1bpKxLNWTB4W5LkrMD0VZJ7TGclbbq 25WK+SRV3/iZ
H1L40rgABgcRdM1tZaGzOl7bkjZkaj4WSq3fuMm28cqJ6WPRrk/NqG+AM/TT cuzTmNZn31pM
u2pEl59ZVWJ06MTuis3RF5VdvtuidRoAAAAAAAAAAAQNLi9ou9Tgu0k1PZq2 I2ywzQ6Tyj2S
Mcm7XNclfZUVFRUVPGfbpU0p/ldW+6GV+mMZw+vTV+lwCH6VNKf5bVvuhlfp h0qaU/yurfdD
K/TDOD0VfpcAh+lTSn+W1b7oZX6YdKmlP8tq33Qyv0wzg9FX6XAIfpU0p/lt W+6GV+mHSppT
/K6t90Mr9MM4PRV+lwCH6VNKf5XVvuhlfph0qaU/yurfdDK/TDOD0VfpcAh+ lTSn+V1b7oZX
6YdKmlP8tq33Qyv0wzg9FX6XAIfpU0p/ldW+6GV+mHSppT/K6t90Mr9MM4PR V+lwCBu8XtF0
ac926mp61WvG6WaabSeUYyNjU3c5zlr7IiIiqqr4i+MsTExtAAGAAAAAAAAA AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIGlxe0XepwXaSans1b EbZYZodJ5R7J
GOTdrmuSvsqKioqKnjDMRM7F8CH6VNKf5XVvuhlfph0qaU/yurfdDK/TGM4Z 9FX6XAIfpU0p
/ldW+6GV+mHSppT/ACurfdDK/TDOD0VfpcAh+lTSn+V1b7oZX6YdKmlP8tq3 3Qyv0wzg9FX6
XAIfpU0p/ltW+6GV+mHSppT/ACurfdDK/TDOD0VfpcAh+lTSn+V1b7oZX6Yd KmlP8rq33Qyv
0wzg9FX6XAIfpU0p/ldW+6GV+mHSppT/ACurfdDK/TDOD0VfpcAh+lTSn+V1 b7oZX6Y+N3i9
oujTnu3U1PWq143SzTTaTyjGRsam7nOctfZEREVVVfEM4PTV+l8ADL5AAAAA AAAAAAAAAAAA
AAAAAAAAABP691ppjQmFjzOrMtHjKElhlZkr43v3kciqjdmIq+Jrl322REVV 2RCgQ4HxeoZr
iRxeTSuDx2KyeN0tiZVykWQyElWJbOQhfExqqyGRXPZBzuTqTbuu+/VssXhd SsykGiNGcVMz
NisXgJcpgtQPbkZKlW1drMh717tMjmLyPhV0jVc5qPei9S7bAf1C7M4puoma eW9D4WkqOutq
b/vO4Ne1iybeZvM5E6/Gu+3iU95/G12XG1NbeHdEZPUN26vD/Kt0xcy12R1m 5YjtSMb3FN07
ttCr3RsVqqrWscqK5OY9OssrgaGHt9EmrsllqdrRWTualkXLzWnRvSKPveeX mevcbLpFeiom
ztt0VqIgH9gAmeGemsfpfSkFOhNfnWztbsz3bstmWad7G88iukcqorlTdUTZ u6qqIm5TAAAA
AAAKAoHJuC/3O6K7P0P07CqmkjhidLNIyONibuc5dkRPSqkrwY+53RXZ+h+n YZvF6k+xc0rd
u42fKYCjlHTZWpDVdZVWrBK2KRYmorpGskVqqiIqp1O2+yRfd3KZyoiW9mdW 4/G5OHHNrW71
ifGWslClVGOSSOusaOYiucic7llby+bx7qhtJah2hSSRsUkybsje5EcvVvtt v1qn5HBtT4V9
2llH6X0ZlsbjZtK6khrQd6yp3WWbvZWcsSpvEsrkerYtmquyqjetTx6t05lp s1qWLLVsk+e/
DWTDvr6dddlVja8bWsisbo2q9kqPd9tWIirz79an1k+PqTEz+H9CyW6scjYp LMLHufyNa6RE
VXbIvKienZU6vzMHJ6405j62cnnuOd4EnjrW442K56zSMjcyNjU63ud3VjUR P8S7eNFOW6p0
ZPb09xSyE2nZ7mcltwPxth1JXTyLHTq8r4FRFXdJEf1s87VTzH21Fpqw3U2r 7OI03K7I1dTY
3UELY6SxpkK8UNfurI5lRGOf3Rs7uXm3503VOvcxEQTcq/ToOE1z31qCrg8z pnNadtX2Pfj1
vpC5lpGJzOajopHo16N3XkdsuyLtvspVMtVpJJY47ELnw/8AFaj0VWf3J5v+ 5B3tY5bUj3Yb
SGCzML5qdhbORyVCeiyk/uTkia3urGrJIsit6m7oiIq7+LeDp4aCWvpuvprS GTxWRx2HuQ5y
R+LkgV6OpuZ3F0qtRLD3TrG9Far9+VXb9fWyZ9eX+u7MuVHvkYy1A50bUdIi SIqtRfEq+hD9
Q2a80r4oZ4pJI9udrXoqt38W6eY4Rd0XJjtO6YXD6Xmr2n6GydXIOr0VbI+d 1avyRzKibrIr
+fZHdau5tuvc++otE5SlRwzNE4R2MyljRWSqWLEEHcnLYVtVYmyybJtIru68 qvXffmXzKMib
kx7O4wzwzK/uM0cnI7lfyOReVfQu3iUzM1qXCYnFPydvIQ96snjrufG5H7SS SNja3q8/M5P6
J1r1IcLj03l7mLy0ela2UrzppqxUlgj06uIje53JywOc5UWWZER6Nc3dG8zv tfa69bWGG0lk
9N35NNcOLsMVRmOfO5cLLX52xXI3OibXcxFle2Luu72tcvK5W7rzKgyPqTls dwdarNmihdYh
SWVFWNivTmeiedE84bZrOsd7pYiWbZV7mj05tk8fV4/OhwfUWIglxGsKS6Uy NjVWWud209fZ
iZV5I1ZH3o5s/JtXbDsnMxysVvI7q+113fC3TFalqLV2dvYVkeVsZ2dIb01b llkrrHFtyPVN
+5q5HLsi7Ku/nMTDNNczOWTW40fc9rXs/f8A07zrKHJuNH3O617P3/07zrKG 21sQdO3oAAbU
IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAFOTcF/ue0V
2fofp2HWVOTcF/ud0V2fofp2Gq7sTtB3pU7rNZtptV1iJLDm8zYlenOqelE8 ex/vd4O+O9+7
R925ebufMnNt6dvHscL1Zip63Em/do4O7krtjN0521L+BkkR6N7i3u1fIxKi Qsa1qryyOVEV
rkVuztl8WJ03mf2jhgyTMizULdSutvsV9OqrnRd8K9Je/wBVRiwrDsxWb78u 8aNXZENeSZ9S
c8snf23Kjp0gbagdMqb9zSRFd5/N4/Mv/wBlP9lsV42SPkniY2L/AIjnPREZ /X0eNDjVDRPe
HDubU2O053PVuPzdvLMd3ry27TY7sy9y3VOZySV1cxqeLZ7VQzcxprOd4aXz 2Vq2IoshcvZT
NxOxDsj3vZnazvZJKzftL3KJqw7oi8q7Lt17oyJuTEbHdp7dWCNJZ7MMTFTd HPejUVOrr3X+
qf8A3QjcnxEZFcyDMRpXUGep4uZ8OQu0Y4e5wyM/jY1JJGvlc3zpG12y9XWv UQemtEMv5vRs
OZwdrJYaF2anbFkcWkUMCSPg7k1YV3SJq7Pcxj9lT0Jy7JuaRzs/D7F5XTWX 05qK3agyV2zj
5KGLmssyEU875mKkkbVYx6d05XI9W7cu/i6xkeuZ/wAdJx+Zxd7E0crWvQup 5CNktWRzuVJW
vRFbtvsu6oqdXjPTPbq112nswxdaJ9uRE618Sdfp2U5Bk4El1HfynEnRVnI+ EcDVip1qlCTI
x15f3q2KzVYxe5vVzmLzryo7ZPtfZ6snC6Fv2sTqBmr9PuyeTi0NjakMtmt3 ZXWUitd1ZG5U
VHSI7uW6t3XflXzoMj6k/p3We3UgcjZrMMSq5Goj5ETdV8SdfnU/Uk8EUkcc k0bHyLsxrnIi
uX0InnOET6NlyuB11azGmJruRk0hShovtUVfKthtOXmbFzJv3RJOTfl+1zI3 zohn6rwOas5j
PMzlTJyyXqFNuJdFp11+VUSsxqxxz77VpGzJI7d6s2VyP39D0k3J/T+hpbVa KeOCWxDHLL/w
2OeiOf8A0TzmdhNR4fMQ5CejcY6LH2pKtl7l5UZJGuzvH5kXfr8S7HKbWJp1 MpqODWGkMnqb
L3Z6bsVYZRkc6aNleBrWpZjRW13MmbK9yq9uyu5k33M6pgK9DLWW3dKW34mj rC3dytaLESPb
PXljl70mRrWbWGMeqKrWcysVUVUTYZH1J/Tu7rlRtdth1qBsLm8zZFkTlVNt 90XxbbdZMcZl
R3BzWjmqiounryoqef8A8O85njtJx5jU2LR2lLDdIT6us262Pt45zIooExjm rI+F7f3cb7KO
cjXonW5Or7R0njDFFBwX1jBBGyKKPTt5jGMTZrWpWeiIieZEQZZSTVNVM/h1 1AEBJcUAAAAA
AAAAAAAAAAAAAAAAAAAAAA/Mscc0bo5Y2yMd42uTdF/7GBxD1Ba0xph2Uo46 HI2nXadOCvNZ
WCNz7NqKu1XSIx6tRFlRy7NVdk8Ri+HuJv8AJmkPemz9ARr+mWNHmIu1RGf7 ZimZ2Lh0UTnM
c6NiuZ/AqtTdvm6vQI4oolescbGK93M9WtROZfSvpUh/D3E3+TNIe9Nn6A2u HmobWp9MNyl7
HQ46027cpzV4bKzxtfWtS13K2RWMVyKsSuTdqLsviFjTLGkTMWqonL9E0zG1 QgAksAAAAAAF
AA5LwY+53RXZ+h+nYVpMaY4f8QdPaaxeApa40xJWxtOGnC+bS86vcyNiMarl S8iKuzU32RE3
8xo/stxJ/nXSXutY+vNE25dSnS7cUxDWBk/stxK/nXSXutY+vH7LcSv510l7 rWPrzH05fX3l
trAyf2W4lfzrpL3WsfXj9luJX866S91rH14+nUfeW2sDJ/ZbiV/Oukvdax9e eKbBcUWZyrj2
6m0w+vNWmmfbTS8/c4nMdEjY1/8AH78z0kcqflG78h9Oo+8tqMGT+y3Er+dd Je61j68fstxK
/nXSXutY+vH06j7y21gZP7LcSv510l7rWPrx+y3Er+ddJe61j68fTqPvLbWB k/stxK/nXSXu
tY+vH7LcSv510l7rWPrx9OT7y2yeNH3O617P3/07zrKHK9T8P+IOodNZTAXd caYjrZOnNTmf
DpedHtZIxWOVqreVEXZy7bov9DqhtopmmPyhaTdpuVRNIAD7RgAAAAAAAAAA AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAU5NwX+53RXZ+h+nYdZOV6 Y4f8QdPaaxeA
pa40xJWxtOGnC+bS86vcyNiMarlS8iKuzU32ROvzHxXTM7EnRrtNuZmpTgyf 2W4lfzrpL3Ws
fXj9luJX866S91rH15q+nUm/eW2sDJ/ZbiV/Oukvdax9eP2W4lfzrpL3WsfX j6cn3ltrAyf2
W4lfzrpL3WsfXj9luJX866S91rH14+nJ95bawJK1S4iV9Y43TbtXaVdLex9u 82VNL2OVra8l
ZitVO/8Axqtlqp/apr/stxK/nXSXutY+vH05PvLbWBk/stxK/nXSXutY+vH7 LcSv510l7rWP
rx9Oo+8ttYGT+y3Er+ddJe61j68fstxK/nXSXutY+vH06mPvLbWJPjR9zute z9/9O81v2W4k
/wA66S91rH15nan4f8QdQ6aymAu640xHWyVOanM+HS86PayRiscrVW8qIuzl 23RU/IzFuc2K
tLtzEw6ogAN7lgAAAAAAAAAAAAAAAAAAAAAAAAAAiuNPkZU7RYP4rUN0wuNP kZU7RYP4rUN0
pGLN+338JNjZIYXBbyMt9os58Vtm6YXBbyMt9os58VtjCXEudIL+yFqAC7ow AAAAAAAAAAAA
AAAAYd3OS19f4jTaQMdFfxV686VVXma6vLUYjUT0Kllyr/ahuE9fxFqbiThc 8xjVq08PkKcj
udEVHzTUnsTl2690rv69+rbz79QUIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADDu4OWxr/EakSdjYqGK vUXRKi8znWJa
j0ci+hErORf7kNwlsnkLsfFrT2KZYe2lYwOUsTQp/C+SOfHtY5fzRJZET+5S pAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAIrjT5GVO0WD+K1DdMLjT5GVO0WD+K1DdK RiziW+/hJsbJ
DC4LeRlvtFnPits3TC4LeRlvtFnPitsYS4lzpBf2QtQCW4t53IaZ4Z6iz+KY x12jQkmhV7OZ
rHIn8bk86N/iVPQil3RlSDgvEvUGptD18pVxOtr2aSxo6/l0sW2wPfTngdCk c7FjYickndXp
yqit3j+z5z9cQdWan0JPlYMRqazqBsumW5JJbaQO7zlW3DB3dqta1qMcyaR6 Nd9hO4L5twO8
H+Pc1jVe9yNa1N1VV2REP591HqbiHgcRqGp4Ut1JI6NKxWkyFunatwSyXWRK 9GwtRFie1zup
ydStXZevqcXJM7isZrvTdzUOVzeHixmFyVlbTY+7RVpr00d1qLExv2FhgVVR U6kV22wHYtOa
50ZqTJWMZp/VeFyt2sm80FS7HK9iIuyrs1VXbfq3NnG3qWSow38dcr3Kk7ee GevIkkcjfS1z
VVFT80JHOWOHseV0W6dlGS6+0rdOLS63N3hejlZ3Nf8Ag9z5ubfdn8O/mOU8 K72Y0poPhTk5
NU3pMfle7VbtOaKJa0VdtOzO1WtaxH8zVhb18yqu7vSiIH9GA/nfTOstWJqP Rth2V1HNR1JT
uSrLlVosjuNbUfPHNBXhVz4WorW7I52+zkR269Z98Jn9Y0dPaEztnWGSyM2p dKWrtyGxFAkU
czaTJ43xo2NFarXKqdarzJ4+sD+gT5XbValTnu3bENarXjdLNNM9GMjY1N3O c5epEREVVVfE
cI/aXWemcBp/UrtRZDUNnKaLv5WxQswxJC61DXhmj7kkbGuam73NVN13RU8/ WZWYz2s5NEZS
DKXZrVDM6LyduVb1+lI6VW1Uc2asyBEcke79lRd0RHM8Sou4f0fDJHNEyWKR skb2o5j2rujk
XrRUXzofojbOsdN6L0Rpy9qfJMx1W4yCpFM+Nzmd0WB0n2lai8reWN6q52zU 261Qq6FypkKU
N2hagt1ZmI+KaGRHskaviVrk6lT80A+5OZDMXYOJmDwEbmd5XMNkbkyK37Sy QTUmM2XzJtYk
3Tz9XoJONmp8/rTWEUWvM9h6mLysVOrVo1qCxtYtCpMqqs1aR6qr5nr1u222 RETY/wBm0LmJ
s5VzcnE7V7r9StNVgl73xn2IpnROkbt3nsu7oIl3VN05erbdd+PpGvNE0e5N uufzH+NkW6pj
OHTgcwkZqfAa00fFLr3PZiplMrLTtVb1agkbmJQtzIqLDWjeio+Fi9TtvGio u508n6LpVvSr
cXLc/h8VUzTOUgAJLAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAADGuWMM3XGLqzwb5qTG3JKkvJ/DXbLVSdu/m 3e+uu3n5fyNk
nMhh7s/EzB5+NrO8qeGyNOZVd9pJJ5qT2bJ502rybr5ur0lGAAAAAAAAAAAA AAAAAAAAAAAA
AAAAAAAAAAAAAARXGnyMqdosH8VqG6YXGnyMqdosH8VqG6UjFnEt9/CTY2SH POGN3X0On8jH
hNM6Zu0E1Fmu5T3NQT1pXf8AmdrfmjbTkRuy7omz13REXq32ToZhcFvIy32i znxW2MJcS50g
v7IfrwlxT/k3RnvXZ/28/wAkv8UJI3RyaK0U9jkVHNdqqyqKi+NFTweWgLuj OLag0Jqq5ofU
OmMFw24cadbnaclWxYoZyVjtnIqIqo3HJzbbrsiqbmGweqsLDdhxHCnhrj47 26W2Vs9LG2dF
RU2eiY77SbKvUvpU6aAOXYzTuo8XjrGNx3CPhjUpWntksV4c5KyOVzVRWq5q Y3ZytVEVN/Fs
mxrK/iKt2a6ugNB99Twtgmm/aaxzyRNVytY53g7dWor3qiL1Ir3elS7AHLNP aZ1Bp3IzZHT/
AAh4X4m5MitksU85JDI5FXdUVzcai7b+Y0IamuIa1CtDw14dxwY53NRjZqKZ G1V5XM3jRMds
xeV7m/Z26nKniVToYA5ZjNM5/GWEs47hBwuqTNe57ZIc3IxzXK1zVVFTG9W7 XvTq8znJ51Pf
3lrfvanW6M+HXcKMC16cf7QzcteJWcixxp4O2Y1WIjeVNk2TbxHRABAQs4gQ upOi4d6AjdRi
WGmrdSToteNURFZH/wCXfYaqNamybJs1PQZmN03qLGJfTHcIuGFRMjG6K6kO ckYlmN2/MyTb
G/aau67ovUu6nUgBynOS6vk1rw6q5/TenMZjmZ6ZsS47My23cyYm+iM7m+rE iN5d+tHLtsib
de6T2v00rpDUE9bhllcjj9azL3V2ntP10uV7DlVPtWqqqkUDV3TeVXQu2VV5 l8R1DiJoqjra
pi617KZfHJjr6XY5cZaWvK5e4ywuYsiJzNa5kz0XlVF6+pUPbo/SmnNH4lMX pnDVMXU35nMg
ZssjvFzPcv2nu9LnKqr6QOe8E7Opbkus7WsMbTxmekzsK3atSbusUT/BdDZG u8/VsqpuqIqq
m7tt16IS2jfLPiJ2ih+FY8qTy7XfPXP72Tbe7CW1l5Z8O+0U3wrIHQTn2svL Ph32im+FZA6C
XPDfI09Z+Ue9vAAO81AAAAAAAAAAAAAAAAAAAAAAAAAAAAGPrLU2H0jgX5vO 2H16Mc0ULnsi
dIqOlkbGxOVqKq7uc1OpANgEVNxO01BCj54M5G9lZLVuFcRYWSjCquRH2Gox ViReRyojutUT
fbbrPzqPino/BSXe+rN6xBj6jLd6zSoTWIKsT280avkY1WpzN60TfxKirsio oFuCHk4h4qlk
stFduLabDerU6VSlj5n2XSS1WzpGqJv3Ryt537tREa1OvrRVPHb4pUHak0jj MdjMnPDnrlmp
O99CZklR8LV3a9it3aqPROZV6kaiu606wOiAksXxF0tkclXp17NtG3FkbRtS 0pY61x0aKr2w
yuajJF2a5U2X7SNVW7oiqT2M4sU89qLSb9PQWJdN5uaSq+9bx08CPmdXdNB3 F7+Vrm/uZmO2
R32uVN084dOBxfGcX8xLp3XeTuY2i1+MqyX9ORxtf/42u6aevX5/tLzOdLAm /Lsm0rP6rr5T
ibcwV2lj79ZmVtzajhwtlMdQnRKqrRjsP36387uZ+7dlROR3nWNyqHUQc20V xVxuTSOpmo7F
a7Lnb2Ijmix86VO6xWpo4Y1lVFb3R0cbFX7WyuXbqVUaSUvEzXcWg8/rp+Y0 KynibWQY3EzU
p47E7KtiWJGJN3yqd0ekabfulTmcibAd2BHXuJGmqE0kV51+HvZkTshMlGV8 GPWRrXNbPK1q
sjXZzVXdfsoqK7ZFRT7ZbiFpjGZSzQtWLnLTlZDdtx0pX1akj0arWSzNarGK qPYq7r9lHIrt
kVAKsEzg9c4LNaryGm8a3Iz28bI+G5MlCVK0MreVVjWZW8nPs5FRu++3WUwA AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAJHK8RtMY7NXsPKmes28fI2K0lHT1+3HE90bJUaskML mb8kjHbIu6I5
NzFVUUxnMj15DMXYOJmDwEbmd5XMNkbkyK37SyQTUmM2XzJtYk3Tz9XoKM51 PrfRk2o6WffQ
1n37TqWKcKppHK8qRzvhe/dO9utd68ey+br9Jr4riNpjI5qjh4kz1a5kJHRV Uvaev1I5Xtjf
KrUkmhazfkje7ZV3VGrsfEXaJnKJZylXAA2MAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAi
uNPkZU7RYP4rUN0wuNPkZU7RYP4rUN0pGLOJb7+EmxskMLgt5GW+0Wc+K2zd MLgt5GW+0Wc+
K2xhLiXOkF/ZC1ABd0YAAAAAAAAAAAAAAABz7RvlnxE7RQ/CseVJLaN8s+In aKH4VjypPLtd
89c/vZNt7sJbWXlnw77RTfCsgdBOY8TcTis5qDQOLzeMpZOhPqKTutW5A2aK Tlxl9yczHIqL
sqIqbp40RTb6J+Fnq00Z7CrfIXPDfI09Z+Ue9vLMEZ0T8LPVpoz2FW+QdE/C z1aaM9hVvkO8
1LMEZ0T8LPVpoz2FW+QdE/Cz1aaM9hVvkAswRnRPws9WmjPYVb5B0T8LPVpo z2FW+QCzBGdE
/Cz1aaM9hVvkHRPws9WmjPYVb5ALMEZ0T8LPVpoz2FW+QdE/Cz1aaM9hVvkA swRnRPws9Wmj
PYVb5B0T8LPVpoz2FW+QCzBGdE/Cz1aaM9hVvkHRPws9WmjPYVb5ALMEZ0T8 LPVpoz2FW+Qd
E/Cz1aaM9hVvkAswRnRPws9WmjPYVb5B0T8LPVpoz2FW+QCzBGdE/Cz1aaM9 hVvkHRPws9Wm
jPYVb5ALMEZ0T8LPVpoz2FW+QdE/Cz1aaM9hVvkAsyX4m6du6n07Wx1CWvHL Fl8ddcs7lRqx
17cUz06kX7StjciebdU3VE6zydE/Cz1aaM9hVvkHRPws9WmjPYVb5AJHXfDD K39bZ7PYuhic
ozO14GOS/lLVTvKWONY+bkhRUmYreVeRVYu6L9rZ3VFcSJV0PhdeaKwl3BOn zmGjiio2nTQW
nTJQbVRtKFGP75a9sUbUTnTububmVydR2Pon4WerTRnsKt8g6J+Fnq00Z7Cr fIBI5jhpm7iZ
qaTHaey0OQyVC42jfnmiXkgosgdyzRtV0EqParmvajurqXbmXb/MNw+1tSXT Fqzcq3n4zMXZ
X1LOXnndVo2YViSOOy+NXyvjReZOdG778u6IiKV/RPws9WmjPYVb5B0T8LPV poz2FW+QCB0D
wgymCkwGOvY3AyVcCqrHlPCNuaa0jY3MiVKzkSOB+zkVzkc9OpURNndW3keH Wo14Aae0bjMh
j62qcDVoLUuK9/e7bNfkRy7o3m5XNR7d+XfZ3iKPon4WerTRnsKt8g6J+Fnq 00Z7CrfIBP5/
hU6a5oSvh7NWvisDFFTyUciKjrVaGSCeFqIiKiqk1Zm/MqJyySePfZf8z2gt SrlbeYxbsVYs
ftpBqCvBPYkia+BuOiqOY56Ru5X7te5NkcmyN603Xah6J+Fnq00Z7CrfIOif hZ6tNGewq3yA
Y0fD/Mt0lhsStmh3ejrCXOSu538qwOyM9lGovLvz8krU2VETmRevbrX7cNOF mC0/QknzmndO
Xc47K3rqZBlJkkqNltSSxfvHMR/M1j2p+Spsiqmymn0T8LPVpoz2FW+QdE/C z1aaM9hVvkAh
tV8I8nc1BqZ9PH4TJ0tRWksrYyGStxOpK6NkcrHV4k5LDVRm7d3MX7StVdkR T8Zvg7dly+fr
VcXg7+Mzd7vpbV3JW2OqMc1jZY1rR/YnT7LlaqvZ/EiL/D13nRPws9WmjPYV b5B0T8LPVpoz
2FW+QD16A07d0/PqaS5LXemVzs2Rg7i5V5Y3xxtRHbomzt2L1Juni6yoIzon 4WerTRnsKt8g
6J+Fnq00Z7CrfIBZgjOifhZ6tNGewq3yDon4WerTRnsKt8gFmCM6J+Fnq00Z 7CrfIOifhZ6t
NGewq3yAWYIzon4WerTRnsKt8g6J+Fnq00Z7CrfIBZgjOifhZ6tNGewq3yDo n4WerTRnsKt8
gFmCM6J+Fnq00Z7CrfIOifhZ6tNGewq3yAWYIzon4WerTRnsKt8g6J+Fnq00 Z7CrfIBZgjOi
fhZ6tNGewq3yDon4WerTRnsKt8gFmCM6J+Fnq00Z7CrfIOifhZ6tNGewq3yA WYIzon4WerTR
nsKt8g6J+Fnq00Z7CrfIBZgjOifhZ6tNGewq3yDon4WerTRnsKt8gFmQ3Fmz qVljSON0tnGY
W3k846vJYkqNsMdGyhbn5HMdtu1XQs35Va7bxKh9uifhZ6tNGewq3yEjxC0p pnQ2a0XqfR3D
CtJcq517J2adw0LLLopMfcjRHOajUbH3R8W6ucjU6lXxIBtt4h5XTDkr8TsA uHiReVM7jldZ
xb/zeu3dK3/1E5U/51Pzw+uVMhqfX92hagt1ZtQQPimgkR7JGrisfsrXJ1Kn 5oed+m+Ieu41
/bTLt0lg5U+1gsFPz2pWrtu2xd2TbxKithRvUu3Op8uEWnsLpTJa40/p7HxY /F0s/EyvXi35
WIuLoOXrVVVVVVVVVVVVVVVTg4j5Grt8ttneXpLay8s+HfaKb4VkCpJbWXln w77RTfCsgU3U
kz99b/vZIubsuggA9QQgAAAAAAPw2WJ0r4WyMWRiIr2I5N2ou+yqnm32X/7A fsAAAAAAAAAA
AAAAAAAAAAAAAAAARXGnyMqdosH8VqG6YXGnyMqdosH8VqG6UjFnEt9/CTY2 SGFwW8jLfaLO
fFbZumFwW8jLfaLOfFbYwlxLnSC/shagAu6MAAAAAAAAAAAAAAAA59o3yz4i doofhWPKkltG
+WfETtFD8Kx5Unl2u+euf3sm292EtrLyz4d9opvhWQOgnPtZeWfDvtFN8KyB 0EueG+Rp6z8o
97eAAd5qAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA
AAAAAAAAAAAAAA59o3yz4idoofhWPOgnPtG+WfETtFD8Kx5wcR8jV2+W2zvK kltZeWfDvtFN
8KyBUkTxNkysOoNAyYSnSu301FJ3KC5bdWif/wCWX9+aRscit2TdU2Yu6oid W+6UzUnPW+vh
IubsunAjPCXFP+TdGe9dn/bx4S4p/wAm6M967P8At56ihLMleL2dyOmOF+pN QYiNsl+hjpp4
OZvM1rmtX7ap50b/ABKnoQ83hLin/JujPeuz/t5/kl/ijIx0cmi9FPY5FRzX aqsqiovmX/y8
CG19czumcY2ph+KV69fyMuJ7m2zWryywtmyEML7DHNYje5vbIreRWqnVu1U6 zP1Fmtc0tTam
07j8znJa+l8dBNDeku0InPWSN8i2LPdWJ3RiKnJs1Gt2jdv9pd0q8XpvUOKr zV8bwh4X04Zp
o7EscGbkY18kbkfG9UTG7K5rkRzV/wAKpumx9s/hdWagt17ed4VcNspYq/8A AluZ+aZ0fXv9
lXY5VTr6/wCoHP8AiPrrVj9OaizOMyuaiuYHCVrVnwa+lFjaNt1VJ+V75ldJ Z5+dn2WN5eVW
tT7Sqp+c5nM3pvUHEPUuLylx9u1Jga7kc6FIqzLXc2OmTnbsisa5yNV6q1N9 3bohfZXT2pct
kn5LK8JOGN+6+PuT57Odlke5myojVV2NVVTZVTZfMqn1fh9WyX5b7+FnDZ1q al4PlmXPzK99
XqXuDl8HdcfUn2F6upOoD9cKslqr9rc7gc9LO+rWq1rEEd69WnuwPkWRHNf3 BETubkY1zeZN
9+frVNtuknONOY/Wmm6b6enuGfDvE15H90fFS1FPC1zttuZUbjk3XZETf8jU 8JcU/wCTdGe9
dn/bwNXW2sdN6LpU72p8mzHVblpKkUz43OZ3RWPk+0rUXlbyxvVXO2am3WqG vQuVMhShu0LU
FurMxHxTQyI9kjV8StcnUqfmhzLUNnWdnXXDyLUuntPUKa5+flko5qa49z/B WQ2arH1YkRu3
N18y+JE2XfdJzX6aV0hqCetwyyuRx+tZl7q7T2n66XK9hyqn2rVVVSKBq7pv KroXbKq8y+IC
glk1Vm9cawgh15nMPTxeUhp1atKrQcxrFoVJlVVmrSPVVfM9et3oRETY9PgX VfrU1b/pMV9E
YnCGzqW5b1la1hjaeMz0mbhW7VqTd1iif4LobI13n6tlVN12VVTd2263hoqq mJdWxYt1W4mY
T3gXVfrU1b/pMV9EPAuq/Wpq3/SYr6I8mqdRZyprLEaYweLpWpchRtW5LFqw 6NldsL4W/wAL
Wqrt1mRNk226ifxvETUGayOKxeJ07j2Xpo7rsklvIObHUdTstrzNa5sarJu5 32epOpUVdvEY
9VT6m1ZicslX4F1X61NW/wCkxX0Q8C6r9amrf9JivoiXxnELO2cdgs/Pp+jB gtQ2GV8c5Lrn
WI1lR3e8kre58qNeqN3RqqrOdP4tl2yeHGttZZHTuAxbqmNyGfyUNy6+xPae 2GKtFMkfM/aP
dXq+RGo1qbcqb79WwzqY+nZ/S+8C6r9amrf9Jivoh4F1X61NW/6TFfREtjOI ebz1qnhcHgqE
ec2urko7t1yQVVqzpA5GvZGqyc713auyfZRVXr6j7t1nrG9Yt0cZpKhHkMVR hs5SvcyeyJNI
j3JXifGxyOXlZvzrsn2m9Xj2eqpn6dn9KLwLqv1qat/0mK+iHgXVfrU1b/pM V9ETnDHUr9T6
zzmRgsWlxlrDYe7UryvVWw92ZYc7Zu+zXLs3fbx8qeg6IPVVDNNm1VGcQ/HB 7I5TJ6ISfM5K
bJ3Icpk6a2po42PlZBfnhjVyRtazfkjai8rU3232LAh+B/kLY7QZv4rbLg3x scmqMpkABl8g
AAiuNPkZU7RYP4rUN0wuNPkZU7RYP4rUN0pGLOJb7+EmxskMLgt5GW+0Wc+K 2zdMLgt5GW+0
Wc+K2xhLiXOkF/ZC1ABd0YAAAAAAAAAAAAAAABz7RvlnxE7RQ/CseVJLaN8s +InaKH4VjypP
Ltd89c/vZNt7sJbWXlnw77RTfCsgdBOfay8s+HfaKb4VkDoJc8N8jT1n5R72 8AA7zUAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAB
z7RvlnxE7RQ/CsedBOfaN8s+InaKH4Vjzg4j5Grt8ttneVJLay8s+HfaKb4V kCpJbWXlnw77
RTfCsgUzUnPW+vhIubsuggA9RQgAAAAAAAAAATHETRVHW1TF1r2Uy+OTHX0u xy4y0teVy9xl
hcxZETma1zJnovKqL19Soe3R+lNOaPxKYvTOGqYupvzOZAzZZHeLme5ftPd6 XOVVX0m0AOY6
c8uuIfaCH4VQKEgY9Y6R0/xG4g0s9qnB4m0/OQSthu5CKB7mLi6KI5Gvciqm 7VTf8l9BpdJ3
Db1haS9s1/nI1UTm7Gj10xbj8vFrLSuYzXEfAZihlLuJr0MZehkt1HRK9JJX 11YxWSNc1zVa
x69bV2VEXqXY0tM6HxGn7tC5SmuyTU6dmrzTSo9ZlsTMnllkXbdZHSM33RUT 7S9Xi2+XSdw2
9YWkvbNf5x0ncNvWFpL2zX+cx+X3nRnnm82J4c47H28a1uZy8+IxVhbGNxEr 4lrVX7ORuyox
JHNZzLytc9yN6vQm3nx3DKpjIKaYvUmcpWqElnvK0zvd0kME7mvkrbOiVr4+ ZqOTnRzkX/F5
jR6TuG3rC0l7Zr/OOk7ht6wtJe2a/wA4/J/z/byw8N8fShoPw2azGLyNNthq 5GJ0Uk9lLEiS
zd17pG5j1dIiO35U2XxbJ1H4fw1oxRKzE6iz+JdPTbTvS1543yXY2q5UdI6W N+z/ALb/ALbO
VftbeZu3t6TuG3rC0l7Zr/OOk7ht6wtJe2a/zj8n/P8Ab2aX0hiNN37FrFJN G2alUopA5yLH
FFWa9saN6t99nrvuq77J4vPQEn0ncNvWFpL2zX+cdJ3Db1haS9s1/nGUvqKq Ij8SoeB/kLY7
QZv4rbLggeAVqte4crdpWIbNWxnMzLDNC9HskY7KWla5rk6lRUVFRU8ZfEmN jiVb0gAMvkAA
EVxp8jKnaLB/FahumFxp8jKnaLB/FahulIxZxLffwk2NkhhcFvIy32iznxW2 bphcFvIy32iz
nxW2MJcS50gv7IWoALujAAAAAAAAAAAAAAAAOfaN8s+InaKH4VjypJbRvlnx E7RQ/CseVJ5d
rvnrn97JtvdhLay8s+HfaKb4VkDoJz7WXlnw77RTfCsgdBLnhvkaes/KPe3g AHeagAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAOf
aN8s+InaKH4VjzoJz7RvlnxE7RQ/CsecHEfI1dvlts7ypJbWXlnw77RTfCsg VJLay8s+HfaK
b4VkCmak56318JFzdl0EHyt2a9StJatzxV4Imq+SWV6NYxqeNVVepE/MztLa kw2qMfJkMDc7
9pMmWFLDYntilVERVWNzkRJGdf8AGzdqqioi7op6ihNYAAAAAAAAAAAAAAAA AKAJHQckj9Vc
QGvnWVseoYmsaqqvck8F0F5U38XWqu6ur7Xp3I7h3S1hqLh/pzUF7ilqqO1k 8VVuTshp4tGN
fLE17kai01VE3cu26qu3nU0cdobMY+5krdTidq+KbJ2UtXHd74xe6SpDHCjt lp7J+7hjbsmy
fZ38aqq8S5iDQrdU01VfmP8AJbItVS6cCB0BNnavEHUOn8pqfJZ6rWxWOuV3 3oKrHxPmlusk
RFghjRUVII/4kVUVF6+svjrWb1N63FyjZL4mJicgAG1gAAAAAAABFcafIyp2 iwfxWobphcaf
Iyp2iwfxWobpSMWcS338JNjZIYXBbyMt9os58Vtm6YXBbyMt9os58VtjCXEu dIL+yFqAC7ow
AAAAAAAAAAAAAAADn2jfLPiJ2ih+FY8qSW0b5Z8RO0UPwrHlSeXa7565/eyb b3YS2svLPh32
im+FZA6Cc+1l5Z8O+0U3wrIHQS54b5GnrPyj3t4AB3moAAAAAAAAAAAAAAAA AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAACd1brTAaWu0qWWkyLrV6OWWvDSxdm69zIljSRytgje rURZY03Xb+JA
R+VECH6VNKf5XVvuhlfph0qaU/yurfdDK/TGM4fXoq/S4BD9KmlP8rq33Qyv 0w6VNKf5XVvu
hlfphnB6Kv0uAQ/SppT/ACurfdDK/TDpU0p/ldW+6GV+mGcHoq/S4BD9KmlP 8rq33Qyv0w6V
NKf5XVvuhlfphnB6Kv0uAQ/SppT/ACurfdDK/TDpU0p/ldW+6GV+mGcHoq/S 4BD9KmlP8tq3
3Qyv0x8bvF7RdGnPdupqetVrxulmmm0nlGMjY1N3Oc5a+yIiIqqq+IZwemr9 L4AGXyAGBqrV
2I05ap0rjb1q/dbI+tTo05LM8jI+XnfysRdmt5m7quybuRPGqIBvgh6nFbRt 3J0sdQtXrkty
pFdR0NCZzIa8jpGpLM7l2ia10bmu59uVfHserEcRtK5OVrY7VurFNWkt1Z7t KWvDagYiOfJE
+RqI9qNVHdXXsu/i6wK4HPLnFvTzMbfnq0s0tmLETZalDZxc8CXoY0arnRK5 nWiK9m/VuiPR
dtj7YvihhZtO4i/cqZbv69jWZCenVxdiaWvEvUsj2NYrmsVyO5VXreiKrd9l AvQefGXqeUxt
bJY6zFap2omzQTxO5mSRuTdrkXzoqKinoAHPtG+WfETtFD8Kx50E59o3yz4i doofhWPODiPk
au3y22d5UnP+MdjUFW7oqxpXH0sjmmZ6Zala5OsMUjvBd/dHPRF26t1ROrdU RN277p0AltZe
WfDvtFN8KyBTNSc9b/vZIubsuUaSt6v1VqCOrxEwWnclqiN3dIsDnNQ2KVeH Zf4oKiUXRTon
/qc86p/zp4jsjchxSa1Gt0ZotGomyImqrOyf/wAeUGptPYPU2NXHZ/F1cjVV yORk8aO5HJ4n
NXxtcnmcioqeZT8aTwSaexr8fHlsrkYO6q+BcjY7vJAxUREjSRU53NTZVRXq 53Wv2lTZE9RQ
mH4S4p/yboz3rs/7ePCXFP8Ak3RnvXZ/28swBGeEuKf8m6M967P+3jwlxT/k 3RnvXZ/28swB
GeEuKf8AJujPeuz/ALePCXFP+TdGe9dn/byzAEZ4S4p/yboz3rs/7ePCXFP+ TdGe9dn/AG8s
wBGeEuKf8m6M967P+3jwlxT/AJN0Z712f9vLMARnhLin/JujPeuz/t48JcU/ 5N0Z712f9vLM
ARnhLin/ACboz3rs/wC3hclxT28jdGe9dn/byzCiRzjgl9zOiOztD9PGV5zj h3d1hp3h/pzT
97hbqqS1jMVVpzvhuYtWOfFE1jlaq3EVU3au26Iu3mQ1Ketc1cs3a9XhlqyW WjOle0xtvFbx
SLGyVGr/AON8fJIx39HIea6VqbTa71dVNH4mZ/SZTcpy2tDS/wB8+qOzuH/U 5MuyB0BDnbXE
HUOoMppjJYGrZxWOp12Xp6r3yvhluvkVEgmkRERJ4/GqKqqvV1F8XzVtqq1o tFFcZTEItc51
SAAnPkAAAAAAABFcafIyp2iwfxWobphcafIyp2iwfxWobpSMWcS338JNjZIY XBbyMt9os58V
tm6YXBbyMt9os58VtjCXEudIL+yFqAC7owAAAAAAAAAAAAAAADn2jfLPiJ2i h+FY8qSW0b5Z
8RO0UPwrHlSeXa7565/eybb3YS2svLPh32im+FZA6Cc+1l5Z8O+0U3wrIHQS 54b5GnrPyj3t
4AB3moAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADnmtvvi0r 2fzH6jGnQznm
tvvi0r2fzH6jGnzXsbrHEhozWa0MsUU1iKOSVdo2veiK9fQiL4z/AF88DJmQ vmjbLJvyMVyI
523j2TznEuNmIWTVmTyEOJuX7U2Jihhq2tPSZGpdVrpFbHFNCqSVZOZ3W5XN Tra7ZeXcx9Wa
ezlzN6mbmKeRjyWRngfinVMCt6VsfcY0Y2G7ujYHRSI9V5lYiLu/r5jRk6k3 Jidj+g33KjJm
wPtQNlcuyMWREcq9XVt/3T/7oft0sTXOa6ViKxvO5Fcn2W+lfy6lOSt4dwZy PiBYtYuOHP2c
nvi8rYrIkrFjrVnQyRuVN0YkzVVeXqVUchP5bEao1FpL9sclhruPtZXPVZsl jpKC2ZYMdXjf
HHG6v45USZe7KxN1VHL1LtsMmZrmPZ3dbdVK7bK2YUgcm7ZOdOVU23338XiR V/7ErmddMgzM
+IwGnstqa5UjjluJj1hbHXa9vMxFfLIxquc37SNaqrsqL1bpvzGvpB2TbjYp MXeyOEsavr2Z
K82DWlW7m2nM18iV162ROcrEcr2tRzt+pebdavB2Y+HGqdT0bmAy3gfJ2472 LsYvFS2o0RK0
UK11bA1yxq1YfsoqI3ZybL1KMmPXM/4p8JxAwGWsYqGv31F4Rp2rbXWI0iSB K8scUscqOXdr
0fIibbKn2Xdfi3prFypXrtsWLUEMLttpHyI1q7+LrXqOXx467rLiBpPNaq0c terHi8o5te1F
3VsHNPWSDu26crZXRo53Iu+you3W3qjcdichWo6dxeR0t3tWqQZJsNu5p6xk +5I689GV467V
RsSrEjHNkei7t2ROrcZMeuY9n9BT26kEfdJ7UETOXm5nyIibendfMJ7lSuxX z2oImoiLzPkR
qbL4l6zh3CfR0ly7pWPVel5pa9LS9ms6PJUN44Ze/NmsVrkVqO7nvsif4VXb qU/fCrRSXbun
o9WaYlnr1tFwVFZkqblZHL3eRFjVHpsj0Zt1eNEX0KMmYuTPs7hNPBCjFmmj jR7ka1XuROZV
8SJv41ILi9naljRHEPTbI50t0tJz3JXq1O5qyaGw1qIu++6LC7fdE8ada9e3 KsXgc9DjNPS6
qo3+9E0jTp1optNSZR0U7efu0Lo0+1DI5Fi+05ERyNRN05TbvYfMYzQ+unZS HJuROGteutm8
z7b5WRXuZjnoqtdI1HM5tnL40Xz7mYjJ8VXJqjY7hmOJGMbkpcJpSja1bm4l 5Ja2NVqw1nf+
/Yd+7i/oqq/0NUztPXNfw8VcXS1XlcYlTJYPIWkxWOgVYqz4J6TWKsz/ALcr tp3oq7Mb/wBP
nPmzhpkdI89jhRnG4OFXOkfgb7XWMVK5VVV5G790rKqrvvG7l/6FMZakuv8A ivhKHELhekTM
Tg8ksvf9aK/jXyyWKKRvgmVFarlbHL1Oax6Jv1bKSHIdmIjV+A1CzXmM1rpi HG3rVbG2MZYo
37T67HxSSRSNeyRscnK5routFbs5HeNFRN/p0T8LPVpoz2FW+QdE/Cz1aaM9 hVvkAyMdoPUN
7IaktaqylGZ+f0zXxE8tJrmujka+2sitaqInKjbLEau+68qqqITWm+Fep8fD XbFBp/EZHGYm
zVpZaG/buSPtPgWKOdsUqIyBqbq5Wosm+/Ki7JuXnRPws9WmjPYVb5B0T8LP Vpoz2FW+QCAx
nCjVEmcgyN3wfVX9nb+JtSS525k555rDYkSXnnYmzUWNfsJttuq9fiT8N4W6 pbLQzFjE4HIZ
F2Cq4m3UdnbdeKCSssiRTxyxRIsjXNk3dG5jVaqfZcvWq9C6J+Fnq00Z7Crf IOifhZ6tNGew
q3yAbeicIzTekMTgY21mpQqRwKlaNY4t2tRF5Gqrla3ffZFVdvSbBGdE/Cz1 aaM9hVvkHRPw
s9WmjPYVb5ALM59o3yz4idoofhWPPd0T8LPVpoz2FW+QxOGWJxWD1Br7F4TG UsZQg1FH3KrT
gbDFHzYyg5eVjURE3VVVdk8aqpwcR8jV2+W2zvLYltZeWfDvtFN8KyBUktrL yz4d9opvhWQK
ZqTnrfXwkXN2XQQAeooQAAAAAAAAAAAAAAAAAABLaJx92nqXXVm1XfFFfz0V iq93iljTG0Yl
cn5c8b2/1apUmHpnOS5bNaooSQMjbhcqyjG5qqqyNdSrWOZfQu9hW/0agG4A AAAAAAAAAAAA
iuNPkZU7RYP4rUN0wuNPkZU7RYP4rUN0pGLOJb7+EmxskMLgt5GW+0Wc+K2z dMLgt5GW+0Wc
+K2xhLiXOkF/ZC1ABd0YAAAAAAAAAAAAAAABz7RvlnxE7RQ/CseVJLaN8s+I naKH4VjypPLt
d89c/vZNt7sJbWXlnw77RTfCsgdBOfay8s+HfaKb4VkDoJc8N8jT1n5R728A A7zUAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABzzW33xaV7P5j9RjToZGa70 nnMzqXD5/AZ7
HYuzjqdum9l3GPuMlZO+u9VRGTxK1WrXTzrvzL1GKozhstVRTXEy+wMn9luJ X866S91rH14/
ZbiV/Oukvdax9eaPp1Ol95bawMn9luJX866S91rH14/ZbiV/Oukvdax9ePp1 H3ltrAyf2W4l
fzrpL3WsfXmRqylxE09i4b82rtKztlyFKijWaXsIqOs2oq7Xdd/xIsqOX8kU fTk+8tq0GT+y
3Er+ddJe61j68fstxK/nXSXutY+vH05PvLbWBk/stxK/nXSXutY+vH7LcSv5 10l7rWPrx9OT
7y21iT40fc7rXs/f/TvNb9luJP8AOukvdax9eZ2p+H/EHUOmspgLuuNMR1sl TmpzPh0vOj2s
kYrHK1VvKiLs5dt0VPyMxbnN81aXbmJh1RAAb3LAAAAAAAAAAAOfaN8s+Ina KH4VjzoJz7Rv
lnxE7RQ/CsecHEfI1dvlts7ypJbWXlnw77RTfCsgVJLay8s+HfaKb4VkCmak 56318JFzdl0E
AHqKEAAAAAAAAAAAAAAAAAAAZOCwcWJymfvxzvkdmsgy9I1yIiRubVgr8qel Nq6O/q5TWI/Q
Essmq+ITJJXvbFqKFkaOcqoxvgrHu2T0Ju5V29Kr6QLAAAAAAAAAAAAABFca fIyp2iwfxWob
phcafIyp2iwfxWobpSMWcS338JNjZIYXBbyMt9os58Vtm6YXBbyMt9os58Vt jCXEudIL+yFq
AC7owAAAAAAAAAAAAAAADn2jfLPiJ2ih+FY8qSW0b5Z8RO0UPwrHlSeXa756 5/eybb3YS2sv
LPh32im+FZA6Cc+1l5Z8O+0U3wrIHQS54b5GnrPyj3t4AB3moAAAAAAAAAAA AAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAT2q9ZYLTF2lRyjsk+1ejllrwUcVauv cyJY0kcrYI3q
1EWWNN12TdyENxI17iMrp6rVxuK1dPOzNYqy5q6QyabRQ5CvLK77Vfb7MbHu 9PV1dexv6o++
fS/Z3MfqcYUZWta6+q0G/wDSijP8Z7W6i16ozTl7izo+hSnu3otVVateN0s8 02ksoxkTGpu5
znLX2RERFVVXqRELs5xxt+5nW/Z2/wDp5Do6eInao1lVrC3VXNOWU5Pm5R6Z AAddrAAAAAAA
AAAAAAAAyNV0c3fxrWafzqYa9FKkjJX1W2IpURFTucjF2VWLuiryOY7dE2d4 0UNc59o3yz4i
doofhWPP03X1/Trkr8R8IuFYi7JmabnWMY/83v2R9f8A+q1Gp4ke4+GgrNe5 qriBaqWIrFeX
UED45Yno5j2risfsqKnUqHBxHyNXb5bbO8riW1l5Z8O+0U3wrIFSS2svLPh3 2im+FZApmpOe
t9fCRc3ZdBAB6ihAAAAAAAAAAAAAAAAAAAGZhsljb2RzdWizlsY682teXufL zTLXhlRd/wDF
+7liTf8ALbzGmTmkcPdxmoNY3bTWJFlszHcqq126rG2hUgXf0LzwP6vRsvnA owAAAAAAAAAA
AAEVxp8jKnaLB/FahumFxp8jKnaLB/FahulIxZxLffwk2NkhhcFvIy32iznx W2bphcFvIy32
iznxW2MJcS50gv7IWoALujAAAAAAAAAAAAAAAAOfaN8s+InaKH4VjypJbRvl nxE7RQ/CseVJ
5drvnrn97JtvdhLay8s+HfaKb4VkDoJz7WXlnw77RTfCsgdBLnhvkaes/KPe 3gAHeagAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABCao++fS/Z3Mf qcYUZ5tV6NwW
p7tK9lG5JlqjHLFXno5W1Se1kqxrI1XQSMVyKsUa7Lum7UIjiLojC4PT9W7Q v6sbLJmcXTcr
9XZVydzsX68En/8AU+PkkdsvmXZSta11FVp1/wCrFeX4y2N1F30xk0eNv3M6 37O3/wBPIaic
J+Fm33aaM9hVvkPPe4TaPv0p6V6XVVqrYjdFPDNq3KPZKxybOa5q2NlRUVUV F6lRS7J2qNW1
avt1UTVnnOb5uV+qUZ0T8LPVpoz2FW+QdE/Cz1aaM9hVvkLMHXa0Z0T8LPVp oz2FW+QdE/Cz
1aaM9hVvkLMARnRPws9WmjPYVb5B0T8LPVpoz2FW+QswBGdE/Cz1aaM9hVvk HRPws9WmjPYV
b5CzAEZ0T8LPVpoz2FW+QdE/Cz1aaM9hVvkLMARnRPws9WmjPYVb5B0T8LPV poz2FW+QswBG
dE/Cz1aaM9hVvkMjVeguFuBxrbUfB3A5eeWVIYauP03Wkke9UVU3VWoyNvUu 73ua1Orr3VEX
pQA4a3gXhdVOSXU+jNG6YxirumJweKr98vT0TXO5o5P7YUZt/wA7kN/hPgsP pnLa6wWAx1fH
YypqCJsFaBvKxiLi6Dl/7qqqqqvWqqqr1nUzn2jfLPiJ2ih+FY84OI+Rq7fL bZ3lSS2svLPh
32im+FZAqSW1l5Z8O+0U3wrIFM1Jz1vr4SLm7LoIAPUUIAAAAAAAAAAAAAAA AAAAnNI5i7k9
QaxpWnMWLE5mOnVRrdlSN1CpOu/pXnnf1+jZPMUZmYbG42jkc3aov5rGRvNs 3k7pzcsyV4Yk
Tb/D+7iiXb89/OBpgAAAAAAAAAAAAIrjT5GVO0WD+K1DdMLjT5GVO0WD+K1D dKRiziW+/hJs
bJDC4LeRlvtFnPits3TC4LeRlvtFnPitsYS4lzpBf2QtQAXdGAAAAAAAAAAA AAAAAc+0b5Z8
RO0UPwrHlSS2jfLPiJ2ih+FY8qTy7XfPXP72Tbe7CW1l5Z8O+0U3wrIHQTk/ GPUFLSt3ROoc
jDdmqUc9NJKynWdPKqeC76fZY1FVfH1r4kTdVVERVJrFcU73EWjHkK8+p9Ma bn64/BOl8jdv
2W/nYbWdDCn5R90X0Papc8N8jT1n5R72877unp8QOa6U1PoTS+NfQwuD1pBH JKs0z36RzMss
8qoiLJJI+urnvVGonM5VXZETzGv0l6c/DdZ+5mW+mO81LMEZ0l6c/DdZ+5mW +mHSXpz8N1n7
mZb6YCzBGdJenPw3WfuZlvph0l6c/DdZ+5mW+mAswRnSXpz8N1n7mZb6YdJe nPw3WfuZlvpg
LMEZ0l6c/DdZ+5mW+mHSXpz8N1n7mZb6YCzBGdJenPw3WfuZlvph0l6c/DdZ +5mW+mAswRnS
Xpz8N1n7mZb6YdJenPw3WfuZlvpgLMEZ0l6c/DdZ+5mW+mHSXpz8N1n7mZb6 YCzBGdJenPw3
WfuZlvph0l6c/DdZ+5mW+mAswRnSXpz8N1n7mZb6YdJenPw3WfuZlvpgLMEZ 0l6c/DdZ+5mW
+mHSXpz8N1n7mZb6YCzBGdJenPw3WfuZlvph0l6c/DdZ+5mW+mAswRnSXpz8 N1n7mZb6YdJe
nPw3WfuZlvpgLMEZ0l6c/DdZ+5mW+mHSXpz8N1n7mZb6YCzBGdJenPw3WfuZ lvph0l6c/DdZ
+5mW+mAswRnSXpz8N1n7mZb6YdJenPw3WfuZlvpgLMEZ0l6c/DdZ+5mW+mHS Xpz8N1n7mZb6
YCzBGdJenPw3WfuZlvph0l6c/DdZ+5mW+mAswRnSXpz8N1n7mZb6YdJenPw3 WfuZlvpgLMEZ
0l6c/DdZ+5mW+mHSXpz8N1n7mZb6YCzBGdJenPw3WfuZlvph0l6c/DdZ+5mW +mAszM1Njcbl
cdFVyr+Suy9UssXunJ++hsRywpv+cjGJt599vOT/AEl6c/DdZ+5mW+mJbijr zDZHTVSvUxes
HSMz2Hncj9I5RickWSrSPXd1dE3RrHKieNV2REVVRFDrgIzpL05+G6z9zMt9 MOkvTn4brP3M
y30wFmCM6S9Ofhus/czLfTDpL05+G6z9zMt9MBZgjOkvTn4brP3My30w6S9O fhus/czLfTAW
YIzpL05+G6z9zMt9MOkvTn4brP3My30wFmCM6S9Ofhus/czLfTDpL05+G6z9 zMt9MBZgjOkv
Tn4brP3My30w6S9Ofhus/czLfTAWYIzpL05+G6z9zMt9MOkvTn4brP3My30w FmCM6S9Ofhus
/czLfTDpL05+G6z9zMt9MBZnPtG+WfETtFD8Kx57ukvTn4brP3My30xicMsn WzGoNfZGpHdj
hm1FHytuUpqsqbYyg1eaKZrXt60XbdqbpsqdSopwcR8jV2+W2zvLYltZeWfD vtFN8KyBUktr
Hyz4d9opvhWQKZqTnrf97JFzdl0EAHqKEAAAAAAAAAAAAAAAAAAAR+gIpY9V 8QnyRPY2XUUL
41c1UR7fBWPbunpTdqpv6UX0FgZOCzkWWymfoRwPjdhcgyjI5yoqSOdVgscy ehNrCN/q1QNY
AAAAAAAAAAAABFcafIyp2iwfxWobphcafIyp2iwfxWobpSMWcS338JNjZIYX BbyMt9os58Vt
m6YXBbyMt9os58VtjCXEudIL+yFqAC7owAAAAAAAAAAAAAAADn2jfLPiJ2ih +FY8qSW0b5Z8
RO0UPwrHlSeXa7565/eybb3YS2svLPh32im+FZA9uZ4eYyTJTZvTN21pXNzO 55beN5Ujsu/9
+ByLHN/cqc+3ich4tZeWfDvtFN8KyB0EueG+Rp6z8o97eZGk01K3Gvi1SuKk uxyq1k+O52xz
x7Js9Y37rG5V3RWI56Jsi83XsmuAd5qAAAAPxLLFCjVlkZGjnIxFc5E3cq7I n9VXqA/YAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABk6szkWnsXDfmgfO2 XIUqKNYqIqOs
2oq7XdfmRZUcv5IprGHrjBy6hwtehDOyB0WVx15XPRVRW1rsNhzerzqkStT8 1QDcAAAAAAAA
AAAAAAAAAAAAADkGO1no/TvEDiDR1BqvBYi0/PQSsgvZGKCRzFxdBEcjXuRV Tdqpv4t0X0HX
wQ9P0KnTLM2qpyiX1TV6Zzc46UuGXrF0h7ar/OY+R1no/UXEDh9R0/qvA5e0 zPTyugo5GKeR
rExd9FcrWOVUTdyJv4t1T0lflpZW8aNMwNkekT9O5d7o0cvK5zbONRFVPOqI 52y/mvpLA5Oi
Yds6Lepu01TMw+6rszGQACxNQAAAAAAAAAAAAAAAAAABh6ZwcuJzWqL8k7JG 5rKsvRtaiosb
W0q1flX0rvXV39HIbhLaJyF25qXXVa1YfLFQz0Veqx3iijXG0ZVan5c8j3f1 coFSAAAAAAAA
AAAAAiuNPkZU7RYP4rUN0wuNPkZU7RYP4rUN0pGLOJb7+EmxskMLgt5GW+0W c+K2zdMLgt5G
W+0Wc+K2xhLiXOkF/ZC1ABd0YAAAAAAAAAAAAAAABz7RvlnxE7RQ/CseVJLa N8s+InaKH4Vj
ypPLtd89c/vZNt7sJbWXlnw77RTfCsgdBOY8TZMrDqDQMmEp0rt9NRSdyguW 3Von/wDll/fm
kbHIrdk3VNmLuqInVvum34S4p/yboz3rs/7eXPDfI09Z+Ue9vLMEZ4S4p/yb oz3rs/7ePCXF
P+TdGe9dn/bzvNSUmy+Wyea1plL2u7Ol4dN5qGlWqpBFJXSHuUD+aZit55O7 LK5qbOTZNuXr
Rd5izqXW9PSMuo49S5S7YymsLOAigTvaOKjWbfnja5ivZt3VUjSNHyKqfvG/ ZVUQucjhtWZH
OV87kOFfDa3la23cLs2fmfNHsu6cr1x26bL4uvq8x6ZKmuJMTYxD+GvDx2Os ukfPUXUUywyu
kcr3q5ng7ZyucquVVTrVVVesCLfqzVuPrZHA5LJ5eGy7M0aWOiryUbeVe6WK SWSs5+7IY92x
K5JJOtGq7xqjVJqxez+fczD5fPZqsuG4iUKldZbNWWzC2SsyRWSSRsVjnNe9 +3j235VV2x0p
mmtRMwC4BnCPhi3ErKky0kzsqQ90TxP5PBu3N/1eM/MumM/LiLGHk4P8LnY6 y5j56q5uTuUr
mIiMVzfBuyq1ETZV8WwElR1pr+9ck1BFLPXjj1U/ErWs3qcdFIm3O4dwWNU7 v3ZY/tou+6vc
ionIux/QJzN2F1W/Uiakdwr4bOzTfFkFz83fCdXL/wATwdzb7dW+/i6jZ8Jc U/5N0Z712f8A
bwPdlte6QxGsINJZXOVqGYsV47EENjeNsjXvexiNkVORXKsb9mb8y8q9RSnL MBTt5/ibrKlr
3T2BbHLp3DtfTituv15Iu+MmqOcssMWy783VyqibIu/XskZXzV7FahixXAS/ f1bRinSO9jrT
lnwtFnVukd57uaJyIvVHG6ZE6/sIBt8Pma01BoLT2fu8UdTx2sli61yZsNPF oxr5ImvcjUWm
qom7l23Vf6m74F1X61NW/wCkxX0R5OC/3O6K7P0P07DxftbqTI5vLxab07Ty GPw2QZQtLLe7
lYnfyRvlWJqt5ERjZE/icnMqKnV1Ksf1VZutFm1FMTMNjwLqv1qat/0mK+iH gXVfrU1b/pMV
9Ec0w2ulwMMeSzc2Sux111Tae7vx6/u6t5qNj7mq8r15XI1ir/AiKibIqnt6 ZJYsdlbE+Nxl
mathLOVhbRuSSsa6FqK6CVzom8rl5k2cm6Lyu6k2TfOdTEUWfeF94F1X61NW /wCkxX0Q8C6r
9amrf9JivoiF1zrnWNHAalpOxeNxuSbpWzmsfPDddL3FI9myNfvGid0bztc3 ZFaqpsuydZ6K
UF/XOt8lgtS3blSnhMbSe+li8jNXbYnsJI50jpI1ZI5rUY1rU6k35lVF6tsZ 1fs+nazyilZe
BdV+tTVv+kxX0Q8C6r9amrf9JivoiHzcWptL5fRuHxWoJ886XP2o44rtt0ap AtGd7YbEicyy
9zVOdFc3deVvnTmPbLxJvwYF092pgMbcgy9jF25r2WSGpG+JFVHsVze6SK/7 OzEbum67rsm6
s6v2z9O170qvwLqv1qat/wBJivoh4F1X61NW/wCkxX0RF4Hihms9HgquKweN lv5Ozkaskjrz
0rRrUciLI13c+dzHIu6JyovWielT04ziFqLKzYfF0dPY5Mtclyle2kt5yQV5 KM7Inua5I1c9
rldunUi9afmozqPp2f0q/Auq/Wpq3/SYr6IeBdV+tTVv+kxX0RDrxgVaGGhk p4yjlLrLjrPf
lx6VoO9rC13o1zY1c9XPavL9lPsoqr17Ivq0Vq+xqriFhbka2alSzp28+Wks znRJPFdhiV6d
SI7xO5X7Iqtd5t9hnUfTszshc8N7Wfh17qLAZbU+Rz1Wti8dcruvQVmPifNL dZIiLBFGioqQ
R+NF22Xr6zoZzzRP3xaq7P4f9RkjoZupnOHNvREVzEAAPprAAAAAAAAAAAAA AAAAAAAAAluK
OQu43TVSzQsPryvz2HruezxrHLkq0Ujf6OY9zV/JVKkzNTeBvB0Xh7uPenf1 Tufdf4e+O+I+
99v+ru3ctvz2A0wAAAAAAAAAAAAAAAAAAAAAAAZlnJY2LVVDDys3ydmjZs13 dz32hifA2VOb
zbumh6vPt+Rpk5kMPdn4mYPPxtZ3lTw2RpzKrvtJJPNSezZPOm1eTdfN1eko wAAAAAAAAAAA
AAAAAAAAAAAZmG8DeEc34L7j33383wp3P+LvjveHl5/+ruPcP+3KaZLaJx92 nqXXVm1XfFFf
z0Viq93iljTG0Ylcn5c8b2/1aoFSAAAAAAAAAAAAAiuNPkZU7RYP4rUN0wuN PkZU7RYP4rUN
0pGLOJb7+EmxskMLgt5GW+0Wc+K2zdMLgt5GW+0Wc+K2xhLiXOkF/ZC1ABd0 YAAAAAAAAAAA
AAAABz7RvlnxE7RQ/CseVJLaN8s+InaKH4VjypPLtd89c/vZNt7sJbWXlnw7 7RTfCsgdBOfa
y8s+HfaKb4VkDoJc8N8jT1n5R728AA7zUAAAAAAAAhdX8LNNat1guoNQS5O3 C+lBTmxSW3Mo
2EhllkjdNG3ZZVR0z9kcqt6/4SzoU6eOow0cfUgqVIGIyGCCNGRxtTxI1qdS J+SH3Cgcm4L/
AHPaK7P0P07D5ZTh/SuZW/ahzWYoU8pPHZyWPqyRthtSMRjUcqqxZGbtYxHc jm8yJ1+fec4S
cROH9LhTpGnc11pitZr4OlFNDNloGPje2BiOa5qu3RUVFRUXxFR0ncNvWFpL 2zX+cjTE5u1T
VRNMZy8ycMtNua2Oy67ag7nlInwyyN5JGZCZss6Ls1F6laiN2VFRPHuvWfiX hxBbw97FZfVW
pMpWtYyXGRpYmiateCRERytRkbUe/ZE+3Ij16vzXf2dJ3Db1haS9s1/nHSdw 29YWkvbNf5x+
Wf8Am+2otE4jO2bE96W4nfGDsYSRsb2oi151ar1/h35/sJsu+3WvUp4rWgkk npZGrqnOUM3W
qJTlylfvfuluJFVWtmjdEsTtlVVRUYipuuy9an36TuG3rC0l7Zr/ADjpO4be sLSXtmv85j8m
dv8Ab5YPh1hMTNi7UdvJWLlDIz5OS1Yma+S5ZlgfA98y8vX9h+yI3lROVu3U my/KfhvjvCse
Xx+Yy2PyMWQtXmWIlherXWWtbKzlkjc3l2Y3bq5k28fWqL6uk7ht6wtJe2a/ zjpO4besLSXt
mv8AOPyf83y03w7xGDyNG/DkMrasU7N2011mZjueS2rVlV2zE3627ptttuvj 6tvThdD4nFZm
DK17F188E+Rna2R7VarrszZpUXZqLsjmIjevqTffm8Z8+k7ht6wtJe2a/wA4 6TuG3rC0l7Zr
/OPyf83lj4c4+nHSfhs1mMVepyXHR3YHQukcy1Os8sT2vjcxzOdd27t3byp1 +PfSwejcdicv
RysV3JWbVPHy0Efan7osrZZWyve9VTdXq5ieJUREVURNttvP0ncNvWFpL2zX +cdJ3Db1haS9
s1/nH5Im3Hu1tE/fFqrs/h/1GSOhnK+FOdweoeK2rbuAzOOy1ZmDxET5qVpk 7GvSfIqrVcxV
RF2VF2/NPSdUJFOxyb853JAAfTUAAAAAAAAAAAAAAAAAAAAABLcUcfdyWmql ahXfYlZnsPYc
xnjSOLJVpZHf0axjnL+SKVJh64zkunsLXvwwMndLlcdRVr1VERtm7DXc7q86 JKrk/NEA3AAA
AAAAAAAAAAAAAAAAAAAAATmQzF2DiZg8BG5neVzDZG5Mit+0skE1JjNl8ybW JN08/V6CjMyz
jcbLqqhmJX7ZOtRs1q7e6bbwyvgdKvL59nQw9fm3/M0wAAAAAAAAAAAAAAAA AAAAAAYemc5L
ls1qihJAyNuFyrKMbmqqrI11KtY5l9C72Fb/AEahuGTgsHFicpn78c75HZrI MvSNciIkbm1Y
K/KnpTaujv6uUDWAAAAAAAAAAAAARXGnyMqdosH8VqG6YXGnyMqdosH8VqG6 UjFnEt9/CTY2
SGFwW8jLfaLOfFbZumFwW8jLfaLOfFbYwlxLnSC/shagAu6MAAAAAAAAAAAA AAAA59o3yz4i
doofhWPKkltG+WfETtFD8Kx5Unl2u+euf3sm292EtrLyz4d9opvhWQOgnPtZ eWfDvtFN8KyB
eW7NepWktW54q8ETVfJLK9GsY1PGqqvUifmXPDfI09Z+Ue9vPqDJ0tqTDaox 8mQwNzv2kyZY
UsNie2KVURFVY3OREkZ1/wAbN2qqKiLuimsd5qAAAAAAAAAAAAAAAAAFOQcO 6WsNRcP9Oagv
cUtVR2sniqtydkNPFoxr5YmvcjUWmqom7l23VV286kPTdPs6HTFV2col9U0z VsWOg5JH6q4g
NfOsrY9QxNY1VVe5J4LoLypv4utVd1dX2vTuVxzHHaGzGPuZK3U4navimydl LVx3e+MXukqQ
xwo7Zaeyfu4Y27Jsn2d/GqquhoCbO1eIOodP5TU+Sz1WtisdcrvvQVWSRPml uskRFghjRUVI
I/4kVUVF6+sj6JrjRtLufTtTnPRmq3VTGcr4AHUfAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAGT
qzBxahxcNCad8DYshSvI5iIqq6taisNb1+ZViRq/kqmsR/F6WWDSlJ8Mr43L qLBsVWOVFVrs
rVa5OrzKiqip50VQLAAAAAAAAAAAAAAAAAAAAAAAAEflopXcaNMztiesTNO5 djpEavK1zrON
VEVfMqo12yfkvoLAybWcir6xxum3QPdLex9u82VFTla2vJWYrVT0qtlqp/ap rAAAAAAAAAAA
AAAAAAAAAAAAj9ASyyar4hMkle9sWooWRo5yqjG+Cse7ZPQm7lXb0qvpLAzM NksbeyObq0Wc
tjHXm1ry9z5eaZa8MqLv/i/dyxJv+W3mA0wAAAAAAAAAAAAEVxp8jKnaLB/F ahumFxp8jKna
LB/FahulIxZxLffwk2NkhhcFvIy32iznxW2bphcFvIy32iznxW2MJcS50gv7 IWoALujAAAAA
AAAAAAAAAAAOfaN8s+InaKH4VjypJbRvlnxE7RQ/CseVJ5drvnrn97Jtvdhz /jHY1BVu6Ksa
Vx9LI5pmemWpWuTrDFI7wXf3Rz0RdurdUTq3VETdu+6c/wBJW9X6q1BHV4iY LTuS1RG7ukWB
zmobFKvDsv8AFBUSi6KdE/8AU551T/nTxHV9ZeWfDvtFN8KyBW6m09g9TY1c dn8XVyNVXI5G
Txo7kcnic1fG1yeZyKip5lLnhvkae/yj3t5PtyHFJrUa3Rmi0aibIiaqs7J/ /Hn++EuKf8m6
M967P+3m5pPBJp7Gvx8eWyuRg7qr4FyNju8kDFRESNJFTnc1NlVFernda/aV NkTXO81Izwlx
T/k3RnvXZ/28eEuKf8m6M967P+3lmAIzwlxT/k3RnvXZ/wBvHhLin/JujPeu z/t5ZgCM8JcU
/wCTdGe9dn/bx4S4p/yboz3rs/7eWYAjPCXFP+TdGe9dn/bx4S4p/wAm6M96 7P8At5ZgCM8J
cU/5N0Z712f9vHhLin/JujPeuz/t5ZgCM8JcU/5N0Z712f8Abx4S4p/yboz3 rs/7eWYAjFyX
FPbyN0Z712f9vMvgl9zOiOztD9PGdHU5Bw7u6w07w/05p+9wt1VJaxmKq053 w3MWrHPiiaxy
tVbiKqbtXbdEXbzIV3EWiXtKs002qc5iW21VET+XRyc0v98+qOzuH/U5Mz6e tc1cs3a9Xhlq
yWWjOle0xtvFbxSLGyVGr/43x8kjHf0ch7dAQ521xB1DqDKaYyWBq2cVjqdd l6eq+SV8Mt18
iokE0iIiJPH/ABKiqqr1dRy9Qat0nRtK9d2jKMn3driafwvgAXZHAAAAAAAA AAAAAAAAAAAA
AAAAAAAAAAzNTZLG4rHRWsqznrvvVKzE7nz/AL6axHFCu35SPYu/m238xpk5 xFw93Oafq0qD
WOljzOLuOR7uVO5179eeT/vyRu2TzrsgFGAAAAAAAAAAAAAAAAAAAAAAADDu 4OWxr/EakSdj
YqGKvUXRKi8znWJaj0ci+hErORf7kNwlsnkLsfFrT2KZYe2lYwOUsTQp/C+S OfHtY5fzRJZE
T+5SpAAAAAAAAAAAAAAAAAAAAAABOaRw93Gag1jdtNYkWWzMdyqrXbqsbaFS Bd/QvPA/q9Gy
+coyc0jmLuT1BrGlacxYsTmY6dVGt2VI3UKk67+leed/X6Nk8wFGAAAAAAAA AAAAAiuNPkZU
7RYP4rUN0wuNPkZU7RYP4rUN0pGLOJb7+EmxskOfaC1vp7TWlJqN21JZyk+o M4tbF0onWLk/
/mtrrbEzd3L6XLs1POqHQTjGneCuiNaYe5qSxi6dbUSagzad/upQ2WyomUtN RJoZmujlTZET
dURyImyOaMJcS50gv7IdIxa8QtQZKtevd7aQw8UrZO8Goy1fstRd+SV/XFC1 fErWc7tl6ntU
tziuL0RpvE5KtitYcEtG3I55Www5rB6fglruc5dkWaBWLJB1r1qndGJ41e1C 36J+Fnq00Z7C
rfIXdGWYIzon4WerTRnsKt8g6J+Fnq00Z7CrfIBZgjOifhZ6tNGewq3yDon4 WerTRnsKt8gF
mCM6J+Fnq00Z7CrfIOifhZ6tNGewq3yAWYIzon4WerTRnsKt8g6J+Fnq00Z7 CrfIBZgjOifh
Z6tNGewq3yDon4WerTRnsKt8gFmCM6J+Fnq00Z7CrfIOifhZ6tNGewq3yAeH RvlnxE7RQ/Cs
eVJE8MsTisHqDX2LwmMpYyhBqKPuVWnA2GKPmxlBy8rGoiJuqqq7J41VS2PL 9dxP31z+9k23
uwltZeWfDvtFN8KyB0E59rLyz4d9opvhWQOglyw5yNPf5R728AA7zUAAAAAA AAAAAAAAAAAA
CW0Tj7tPUuurNqu+KK/norFV7vFLGmNoxK5Py543t/q1SpMTTmakyuZ1NRfH ExuHybKTFYq7
vR1OtY3dv5951Tq6tkTz7m2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJziL mLuD0/Vu0HMb
LJmcXTcr28ydzsX68En/AH5JHbL5l2UozM1NjcblcdFVyr+Suy9UssXunJ++ hsRywpv+cjGJ
t599vOBpgAAAAAAAAAAAAAAAAAAAAAAAzLPgb9qqHd+4+Gu8bPem/wDxO9+e Du+3/Tz977/n
ymmS2Tx92Ti1p7KsrvdSr4HKV5pk/hZJJPj3Mav5qkUip/apUgAAAAAAAAAA AAAAAAAAAAAA
zMNjcbRyObtUX81jI3m2byd05uWZK8MSJt/h/dxRLt+e/nNMj9ARSx6r4hPk iexsuooXxq5q
oj2+Cse3dPSm7VTf0ovoAsAAAAAAAAAAAAAEVxp8jKnaLB/FahumFxp8jKna LB/FahulIxZx
Lffwk2NkhhcFvIy32iznxW2bphcFvIy32iznxW2MJcS50gv7IWoALujAAAAA AAAAAAAAAAAJ
HKcOdMZHNXsxKuerXL8jZbS0dQ36kcr2xsiRyxwzNZvyRsbuibqjU3JXIaIw sPEzB4Bl/ViU
rmGyNyZF1dleZZIJqTGbL3z1JtYk3Tz9XoOsGZZxuNl1VQzEr9snWo2a1dvd Nt4ZXwOlXl8+
zoYevzb/AJmubVEznMM5yxMVw50xjs1RzES56zcx8jpaq3tQ37ccT3RviVyR zTOZvySPbuqb
ojl2K4A+qaYpjKIYAAfQAyNZ5efT+ksrm6uLsZWejUksR0q+/dJ3NaqoxNkV ev8AJFX0IviO
ZVeNbI9LZPMW26cv97zVK9Z2NyrnMWaxIrEjnY+NJa/JtzKrmLu3dURVRWgd kBxuPjPbdRuw
18Pjsnk69/G1YXU7kiU7KXZ+4t2kfEjmPY7fmbyr1K1UVd9k99niXqKldv6e uaexj9Rx5inj
KjYLz1qyd8xOlbI97o0e1GMjk5mo1d+VNvH1B1UH8163zusO/M9VzU2ZgkTW uHpup4LLTNc+
u+qxXx13o6NzEkX7St3b9pV3VfGuhi9a3dFZfWs8dbVUVHHaehyNTDaovST2 J5GyvbLLFK98
qpEiOia5OddnKn2URU3D+hAcg/8AiD1rncVp7WWDwEcda3U0m/Ktv98OjkjR z5I3cnK1dnoj
eZq7p1+jxkfXzOV4f6z1HktQV2S0tOYzG18fTj1FdmY2a5NMxu6yps9HOd9p 8iOVjWN5UXbZ
A/o8HGpuNNmLD5h0GIx2VyVB+P7j3jck70sJatsrcndXxIrJGK7dU5VRUVq7 9aonV8A/LvxF
d2ego18kqL3eOlM6WFq7rtyuc1rl6tvG1Ovf+oHuAP8AN05lbum6JuqAf6Ac y0trbiJqLTGK
1BS0TpWOrk6UNyFk2qLCPayViPajkSiqIuzk32VU386mi/pNrR4zu1ZR/rMR M7FVpHD3cZqD
WN201iRZbMx3KqtduqxtoVIF39C88D+r0bL5yjOdU8xxajs3X2tMaNnilnR9 WNuo7DFgj7mx
qsVe8V51V6PfzdXU9G7fZ3XW0VqjO5TU+X09qHBY3GWsfSqXGPo5N9xkrLD7 DERVfBErVatZ
fMqKjk6zXZ0/R79Xpt1xMszTMbVeACW+QAAAAAAAAAAAAAAAAAAAAAAAAAAA AAI/i9FLPpSk
yGJ8jk1Fg3qjGqqo1uVqucvV5kRFVV8yIpYGTqzORaexcN+aB87ZchSoo1io io6zairtd1+Z
FlRy/kigawAAAAAAAAAAAAAAAAAAAAAAAMO7nJa+v8RptIGOiv4q9edKqrzN dXlqMRqJ6FSy
5V/tQ3DJtYOKxrHG6kdO9stHH26LYkROVzbElZ6uVfSi1mon9ymsAAAAAAAA AAAAAAAAAAAA
AACc0jmLuT1BrGlacxYsTmY6dVGt2VI3UKk67+leed/X6Nk8xRmZhsbjaORz dqi/msZG82ze
TunNyzJXhiRNv8P7uKJdvz384GmAAAAAAAAAAAAAiuNPkZU7RYP4rUN0wuNP kZU7RYP4rUN0
pGLOJb7+EmxskOecMdcYXD6fyOOt0tTSzQ6izXM6npnI2ol3ydpycssMDmO6 lTfZy7Lui7Ki
odDMLgt5GW+0Wc+K2xhLiXOkF/ZD9dJenPw3WfuZlvph0l6c/DdZ+5mW+mLM F3RkZ0l6c/Dd
Z+5mW+mHSXpz8N1n7mZb6YswBGdJenPw3WfuZlvph0l6c/DdZ+5mW+mLMARn SXpz8N1n7mZb
6YdJenPw3WfuZlvpizAEZ0l6c/DdZ+5mW+mHSXpz8N1n7mZb6YswBGdJenPw 3WfuZlvph0l6
c/DdZ+5mW+mLMARnSXpz8N1n7mZb6YdJenPw3WfuZlvpizAEZ0l6c/DdZ+5m W+mJPK8QsC/j
Dpy4lDVvcotP5aJzV0nk0kVX2McqKjFr8zm/YXdyIqNVWoqorm79fJbJ4+7J xa09lWV3upV8
DlK80yfwskknx7mNX81SKRU/tUDy9JenPw3WfuZlvph0l6c/DdZ+5mW+mLMA RnSXpz8N1n7m
Zb6YdJenPw3WfuZlvpizAHP8/rnS+ZwtzFTVde1o7cLonTVdJZeKaPdNuZj0 rbtcnjRSJlpa
IvSX7eevcT8zk7cVaKLIzaOvwz1EryrLC6LuNFjUe2Rebmc12+2y9W6HdgBx Xu2lLUTlzWU4
pZi07I0cgtizpHIt2dUmSWJjY46TY2sVyfa5Wo5267u8W31zk2hcrkcpk3R8 Rat+/ZqW2WIN
IZNHVJ6zVbE+JFpqniVUVHo5FRVTbZdjsoA4HZxmjbVa2tnN8WpMlby9bMPy X7IXe7tswMRk
fK1aHc0aiIn2eTbqPRJT0Lejy66iucUtRWspjH4t9q/pPItkgrOcjnMiSGjG xu7ka5V5VVVa
3fdE2O6ADg96jovKQZtM7leKuWtZrDLhrNqfSF5j21+ZXJyNjoNY1yK53Xyr vv17mvn7HD/N
2tQWL1LiCr85DTjmWPSWVYsDqr3vgliVKu7Xte/m3VVTdrerx79hAHE55NK3 6NyDPZbipmZr
U9KV1ixpHIMWNKlhtiJjI46LY2or2/aXk5nIq9fUm1z0l6c/DdZ+5mW+mLMA RnSXpz8N1n7m
Zb6YiIsXhOI/GLUGVp2dT4S9jdP4qOnebWtYy1C51jIK/aOeNvdY3bM3R7HM Xl28aLt2o5vq
zSevb/Em7lNN6kxuAw+QxFKnbtpW74vtfXntP2ha/wDdNRzbG3O7n2VOpvnA yNQcRc/wut0K
HEN9HP0b8yV6WRxSJHfkcqoid0oqu8nj63QKv9iGxwS+5nRHZ2h+njNnRPDr S+krEuRpVZr2
anby2czkpls3rHUifamfuqJ1J9lvK30IhjcEvuZ0R2dofp4yqYr5ejr4b7G1 Xk5pf759U9nc
P+pyZRk5pf759UdncP8AqcmcbDHO9p8Nl7dXYAPREQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAC
O4wuVmkqKojV/wD1Hgk62ovjy1RPOWJmam8DeDovD3ce9O/qnc+6/wAPfHfE fe+3/V3buW35
7AaYAAAAAAAAAAAAAAAAAAAAAAAJHK2Jm8ZdN1WyOSGTT2XkezzK5tjGo1f+ yPd/9yuMyz4G
/aqh3fuPhrvGz3pv/wATvfng7vt/08/e+/58ppgAAAAAAAAAAAAAAAAAAAAA Aj9ARSx6r4hP
kiexsuooXxq5qoj2+Cse3dPSm7VTf0ovoLAycFnIstlM/QjgfG7C5BlGRzlR Ukc6rBY5k9Cb
WEb/AFaoGsAAAAAAAAAAAAAiuNPkZU7RYP4rUN0wuNPkZU7RYP4rUN0pGLOJ b7+EmxskMLgt
5GW+0Wc+K2zdMLgt5GW+0Wc+K2xhLiXOkF/ZC1ABd0YAAAAAAAAAAAAAAAAM O7nJa+v8RptI
GOiv4q9edKqrzNdXlqMRqJ6FSy5V/tQjI2anz+tNYRRa8z2HqYvKxU6tWjWo LG1i0KkyqqzV
pHqqvmevW7bbZERNj/ZtC5ibOVc3JxO1e6/UrTVYJe98Z9iKZ0TpG7d57Lu6 CJd1TdOXq23X
fj6RrzRNHuTbrn8x/jZFuqYzh04HMJGanwGtNHxS69z2YqZTKy07VW9WoJG5 iULcyKiw1o3o
qPhYvU7bxoqLudJu2qtGpLbu2Ya1aFqvklmejGManjVXL1IhP0XSrelW4uW5 /D4qpmmcpfYG
DovWGnNZVLlzTOTZka1O0tSWaNjkZ3TubJPsqqIjk5ZGKjm7ou/UpzjiXf1R Lq/XEOO1ZksR
TwOkYMrVgqMh2daV1xeZyvY5VbtC1Fb4l6iSw7KefI3qWNpyXcjcr06se3PN PIkbG7qiJu5V
RE3VUT/ucB1XqrWWncXkLTdV3rUlvRcebc6aGFG1bCTxNc6JGsTlZySO3R3N /Ci777quhx+z
9me/qjTseQbJQh03RuLWarVRkr8gjedV8e6tRPPtsB2y1ksdVcxtq/VgdJO2 sxJJmtV0zk3b
Gm69b1TrRvjU9RwKg/IYPU+bkrZq7P35xMqVZorCRPa2N1SFy7fYRUVUcjd9 /Exu3Xuq/fR+
odSeA9H6om1lcytrL6llxdmg5sPcHQd1nYrGta1HI+NI0ert9/su36l2QO3Y 69SyVKK9jrle
5VlTeOeCRJI3pvtujkVUXrPQfzLw+zurZ8LpXSeE8JxUodNLklXHWqteWWR1 uaNVV1hrkVka
Maqo1PHKnN1bIe7V3EPWuMwGk8jHqWi2xnMUsWYWCNliDFxJMxi5disRU5Wo /ZWqvJu5q+Jj
tw7Tm9e6FweVdis1rTTmMyDEarqtvKQwzN5k3buxzkXrRUVOooYZI5omTQyM kje1HMe1d0ci
9aKi+dDg0NTUz+KHEmtgMnpZYe98ayWbP13zrIveSIj92Oa3ZfGu6Kin34A6 jkZDo3CR2Zau
Fh0VJIsNiVr0dLXtMgWZJNk5mK1FVq9ScrmrsgHYMzqPA4a/RoZbM0aNvIPV lOGedrHzqm2/
Kiruu26b/wBUP1pvP4TUmO8JYDK08pS51j7vVlSRiuTxpunUfzniGZfV9LD6 iyGrMyy5c4c3
LMz66wtSRUkjRU2WNfsu3RV286Jtse7S2Y1fHSwek8Xfza1Mdo3H5Nk0FulB K9Zkk5nuWdmz
ookYxiNanVv9tV3aB/SAONcOctq3V+uaT8tqaWnXqaYxOUmpYpYX1bViZ9pH u51Y5yxObG3q
a5PN19XX2UAviOccEvuZ0R2dofp4zo6+I5xwS+5nRHZ2h+njKpivl6Ovhvsb VeTml/vn1R2d
w/6nJlGTml/vn1R2dw/6nJnGwxzvafDZe3V2AD0REAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAl
uKOPu5LTVStQrvsSsz2HsOYzxpHFkq0sjv6NYxzl/JFKkw9cZyXT2Fr34YGT ulyuOoq16qiI
2zdhrud1edElVyfmiAbgAAAAAAAAAAAAAAAAAAAAAAAJbJ4+7Jxa09lWV3up V8DlK80yfwsk
knx7mNX81SKRU/tUqTDu5yWvr/EabSBjor+KvXnSqq8zXV5ajEaiehUsuVf7 UNwAAAAAAAAA
AAAAAAAAAAAAAGHpnBy4nNaovyTskbmsqy9G1qKixtbSrV+VfSu9dXf0chuE tonIXbmpddVr
Vh8sVDPRV6rHeKKNcbRlVqflzyPd/VygVIAAAAAAAAAAAACK40+RlTtFg/it Q3TC40+RlTtF
g/itQ3SkYs4lvv4SbGyQwuC3kZb7RZz4rbN0wuC3kZb7RZz4rbGEuJc6QX9k LUAF3RgAAAAA
AAAAAAAAAAHPtG+WfETtFD8Kx5Ukto3yz4idoofhWPKk8u13z1z+9k23uw55 xqs6jpz6LtaR
xlTKZyPOzLTqWp+4xSu8F390V3m6t1TxIqoiKrd90y9CppfWGfjq8Rstkcjr CFe6t0/nqyUo
K6oq/ar1N1jmam26S80y+fmQrtZeWfDvtFN8KyBUau0rp3V2L8Gakw9TJ1UX mY2Zn2onf87H
J9pjk8zmqip6S54b5GnrPyj3t5Caes6zra64hxaa09p6/TTPwc0l7NTU3tf4 Kx+7UYyrKit2
5evmTxqmybbrqTxa/sTW5p+HXD+WW7XSrae/Uk7nTwpzbRvVcd9pic7/ALK7 p9t3pU2eHujK
Wi6uUr0spl8kmRv9+ySZKz3xK1e4xQtYkipzOa1kLETmVXdXWqlOd5qc9kra 6kXeThtw8eve
i0vtaimX/wAOu28P/wAu/wCGuyfY8XV4jOx+mc/jqclOhwf4W1a0rEZJFFmp Gte1HI5EciY3
rTmRF6/OiKdTAHNXYjVzszNmXcLeG7slPJFLLbXUEyyvfEipG5X+Dt1c1FVG r408xhcPdDat
0fBBNBw54dWcxG6dXZVc7Myy9JJHvVFemPV3UjuXx9aIn9Ds4A5blNN6iymN qYzJcIuGFujT
371rTZyV8cG/j5Grjdm7+fbxnuSnrdHWHJw04dotmq2nOv7Qzfva7UVGxO/8 u+0xEc5EavUn
MvV1nRAByPI6JyGRsMs5DghwjuTsjZEySfKOkc1jGo1jUVcZujWtRERPEiIi IaGXwuq8xFRi
y3Cnhrfjx/8A+zZZz0sja/UifYR2OXl6kTxehPQdMAHO4KWtq8bI4OGfDqJk dZ1RjWahmajY
HKiuiREx3UxVRFVviXbxHkzOn9TZmpSqZfhNwyv16DUZTisZ2WRldqIiI1iL jtmpsiJsnV1I
dPAEFXXiHXuPu1+H+gorUkLIHzM1LO17o2K5WMVyY7dWtV7tk8Scy7eNT1eE uKf8m6M967P+
3lmAIxclxT28jdGe9dn/AG8y+CX3M6I7O0P08Z0dfEc44Jfczojs7Q/TxlUx Xy9HXw32NqvJ
zS/3z6o7O4f9TkyjJzS/3z6o7O4f9TkzjYY53tPhsvbq7AB6IiAAAAAAAAAA AAAAAAAAAAAA
AAAAAAAAZOrMHFqHFw0Jp3wNiyFK8jmIiqrq1qKw1vX5lWJGr+SqaxH8XpZY NKUnwyvjcuos
GxVY5UVWuytVrk6vMqKqKnnRVAsAAAAAAAAAAAAAAAAAAAAAAAAZNrBxWNY4 3Ujp3tlo4+3R
bEiJyubYkrPVyr6UWs1E/uU1iPy0sreNGmYGyvSJ+ncu90aOXlc5tnGoiqnn VEc7ZfzX0lgA
AAAAAAAAAAAAAAAAAAAAADMw3gbwjm/Bfce++/m+FO5/xd8d7w8vP/1dx7h/ 25TTJbROPu09
S66s2q74or+eisVXu8UsaY2jErk/Lnje3+rVAqQAAAAAAAAAAAAEVxp8jKna LB/FahumFxp8
jKnaLB/FahulIxZxLffwk2NkhhcFvIy32iznxW2bphcFvIy32iznxW2MJcS5 0gv7IWoALujA
AAAAAAAAAAAAAAAOfaN8s+InaKH4VjypJbRvlnxE7RQ/CseVJ5drvnrn97Jt vdhLay8s+Hfa
Kb4VkDoJz7WXlnw77RTfCsgdBLnhvkaes/KPe3gAHeagAAAAAAAAAAAAAAAB fEc44Jfczojs
7Q/TxnR18Rzjgl9zOiOztD9PGVTFfL0dfDfY2q8nNL/fPqjs7h/1OTKMnNL/ AHz6o7O4f9Tk
zjYY53tPhsvbq7AB6IiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZmpsljcVjor WVZz133qlZid
z5/301iOKFdvykexd/Ntv5jTJziLh7uc0/VpUGsdLHmcXccj3cqdzr3688n/ AH5I3bJ512QC
jAAAAAAAAAAAAAAAAAAAAAAABmWcljYtVUMPKzfJ2aNmzXd3PfaGJ8DZU5vN u6aHq8+35GmT
mQw92fiZg8/G1neVPDZGnMqu+0kk81J7Nk86bV5N183V6SjAAAAAAAAAAAAA AAAAAAAAABh6
ZzkuWzWqKEkDI24XKsoxuaqqsjXUq1jmX0LvYVv9Gobhk4LBxYnKZ+/HO+R2 ayDL0jXIiJG5
tWCvyp6U2ro7+rlA1gAAAAAAAAAAAAEVxp8jKnaLB/FahumFxp8jKnaLB/Fa hulIxZxLffwk
2NkhhcFvIy32iznxW2bphcFvIy32iznxW2MJcS50gv7IWoALujAAAAAAAAAA AAAAAAOfaN8s
+InaKH4VjypJbRvlnxE7RQ/CseVJ5drvnrn97JtvdhLay8s+HfaKb4VkCk1L g8nlp4ZKGss7
gGxtVro8fDTe2Rd/G7vivKu/m6lRPyJvWXlnw77RTfCsgdBLnhvkaes/KPe3 mTprE38TBNHf
1Pls+6RyObJkI6rHRpt4m97wxJt/VFX8zFn0hqCSeSRnFPWELXOVyRsrYpWs RV8Sc1JV2Txd
aqv5lgDvNTMzGMu3sOyjV1Dk8XYby73qsdd0ztvHuksT4+vz7MT8tjPwGncx jcilq7r3Ueai
RqtWrdgoNiVV8+8NaN+6f3belFKMATmf07mMlkVtUte6jwsStRqVaUFB0SKn n3mrSP3X+7b0
IhoYfGXaOHfRtahyeUsO5tr1qOu2Zu/i2SKJkfV5t2L+e5pgCPg0hqCOeOR/ FPWEzWuRyxvr
YpGvRF8S8tJF2XxdSov5m1qXE38tBDHQ1PlsA6NyudJj46r3SJt4nd8Qypt/ REX8zWAGFprB
5PEzzSX9ZZ3PtkajWx5CGmxsa7+Nve9eJd/N1qqfkePK6WzlzIz2q3EjVOOi kdzMq1q+NdFE
noaslR79v7nKv5lSAMzwZd/Z3wX+0OT777lyeFO51++d/wDn5e5dx5v/AKe3 5GTitLZynkYL
VniRqnIxRu5n1bNfGtilT0OWOox+39rkX8ypAGFqXB5PLTwyUNZZ3ANjarXR 4+Gm9si7+N3f
FeVd/N1KifkffTWJv4mCaO/qfLZ90jkc2TIR1WOjTbxN73hiTb+qKv5msAI+ xpDUEk0kjOKe
sIWucrkjZWxStYir4k3pKuyeLrVV/MwOEVeWzwQ0RFDesUn/ALP49e6wNYrv /wBvH1fba5P/
AMHT18Rzjgl9zOiOztD9PGVTFfL0dfDfY2t7H465WsJLNnsldYiKncp2V0av 5/Yiav8A+SSZ
hMlleNOo1oavzeB7np7Eq5MfFTf3Texkdkd3xBL4tlVNtv4l336tr4nNL/fP qjs7h/1OTONh
jne0+Gy9uqjD4y7Rw76NrUOTylh3NtetR12zN38WyRRMj6vNuxfz3MKDSGoI 545H8U9YTNa5
HLG+tika9EXxLy0kXZfF1Ki/mWAPRERk6lxN/LQQx0NT5bAOjcrnSY+Oq90i beJ3fEMqbf0R
F/M+GmsHk8TPNJf1lnc+2RqNbHkIabGxrv429714l383Wqp+RugCWyuls5cy M9qtxI1TjopH
czKtavjXRRJ6GrJUe/b+5yr+ZreDLv7O+C/2hyfffcuTwp3Ov3zv/wA/L3Lu PN/9Pb8jTAEt
itLZynkYLVniRqnIxRu5n1bNfGtilT0OWOox+39rkX8z2alweTy08MlDWWdw DY2q10ePhpvb
Iu/jd3xXlXfzdSon5G6AMnTWJv4mCaO/qfLZ90jkc2TIR1WOjTbxN73hiTb+ qKv5mLPpDUEk
8kjOKesIWucrkjZWxStYir4k5qSrsni61VfzLAAZmYxl29h2Uauocni7DeXe 9Vjrumdt490l
ifH1+fZiflsZ+A07mMbkUtXde6jzUSNVq1bsFBsSqvn3hrRv3T+7b0opRgCc z+ncxksitqlr
3UeFiVqNSrSgoOiRU8+81aR+6/3behEPVpPlhr3Ma/Ul3P26FnuNqe4yBssb 3RslSNyQxxs/
gkY5Nm77OTdVNkltE4+7T1Lrqzarviiv56KxVe7xSxpjaMSuT8ueN7f6tUCp AAAAz9SZrG6d
wF7O5mz3rjqEDrFmbkc/ucbU3cvK1FcvV5kRVA0ARGe4q6NwecbhclLnY7z5 nQxRx6cyEqTv
a1XOSJzIFbJs1FduxV6kVfEhXYu7BksdXyFZJ0hsRpJGk8D4ZERU3TmY9Ec1 fyciKnoA9IJH
PcR9KYXP2cFcmy8uQqxxyWI6WDu3Eia9FViufDE9qboi+NfMpvadzWL1Dhau awt2O7j7TeeG
ePfZyIqovj60VFRUVF60VFRQNAAACc4i5i7g9P1btBzGyyZnF03K9vMnc7F+ vBJ/35JHbL5l
2UozM1NjcblcdFVyr+Suy9UssXunJ++hsRywpv8AnIxibeffbzgaYAAAAAAA AAAAAAAAAAAA
AAAAJzIZi7BxMweAjczvK5hsjcmRW/aWSCakxmy+ZNrEm6efq9BRmZZxuNl1 VQzEr9snWo2a
1dvdNt4ZXwOlXl8+zoYevzb/AJmmAAAAAAAAAAAAAAAAAAAAAACP0BLLJqvi EySV72xaihZG
jnKqMb4Kx7tk9CbuVdvSq+ksDMw2Sxt7I5urRZy2MdebWvL3Pl5plrwyou/+ L93LEm/5beYD
TAAAAAAAAAAAAARXGnyMqdosH8VqG6YXGnyMqdosH8VqG6UjFnEt9/CTY2SG FwW8jLfaLOfF
bZumFwW8jLfaLOfFbYwlxLnSC/shagAu6MAAAAAAAAAAAAAAAA59o3yz4ido ofhWPKkltG+W
fETtFD8Kx5Unl2u+euf3sm292EtrLyz4d9opvhWQOgnPtZeWfDvtFN8KyB0E ueG+Rp6z8o97
eAAd5qAAAAAAAAAAAAAAAmNW09aNvxZTSmWoPbHEjJcRkYdoLCoqrzNnYndI nrvtuqSN2RPs
Iu6gU6+I5xwS+5nRHZ2h+njNPD8RMZJkYsLqala0pm5V5YquS5Ujsu/9idqr HN/ajufbxtQz
OCX3M6I7O0P08ZVMV8vR18N9jaryc0v98+qOzuH/AFOTKMnNL/fPqjs7h/1O TONhjne0+Gy9
ursAHoiIAAAAAAAAAAAAABh6ZzkuWzWqKEkDI24XKsoxuaqqsjXUq1jmX0Lv YVv9Gobhjaex
NXG5fUdyvc7vLlcky3Yj3T9w9KleFGdXpZCx/X1/b9GwHKv/AIhrMVbU9CS1 qLGVYWYqZ7cd
k8xZxMczkem8sFmJeVZ0Tq5XNcqIqKm267x2otSZS/cms5rMpp+u7TuPs4Rm azFqpbRXwKsk
kbYERLFlJOpybK7dGJyojtl/p17GPREexrkRd03TfrP9c1rlRXNRVau6bp4l A/nHUlXJZHAc
UMrmczmFy2C0vUuVHV7tioyvcbj3yulbE1zeVyyMRdnJ1bbbda75XGS9hbuk +J/7Z5+1Uz0e
PjTA1VyEkKS1nUYnIsUSORsqPmWdJPsu2RNl2REP6kP8VrVcjlaiub4lVOtA OdcTPvY4U/8A
+Xv/AAyyRvEPI4iPWWum621Lfw81SlA/SsceTlqq5q193SV42ORJpu+OZq9T ndTG7bLsveD/
ABzGOVqua1ytXdN08SgcL0JU4g5PXuoJodQ4/B5RcJhFyrLOIW0rrC15Ffy7 SsRmzubq2X/8
GTrPFTaJz2A0pbztKvptcbbtuuZjKTY2vbyUlnukznSQcqc+z1cyNVRERXbI qt6v6LP8exr2
8r2tcnoVNwP5kuZjPvbpitqvUtBuFfp981a/lcpcxcFqdLMib90ajXvlbAkC t59lXmc9qLvu
VXDnH5DUWs9PrqjOZXIPoaYqX40js2Kkc03fc/c5pI92Oe7ka1FR6bO3XdF6 tu4va16bPajk
332VNz/QBH8XopZ9KUmQxPkcmosG9UY1VVGtytVzl6vMiIqqvmRFLAydWZyL T2LhvzQPnbLk
KVFGsVEVHWbUVdruvzIsqOX8kUDWAAAAAAAAAAAAAAAAAAAAAAABH5aKV3Gj TM7YnrEzTuXY
6RGrytc6zjVRFXzKqNdsn5L6CwMm1nIq+scbpt0D3S3sfbvNlRU5WtryVmK1 U9KrZaqf2qaw
AAAAAAAAAAAAAAAAAAAAAAJzSOHu4zUGsbtprEiy2ZjuVVa7dVjbQqQLv6F5 4H9Xo2XzlGTm
kcxdyeoNY0rTmLFiczHTqo1uypG6hUnXf0rzzv6/RsnmAowAAAAAAAAAAAAE Vxp8jKnaLB/F
ahumFxp8jKnaLB/FahulIxZxLffwk2NkhhcFvIy32iznxW2bphcFvIy32izn xW2MJcS50gv7
IWoALujAAAAAAAAAAAAAAAAOfaN8s+InaKH4VjypMnK8OdMZHNXsxKuerW78 jZbS0dQ36kcr
2xsiRyxwzNZvyRsbuibqjU3JXIaIwsHEzB4CO/qzvK5hsjcmRdXZXmWSCakx my989SbWJN08
/V6Cp6fhyvStIquxXln/AI303fTGWT1cTcTis5qDQOLzeMpZOhPqKTutW5A2 aKTlxl9yczHI
qLsqIqbp40RTb6J+Fnq00Z7CrfIfXFcOdMY7NUcxEues28fI6Wqt7UN+3HE9 0b4lckc0zmb8
kj27qm6I5diuO5qzQp0LR4tTOeTXXV6pzRnRPws9WmjPYVb5B0T8LPVpoz2F W+QswdB8Izon
4WerTRnsKt8g6J+Fnq00Z7CrfIWYAjOifhZ6tNGewq3yDon4WerTRnsKt8hZ gCM6J+Fnq00Z
7CrfIOifhZ6tNGewq3yFmAIzon4WerTRnsKt8g6J+Fnq00Z7CrfIWYAjOifh Z6tNGewq3yDo
n4WerTRnsKt8hZgCM6J+Fnq00Z7CrfITGrdFaCx9+LEae4F6bzWSmiSVJHYS tXowNVVRFlsO
jVN90X7DGvf4l5URUU60AOMYf/4fNGWsjFmNYaf0xasxLzQ47E4eGlQgX0Kj U7pOv5yOVq+N
GNKDgl9zOiOztD9PGdHXxHOOCX3M6I7O0P08ZVMV8vR18N9jaryc0v8AfPqj s7h/1OTKMnNL
/fPqjs7h/wBTkzjYY53tPhsvbq7AB6IiAAAAAAAAAAAAAAR+gIpY9V8QnyRP Y2XUUL41c1UR
7fBWPbunpTdqpv6UX0FgZOCzkWWymfoRwPjdhcgyjI5yoqSOdVgscyehNrCN /q1QNYAAAAAA
AAAAAAAMPXGDl1Dha9CGdkDosrjryueiqitrXYbDm9XnVIlan5qhuEtxRyF3 G6aqWaFh9eV+
ew9dz2eNY5clWikb/RzHuav5KoFSAAAAAAAAAAAAAAAAAAABk6p1HhtL49mR z1zvKk6VInWH
RvdHEqoqosjmoqRs6v43bNRdkVd1QDWB8qlmvbrR2qk8ViCVqPjliejmPavi VFTqVPzOaxs1
Pn9aawii15nsPUxeVip1atGtQWNrFoVJlVVmrSPVVfM9et222yIibEbStKt6 Lbm5cn8M00zV
OULO7g5bGv8AEakSdjYqGKvUXRKi8znWJaj0ci+hErORf7kNw52uldSLOyZe K2suZrXNREgx
aN2VUVd2957Kv2U2VU3Tr28a7+SRmp8BrTR8UuvM9mKmUystO1VvVqCRuYlC 3MiosNaN6Kj4
WL1O223RUXcgaPrzRNIuRbon8z/j7m3VEZy6eADsNYAAAAAAAAAAAAAAAAAA BmYbG42jkc3a
ov5rGRvNs3k7pzcsyV4YkTb/AA/u4ol2/PfzmmR+gIpY9V8QnyRPY2XUUL41 c1UR7fBWPbun
pTdqpv6UX0AWAAAAAAAAAAAAACK40+RlTtFg/itQ3TC40+RlTtFg/itQ3SkY s4lvv4SbGyQw
uC3kZb7RZz4rbN04RhOM9bTLpdCYnCZK7qCfO5uRssuOtPqsZ4UtLzJ3CKSS ZURU6o27b7or
2qi7MJcS50gv7If0eqonjUHFcXd09ZyVbNa1s681Nk60rZ68TtFZaChUkau7 XRVm11TmaqIq
PkWR6L4nIW/SXpz8N1n7mZb6Yu6MswRnSXpz8N1n7mZb6YdJenPw3WfuZlvp g
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: ECF + EMF [message #618553 is a reply to message #618552] |
Tue, 08 May 2007 17:09 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
Thanks. A few questions and comments below.
Eike Stepper wrote:
> Hi Scott,
>
> I've attached a Team Project Set File for Net4j and CDO each as well as
> some diagrams for Net4j.
> The types in org.eclipse.net4j.transport have proper JavaDocs (more to
> follow).
> The four main interfaces of the transport layer are IBuffer, IChannel,
> IConnector and IProtocol.
> A good starting point is
> org.eclipse.net4j.tests.TCPTransportTest.createContainer() to see how it
> all works.
>
> The transport layer is the lowest layer in Net4j. It is asynchronous,
> buffer-oriented, non-blocking, fast
> but somewhat inconvenient for clients that are stream-oriented. I
> suggest that we use a SignalProtocol
> to integrate with ECF. SignalProtocols are sets of Signals that can be
> exchanged between two peers (IChannels).
> For each logical signal two classes have to be implemented, one for the
> sending party (RequestWithConfirmation)
> and one for the receiving party (IndicationWithResponse). In each of
> these classes two methods have to be
> implemented:
>
> org.eclipse.net4j.signal.RequestWithConfirmation.requesting( ExtendedDataOutputStream)
>
> org.eclipse.net4j.signal.RequestWithConfirmation.confirming( ExtendedDataInputStream)
>
> org.eclipse.net4j.signal.IndicationWithResponse.indicating(E xtendedDataInputStream)
>
> org.eclipse.net4j.signal.IndicationWithResponse.responding(E xtendedDataOutputStream)
>
>
> In addition to these synchronous signals there is also an asynchronous
> version available:
>
> org.eclipse.net4j.signal.Request.requesting(ExtendedDataOutp utStream)
> org.eclipse.net4j.signal.Indication.indicating(ExtendedDataI nputStream)
>
> A very simple example for such a SignalProtocol is in
> org.eclipse.net4j.tests.SignalTest.
> Complex examples for user supplied protocols are the packages
> org.eclipse.emf.internal.cdo.protocol and
> org.eclipse.emf.cdo.internal.server.protocol. I'll provide a simpler
> example application for Net4j ASAP.
A couple of questions: are the Net4j channels always point-to-point (as
opposed to publish and subscribe)? From the materials here
http://www.sympedia.com/net4j/ I don't see any indication of anything
but pt-to-pt communication (client-server or 1-1 peers) but perhaps I am
missing it.
If the notion of a channel is also pub/sub (no to question above), then
is there any notion of group membership or reliability/failure detection
in the pub/sub group?
Further, have you (or someone else) attempted to use Net4J to implement
the JMS spec? If so, then an ECF provider is already done :).
>
> I plan to develop a remoting layer on top of SignalProtocols that
> integrates with the OSGi service registry
FYI, we've already done this. There's an ECF API called the 'remote
services' API in plugin org.eclipse.ecf.remoteservices.*. It's for
accessing remote OSGi services either synchronously (RPC) or
asynchronously (listeners for results or 'fire and go'). Here's
javadocs for it
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/
See org.eclipse.ecf.remoteservice.* packages.
It's a 'separate but equal' API relative to the 'normal' OSGi services
API (exposed via BundleContext). The reason it's separate is to
a) Allow for programmer-controlled options WRT synch/asynch service
invocation (i.e. rather than have everything based upon blocking RPC).
b) Expose partial failure at API level rather than making the remote
service invocation completely transparent (i.e. make it look like a
'normal' method call)
This API is completely transport independent, and so could/would/should
be implemented on top of Net4J and/or other providers.
Thanks,
Scott
|
|
|
| Re: ECF + EMF [message #618554 is a reply to message #618553] |
Tue, 08 May 2007 17:56 |
|
Scott Lewis schrieb:
> Hi Eike,
>
> Thanks. A few questions and comments below.
>
> Eike Stepper wrote:
>> Hi Scott,
>>
>> I've attached a Team Project Set File for Net4j and CDO each as well
>> as some diagrams for Net4j.
>> The types in org.eclipse.net4j.transport have proper JavaDocs (more to
>> follow).
>> The four main interfaces of the transport layer are IBuffer, IChannel,
>> IConnector and IProtocol.
>> A good starting point is
>> org.eclipse.net4j.tests.TCPTransportTest.createContainer() to see how
>> it all works.
>>
>> The transport layer is the lowest layer in Net4j. It is asynchronous,
>> buffer-oriented, non-blocking, fast
>> but somewhat inconvenient for clients that are stream-oriented. I
>> suggest that we use a SignalProtocol
>> to integrate with ECF. SignalProtocols are sets of Signals that can be
>> exchanged between two peers (IChannels).
>> For each logical signal two classes have to be implemented, one for
>> the sending party (RequestWithConfirmation)
>> and one for the receiving party (IndicationWithResponse). In each of
>> these classes two methods have to be
>> implemented:
>>
>> org.eclipse.net4j.signal.RequestWithConfirmation.requesting( ExtendedDataOutputStream)
>>
>> org.eclipse.net4j.signal.RequestWithConfirmation.confirming( ExtendedDataInputStream)
>>
>> org.eclipse.net4j.signal.IndicationWithResponse.indicating(E xtendedDataInputStream)
>>
>> org.eclipse.net4j.signal.IndicationWithResponse.responding(E xtendedDataOutputStream)
>>
>>
>> In addition to these synchronous signals there is also an asynchronous
>> version available:
>>
>> org.eclipse.net4j.signal.Request.requesting(ExtendedDataOutp utStream)
>> org.eclipse.net4j.signal.Indication.indicating(ExtendedDataI nputStream)
>>
>> A very simple example for such a SignalProtocol is in
>> org.eclipse.net4j.tests.SignalTest.
>> Complex examples for user supplied protocols are the packages
>> org.eclipse.emf.internal.cdo.protocol and
>> org.eclipse.emf.cdo.internal.server.protocol. I'll provide a simpler
>> example application for Net4j ASAP.
>
>
> A couple of questions: are the Net4j channels always point-to-point (as
> opposed to publish and subscribe)?
Yes, channels are always PtP. Net4j doesn't know about groups or membership.
For anything more than pure PtP transport of buffers (and streams) it'd be best
to implement an asymmetric SignalProtocol that, on server-side, connects to
a GroupManager or thelike. CDO for example has the notion of a CDOSession
(relates to a channel with CDOClientProtocol) at client-side. When data is
committed in the context of this session a CommitTransactionRequest is created
and sent through the channel. When it arrives at the server its counterpart
CommitTransactionIndication is created by the CDOServerProtocol and executed.
It reads a change description, passes it to the O/R mapper and sends
notification signals to all the other CDOSessions of this mapper. The tricky
part is how the Indication instance gets a handle to the mapper. Usually
such server-side infrastructure is passed by the server-side protocol instance
which, in turn, gets it from the protocol factory. For this purpose an
IAcceptor stores a handle to a factory registry. When an acceptor accepts a
connector it passes the registry to the new connector instance. When the
connector receives a request to open a new channel it uses the registry
to lookup a protocol factory that can create the required protocol instance
for the channel.
> From the materials here
> http://www.sympedia.com/net4j/ I don't see any indication of anything
> but pt-to-pt communication (client-server or 1-1 peers) but perhaps I am
> missing it.
While most of the concepts described on that page are still valid the
architecture and the used technologies are completely different.
I should remove those pages.
> If the notion of a channel is also pub/sub (no to question above), then
> is there any notion of group membership or reliability/failure detection
> in the pub/sub group?
What exactly do you mean by "reliability/failure detection"?
> Further, have you (or someone else) attempted to use Net4J to implement
> the JMS spec? If so, then an ECF provider is already done :).
No I don't know of anyone who did that for Net4j.
While this is a quite interesting thing I'm sure that I won't have the time for it ;-(
>>
>> I plan to develop a remoting layer on top of SignalProtocols that
>> integrates with the OSGi service registry
>
>
> FYI, we've already done this. There's an ECF API called the 'remote
> services' API in plugin org.eclipse.ecf.remoteservices.*. It's for
> accessing remote OSGi services either synchronously (RPC) or
> asynchronously (listeners for results or 'fire and go'). Here's
> javadocs for it
>
> http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/
>
> See org.eclipse.ecf.remoteservice.* packages.
I'll definitely have at look. That sounds very interesting!
Did you know there is another project(s) called jSLP and R-OSGI?
I've tested them and they worked very well.
> It's a 'separate but equal' API relative to the 'normal' OSGi services
> API (exposed via BundleContext). The reason it's separate is to
>
> a) Allow for programmer-controlled options WRT synch/asynch service
> invocation (i.e. rather than have everything based upon blocking RPC).
>
> b) Expose partial failure at API level rather than making the remote
> service invocation completely transparent (i.e. make it look like a
> 'normal' method call)
>
> This API is completely transport independent, and so could/would/should
> be implemented on top of Net4J and/or other providers.
I'm sure I'll come back with questions when time comes.
First I'll have to complete the Net4j JavaDocs - someone asked for them ;-)
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: ECF + EMF [message #618555 is a reply to message #618554] |
Wed, 09 May 2007 00:04 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
Eike Stepper wrote:
<stuff deleted>
>> If the notion of a channel is also pub/sub (no to question above),
>> then is there any notion of group membership or reliability/failure
>> detection in the pub/sub group?
>
> What exactly do you mean by "reliability/failure detection"?
I mean some way to tell if group membership has changed (i.e. if a
participant just drops out/crashes/network partitions).
Having some sort of group failure detection is necessary in order to
guarantee distributed state synchronization for replicated data
architectures (of which ECF's shared object API is one). The general
problem is called 'distributed consensus' and comes from this classic
impossibility result:
http://portal.acm.org/citation.cfm?id=214121
The model (exposed by shared object API) is frequently referred to as
'virtual synchrony':
http://www.cs.cornell.edu/Info/Projects/HORUS/Papers.html
http://www.cs.cornell.edu/info/projects/spinglass/pros_n_con s.htm
>
>> Further, have you (or someone else) attempted to use Net4J to
>> implement the JMS spec? If so, then an ECF provider is already done :).
>
> No I don't know of anyone who did that for Net4j.
> While this is a quite interesting thing I'm sure that I won't have the
> time for it ;-(
That is too bad...as I implied...ECF already has a provider
implementation built to the JMS spec (which has both pt-to-pt and
pub/sub channels), so any transport that implements JMS would be already
done.
>
>>>
>>> I plan to develop a remoting layer on top of SignalProtocols that
>>> integrates with the OSGi service registry
>>
>>
>> FYI, we've already done this. There's an ECF API called the 'remote
>> services' API in plugin org.eclipse.ecf.remoteservices.*. It's for
>> accessing remote OSGi services either synchronously (RPC) or
>> asynchronously (listeners for results or 'fire and go'). Here's
>> javadocs for it
>>
>> http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/
>>
>> See org.eclipse.ecf.remoteservice.* packages.
>
> I'll definitely have at look. That sounds very interesting!
You might also want to consult some new ECF API docs here:
http://wiki.eclipse.org/index.php/ECF_API_Docs
> Did you know there is another project(s) called jSLP and R-OSGI?
> I've tested them and they worked very well.
Yes, I'm aware of them.
My main criticism of R-OSGI is that the remote service invocation is
completely transparent. That is, the caller/client of the remote
service doesn't really have any indication *at the service interface
level* that the service is being provided by a remote process, as
opposed to an in-process invocation.
Although this is appealing from an aesthetic view (i.e. there's only one
way to invoke a service, whether it's local or remote), it's 'risky'
IMHO...in the sense that in terms of partial failure and performance
characteristics (among others), the remote calls are very different from
local calls at runtime (i.e. they can block for orders of magnitude
longer, or they can fail without any indication of failure).
With the ECF remoteservices API we've left the invocation 'style' up to
the client. So rather than getting a proxy to a service and calling it,
it's possible for the client to send a message to a remote service and
provide a listener for eventual callback (e.g.
org.eclipse.ecf.remoteservice.IRemoteService.callAsynch(IRem oteCall
call, IRemoteCallListener listener)), or call and block for a specified
timeout (e.g. IRemoteService.callSynch(IRemoteCall call)), or 'fire and
go' (e.g. IRemoteService.fireAsynch(IRemoteCall call)), or even get a
proxy as in R-OSGI and invoke it (e.g. IRemoteService.getProxy()).
So anyway...the main point here is to give control of the
synchrony/asynchrony to the client/service caller, by having a
remoteservices API that looks very much like the 'normal' OSGi services
API. And, of course, if desired all of this could be hidden as well
(i.e. by just using getProxy()).
But IMHO 'network transparency' can be tricky business, so it makes
sense to give an explicit remote services API rather than force
programmers to always use proxies/rpc.
Here's a brief discussion about this on eclipsezone
http://www.eclipsezone.com/forums/thread.jspa?messageID=9213 4186�
Anyway, the ECF remoteservices API takes an explicit/non-transparent
approach to exposing a remoteservices API...not to force asynch options
to be used, but rather to just make them available.
>
>> It's a 'separate but equal' API relative to the 'normal' OSGi services
>> API (exposed via BundleContext). The reason it's separate is to
>>
>> a) Allow for programmer-controlled options WRT synch/asynch service
>> invocation (i.e. rather than have everything based upon blocking RPC).
>>
>> b) Expose partial failure at API level rather than making the remote
>> service invocation completely transparent (i.e. make it look like a
>> 'normal' method call)
>>
>> This API is completely transport independent, and so
>> could/would/should be implemented on top of Net4J and/or other providers.
>
> I'm sure I'll come back with questions when time comes.
> First I'll have to complete the Net4j JavaDocs - someone asked for them ;-)
Yes, indeed...thanks.
Scott
|
|
|
| Re: ECF + EMF [message #618597 is a reply to message #618555] |
Wed, 09 May 2007 05:15 |
|
Hi Scott,
Scott Lewis schrieb:
> Hi Eike,
>
> Eike Stepper wrote:
> <stuff deleted>
>
>>> If the notion of a channel is also pub/sub (no to question above),
>>> then is there any notion of group membership or reliability/failure
>>> detection in the pub/sub group?
>>
>> What exactly do you mean by "reliability/failure detection"?
>
> I mean some way to tell if group membership has changed (i.e. if a
> participant just drops out/crashes/network partitions).
>
> Having some sort of group failure detection is necessary in order to
> guarantee distributed state synchronization for replicated data
> architectures (of which ECF's shared object API is one). The general
> problem is called 'distributed consensus' and comes from this classic
> impossibility result:
In Net4j most components (acceptors, connectors and channels) implement
ILifecycle which in turn implements INotifier. As a result you can attach
an IListener to receive ILifecycleEvents from a channel. The hypthetical
GroupManager that I mentioned as an example would be able to detect
channels that have disappeared. It's also possible to listen to IContainerEvents
of the containing connector (they are generated from the ILifecycleEvents
of the contained channels).
It'd be the responsibility of that GroupManager to do what ever is necessary
in response to such events. I assume it'd be necessary to inform the other
clients which would be done by sending appropriate Signals through the channels
of these clients. Multiple Signals on the same channel don't interfere with
each other (nor do multiple channels on the same connector). They are multiplexed
at the same time.
Do you think that these features enable us to build something like "group failure detection"?
> http://portal.acm.org/citation.cfm?id=214121
>
> The model (exposed by shared object API) is frequently referred to as
> 'virtual synchrony':
>
> http://www.cs.cornell.edu/Info/Projects/HORUS/Papers.html
> http://www.cs.cornell.edu/info/projects/spinglass/pros_n_con s.htm
>
>>
>>> Further, have you (or someone else) attempted to use Net4J to
>>> implement the JMS spec? If so, then an ECF provider is already done :).
>>
>> No I don't know of anyone who did that for Net4j.
>> While this is a quite interesting thing I'm sure that I won't have the
>> time for it ;-(
>
> That is too bad...as I implied...ECF already has a provider
> implementation built to the JMS spec (which has both pt-to-pt and
> pub/sub channels), so any transport that implements JMS would be already
> done.
Ok, I'll have a look at this PI for JMS. Maybe we don't need need a full JMS API
in a first run.
>>
>>>>
>>>> I plan to develop a remoting layer on top of SignalProtocols that
>>>> integrates with the OSGi service registry
>>>
>>>
>>> FYI, we've already done this. There's an ECF API called the 'remote
>>> services' API in plugin org.eclipse.ecf.remoteservices.*. It's for
>>> accessing remote OSGi services either synchronously (RPC) or
>>> asynchronously (listeners for results or 'fire and go'). Here's
>>> javadocs for it
>>>
>>> http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/
>>>
>>> See org.eclipse.ecf.remoteservice.* packages.
>>
>> I'll definitely have at look. That sounds very interesting!
>
> You might also want to consult some new ECF API docs here:
>
> http://wiki.eclipse.org/index.php/ECF_API_Docs
>
>> Did you know there is another project(s) called jSLP and R-OSGI?
>> I've tested them and they worked very well.
>
> Yes, I'm aware of them.
>
> My main criticism of R-OSGI is that the remote service invocation is
> completely transparent. That is, the caller/client of the remote
> service doesn't really have any indication *at the service interface
> level* that the service is being provided by a remote process, as
> opposed to an in-process invocation.
Clients interested in that information should be able to query the
service registration for some remoting related properties.
That's not the same as service API level information especially if
the service handle is passed around.
> Although this is appealing from an aesthetic view (i.e. there's only one
> way to invoke a service, whether it's local or remote), it's 'risky'
> IMHO...in the sense that in terms of partial failure and performance
> characteristics (among others), the remote calls are very different from
> local calls at runtime (i.e. they can block for orders of magnitude
> longer, or they can fail without any indication of failure).
What is "partial failure"?
I'd expect that a service remote proxy would throw some unchecked exception
in case of network errors.
> With the ECF remoteservices API we've left the invocation 'style' up to
> the client. So rather than getting a proxy to a service and calling it,
> it's possible for the client to send a message to a remote service and
> provide a listener for eventual callback (e.g.
> org.eclipse.ecf.remoteservice.IRemoteService.callAsynch(IRem oteCall
> call, IRemoteCallListener listener)), or call and block for a specified
> timeout (e.g. IRemoteService.callSynch(IRemoteCall call)), or 'fire and
> go' (e.g. IRemoteService.fireAsynch(IRemoteCall call)), or even get a
> proxy as in R-OSGI and invoke it (e.g. IRemoteService.getProxy()).
I believe that the invocation style is some sort of cross cutting concern
which does not necessarily have to be integral part of a business interface.
In general it's possible to convert either style into the other by additional
(separate) API and Java 5 makes this even easier with the concurrent infrastructure.
Of course in certain cases it could be convenient to have these offerings at the
level of the business interface.
> So anyway...the main point here is to give control of the
> synchrony/asynchrony to the client/service caller, by having a
> remoteservices API that looks very much like the 'normal' OSGi services
> API. And, of course, if desired all of this could be hidden as well
> (i.e. by just using getProxy()).
>
> But IMHO 'network transparency' can be tricky business, so it makes
> sense to give an explicit remote services API rather than force
> programmers to always use proxies/rpc.
>
> Here's a brief discussion about this on eclipsezone
>
> http://www.eclipsezone.com/forums/thread.jspa?messageID=9213 4186�
Hmm, my browser just shows an empty page...
> Anyway, the ECF remoteservices API takes an explicit/non-transparent
> approach to exposing a remoteservices API...not to force asynch options
> to be used, but rather to just make them available.
I'll have a look at this API to see how it works.
I have a suggestion on how we could proceed to integrate our technologies.
Instead of producing an arbitrary example application on top of Net4j for you
I could try to implement something that does things similar to the ones you
need to form new ECF providers (or other concepts). Could you briefly describe
which entities you need on client-side, server-side respectively? What information
do they exchange in which order and what state is maintained on server-side?
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: ECF + EMF [message #618598 is a reply to message #618597] |
Wed, 09 May 2007 15:52 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
Eike Stepper wrote:
<stuff deleted>
> Do you think that these features enable us to build something like
> "group failure detection"?
Yes. As long as the net4j channels provide ordered, reliable
point-to-point delivery, a server-based failure detector can be
reasonably easily created (or rather reused, since it already exists in
org.eclipse.ecf.provider plugin).
>
<stuff deleted>
>> That is too bad...as I implied...ECF already has a provider
>> implementation built to the JMS spec (which has both pt-to-pt and
>> pub/sub channels), so any transport that implements JMS would be
>> already done.
>
> Ok, I'll have a look at this PI for JMS. Maybe we don't need need a full
> JMS API
> in a first run.
That is true. The JMS API has a lot to it (e.g. transactions, etc) and
we would not need those things in order to use the JMS provider that ECF
already has (which is available here BTW http://ecf1.osuosl.org).
<stuff deleted>
>> Although this is appealing from an aesthetic view (i.e. there's only
>> one way to invoke a service, whether it's local or remote), it's
>> 'risky' IMHO...in the sense that in terms of partial failure and
>> performance characteristics (among others), the remote calls are very
>> different from local calls at runtime (i.e. they can block for orders
>> of magnitude longer, or they can fail without any indication of failure).
>
> What is "partial failure"?
It's the partitioning of the network OR the crashing of remote processes
in the middle of a remote invocation.
Say, for example, that a client invokes a remote method on a server, and
the server crashes before the method completes...and so a return value
is never sent and the client potentially never knows about the failure.
How does the client recover? How long does it wait to conclude that a
response is never coming? The difficult thing about partial failure is
that there is no local analog to partial failure (i.e. it doesn't really
happen with local method invocation...at least with anything near the
frequency).
This is a useful explanation IMHO of the difficulties caused by partial
failure for distributed systems:
http://research.sun.com/techrep/1994/abstract-29.html
> I'd expect that a service remote proxy would throw some unchecked exception
> in case of network errors.
This is one way. But there's still the problem of detecting the remote
failure in the first place. Another is to throw checked exceptions.
There's a large debate about checked vs. unchecked exceptions for such
things (e.g. RMI uses checked exceptions...RemoteException).
The ECF remote services API does both (unchecked exceptions for proxys,
checked exceptions for explicit synch/asynch invocations)...just to be
diplomatic :).
>
>> With the ECF remoteservices API we've left the invocation 'style' up
>> to the client. So rather than getting a proxy to a service and
>> calling it, it's possible for the client to send a message to a remote
>> service and provide a listener for eventual callback (e.g.
>> org.eclipse.ecf.remoteservice.IRemoteService.callAsynch(IRem oteCall
>> call, IRemoteCallListener listener)), or call and block for a
>> specified timeout (e.g. IRemoteService.callSynch(IRemoteCall call)),
>> or 'fire and go' (e.g. IRemoteService.fireAsynch(IRemoteCall call)),
>> or even get a proxy as in R-OSGI and invoke it (e.g.
>> IRemoteService.getProxy()).
>
> I believe that the invocation style is some sort of cross cutting concern
> which does not necessarily have to be integral part of a business
> interface.
I think it depends upon what the 'business interface' is...as you sort
of allude to below.
> In general it's possible to convert either style into the other by
> additional
> (separate) API and Java 5 makes this even easier with the concurrent
> infrastructure.
> Of course in certain cases it could be convenient to have these
> offerings at the
> level of the business interface.
Yes. For some apps it makes sense to be able to invoke services
asynchronously (in addition to/instead of RPC).
>
>> So anyway...the main point here is to give control of the
>> synchrony/asynchrony to the client/service caller, by having a
>> remoteservices API that looks very much like the 'normal' OSGi
>> services API. And, of course, if desired all of this could be hidden
>> as well (i.e. by just using getProxy()).
>>
>> But IMHO 'network transparency' can be tricky business, so it makes
>> sense to give an explicit remote services API rather than force
>> programmers to always use proxies/rpc.
>>
>> Here's a brief discussion about this on eclipsezone
>>
>> http://www.eclipsezone.com/forums/thread.jspa?messageID=9213 4186�
>>
>
> Hmm, my browser just shows an empty page...
Strange...works for me in Firefox (both yesterday and today).
>
>> Anyway, the ECF remoteservices API takes an explicit/non-transparent
>> approach to exposing a remoteservices API...not to force asynch
>> options to be used, but rather to just make them available.
>
> I'll have a look at this API to see how it works.
>
> I have a suggestion on how we could proceed to integrate our technologies.
> Instead of producing an arbitrary example application on top of Net4j
> for you
> I could try to implement something that does things similar to the ones you
> need to form new ECF providers (or other concepts). Could you briefly
> describe
> which entities you need on client-side, server-side respectively? What
> information
> do they exchange in which order and what state is maintained on
> server-side?
The basic entity for ECF is the IContainer
(org.eclipse.ecf.core.IContainer in the org.eclipse.ecf bundle).
Providers (both clients and servers) must implement IContainer.
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/ecli pse/ecf/core/IContainer.html
Then the provider plugin register's itself with ECF by defining an
extension for the ECF containerFactory extension point:
http://wiki.eclipse.org/index.php/ECF_Core_Bundle#Container_ Factory
Further, providers can implement other ECF APIs as adapters off of
IContainer.getAdapter(Class)...e.g. with datashare:
IChannelContainerAdapter adapter = (IChannelContainerAdapter)
container.getAdapter(IChannelContainerAdapter.class);
// Use adapter if it's non-null to create channel
IChannel channel = adapter.createChannel(channelid,listener,properties);
This is also documented on IContainer.getAdapter():
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/ecli pse/ecf/core/IContainer.html#getAdapter(java.lang.Class)
There are plenty existing examples of doing this...just let me know if
you want them and I'll point you to code and/or other docs.
Scott
|
|
|
| Re: ECF + EMF [message #618599 is a reply to message #618598] |
Wed, 09 May 2007 07:38 |
|
Hi Scott,
In contrast to what I said before I started this afternoon to implement the JMS spec on top of Net4j and got pretty far on the client side. I think you're right and it's of double benefit for Net4j to have JMS compliance plus ECF integration and for you it's even less effort as you said. Let's see how far I come with this approach. I'll keep you informed...
Cheers
/Eike
Scott Lewis schrieb:
> Hi Eike,
>
> Eike Stepper wrote:
> <stuff deleted>
>
>> Do you think that these features enable us to build something like
>> "group failure detection"?
>
> Yes. As long as the net4j channels provide ordered, reliable
> point-to-point delivery, a server-based failure detector can be
> reasonably easily created (or rather reused, since it already exists in
> org.eclipse.ecf.provider plugin).
>
>>
> <stuff deleted>
>>> That is too bad...as I implied...ECF already has a provider
>>> implementation built to the JMS spec (which has both pt-to-pt and
>>> pub/sub channels), so any transport that implements JMS would be
>>> already done.
>>
>> Ok, I'll have a look at this PI for JMS. Maybe we don't need need a
>> full JMS API
>> in a first run.
>
> That is true. The JMS API has a lot to it (e.g. transactions, etc) and
> we would not need those things in order to use the JMS provider that ECF
> already has (which is available here BTW http://ecf1.osuosl.org).
>
> <stuff deleted>
>
>>> Although this is appealing from an aesthetic view (i.e. there's only
>>> one way to invoke a service, whether it's local or remote), it's
>>> 'risky' IMHO...in the sense that in terms of partial failure and
>>> performance characteristics (among others), the remote calls are very
>>> different from local calls at runtime (i.e. they can block for orders
>>> of magnitude longer, or they can fail without any indication of
>>> failure).
>>
>> What is "partial failure"?
>
> It's the partitioning of the network OR the crashing of remote processes
> in the middle of a remote invocation.
>
> Say, for example, that a client invokes a remote method on a server, and
> the server crashes before the method completes...and so a return value
> is never sent and the client potentially never knows about the failure.
> How does the client recover? How long does it wait to conclude that a
> response is never coming? The difficult thing about partial failure is
> that there is no local analog to partial failure (i.e. it doesn't really
> happen with local method invocation...at least with anything near the
> frequency).
>
> This is a useful explanation IMHO of the difficulties caused by partial
> failure for distributed systems:
>
> http://research.sun.com/techrep/1994/abstract-29.html
>
>> I'd expect that a service remote proxy would throw some unchecked
>> exception
>> in case of network errors.
>
> This is one way. But there's still the problem of detecting the remote
> failure in the first place. Another is to throw checked exceptions.
> There's a large debate about checked vs. unchecked exceptions for such
> things (e.g. RMI uses checked exceptions...RemoteException).
>
> The ECF remote services API does both (unchecked exceptions for proxys,
> checked exceptions for explicit synch/asynch invocations)...just to be
> diplomatic :).
>
>>
>>> With the ECF remoteservices API we've left the invocation 'style' up
>>> to the client. So rather than getting a proxy to a service and
>>> calling it, it's possible for the client to send a message to a
>>> remote service and provide a listener for eventual callback (e.g.
>>> org.eclipse.ecf.remoteservice.IRemoteService.callAsynch(IRem oteCall
>>> call, IRemoteCallListener listener)), or call and block for a
>>> specified timeout (e.g. IRemoteService.callSynch(IRemoteCall call)),
>>> or 'fire and go' (e.g. IRemoteService.fireAsynch(IRemoteCall call)),
>>> or even get a proxy as in R-OSGI and invoke it (e.g.
>>> IRemoteService.getProxy()).
>>
>> I believe that the invocation style is some sort of cross cutting concern
>> which does not necessarily have to be integral part of a business
>> interface.
>
> I think it depends upon what the 'business interface' is...as you sort
> of allude to below.
>
>> In general it's possible to convert either style into the other by
>> additional
>> (separate) API and Java 5 makes this even easier with the concurrent
>> infrastructure.
>> Of course in certain cases it could be convenient to have these
>> offerings at the
>> level of the business interface.
>
> Yes. For some apps it makes sense to be able to invoke services
> asynchronously (in addition to/instead of RPC).
>
>
>>
>>> So anyway...the main point here is to give control of the
>>> synchrony/asynchrony to the client/service caller, by having a
>>> remoteservices API that looks very much like the 'normal' OSGi
>>> services API. And, of course, if desired all of this could be hidden
>>> as well (i.e. by just using getProxy()).
>>>
>>> But IMHO 'network transparency' can be tricky business, so it makes
>>> sense to give an explicit remote services API rather than force
>>> programmers to always use proxies/rpc.
>>>
>>> Here's a brief discussion about this on eclipsezone
>>>
>>> http://www.eclipsezone.com/forums/thread.jspa?messageID=9213 4186�
>>>
>>
>> Hmm, my browser just shows an empty page...
>
>
> Strange...works for me in Firefox (both yesterday and today).
>
>>
>>> Anyway, the ECF remoteservices API takes an explicit/non-transparent
>>> approach to exposing a remoteservices API...not to force asynch
>>> options to be used, but rather to just make them available.
>>
>> I'll have a look at this API to see how it works.
>>
>> I have a suggestion on how we could proceed to integrate our
>> technologies.
>> Instead of producing an arbitrary example application on top of Net4j
>> for you
>> I could try to implement something that does things similar to the
>> ones you
>> need to form new ECF providers (or other concepts). Could you briefly
>> describe
>> which entities you need on client-side, server-side respectively? What
>> information
>> do they exchange in which order and what state is maintained on
>> server-side?
>
> The basic entity for ECF is the IContainer
> (org.eclipse.ecf.core.IContainer in the org.eclipse.ecf bundle).
>
> Providers (both clients and servers) must implement IContainer.
>
> http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/ecli pse/ecf/core/IContainer.html
>
>
> Then the provider plugin register's itself with ECF by defining an
> extension for the ECF containerFactory extension point:
>
> http://wiki.eclipse.org/index.php/ECF_Core_Bundle#Container_ Factory
>
> Further, providers can implement other ECF APIs as adapters off of
> IContainer.getAdapter(Class)...e.g. with datashare:
>
> IChannelContainerAdapter adapter = (IChannelContainerAdapter)
> container.getAdapter(IChannelContainerAdapter.class);
>
> // Use adapter if it's non-null to create channel
> IChannel channel = adapter.createChannel(channelid,listener,properties);
>
> This is also documented on IContainer.getAdapter():
>
> http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/ecli pse/ecf/core/IContainer.html#getAdapter(java.lang.Class)
>
>
> There are plenty existing examples of doing this...just let me know if
> you want them and I'll point you to code and/or other docs.
>
> Scott
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: ECF + EMF [message #618600 is a reply to message #618599] |
Wed, 09 May 2007 18:16 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
Sounds great...thanks. If you want to know what subset of JMS we use,
see the JMS provider source (currently written to ActiveMQ) at:
http://ecf1.osuosl.org
Thanks,
Scott
Eike Stepper wrote:
> Hi Scott,
>
> In contrast to what I said before I started this afternoon to implement
> the JMS spec on top of Net4j and got pretty far on the client side. I
> think you're right and it's of double benefit for Net4j to have JMS
> compliance plus ECF integration and for you it's even less effort as you
> said. Let's see how far I come with this approach. I'll keep you
> informed...
>
> Cheers
> /Eike
>
>
> Scott Lewis schrieb:
>> Hi Eike,
>>
>> Eike Stepper wrote:
>> <stuff deleted>
>>
>>> Do you think that these features enable us to build something like
>>> "group failure detection"?
>>
>> Yes. As long as the net4j channels provide ordered, reliable
>> point-to-point delivery, a server-based failure detector can be
>> reasonably easily created (or rather reused, since it already exists
>> in org.eclipse.ecf.provider plugin).
>>
>>>
>> <stuff deleted>
>>>> That is too bad...as I implied...ECF already has a provider
>>>> implementation built to the JMS spec (which has both pt-to-pt and
>>>> pub/sub channels), so any transport that implements JMS would be
>>>> already done.
>>>
>>> Ok, I'll have a look at this PI for JMS. Maybe we don't need need a
>>> full JMS API
>>> in a first run.
>>
>> That is true. The JMS API has a lot to it (e.g. transactions, etc)
>> and we would not need those things in order to use the JMS provider
>> that ECF already has (which is available here BTW
>> http://ecf1.osuosl.org).
>>
>> <stuff deleted>
>>
>>>> Although this is appealing from an aesthetic view (i.e. there's only
>>>> one way to invoke a service, whether it's local or remote), it's
>>>> 'risky' IMHO...in the sense that in terms of partial failure and
>>>> performance characteristics (among others), the remote calls are
>>>> very different from local calls at runtime (i.e. they can block for
>>>> orders of magnitude longer, or they can fail without any indication
>>>> of failure).
>>>
>>> What is "partial failure"?
>>
>> It's the partitioning of the network OR the crashing of remote
>> processes in the middle of a remote invocation.
>>
>> Say, for example, that a client invokes a remote method on a server,
>> and the server crashes before the method completes...and so a return
>> value is never sent and the client potentially never knows about the
>> failure. How does the client recover? How long does it wait to
>> conclude that a response is never coming? The difficult thing about
>> partial failure is that there is no local analog to partial failure
>> (i.e. it doesn't really happen with local method invocation...at least
>> with anything near the frequency).
>>
>> This is a useful explanation IMHO of the difficulties caused by
>> partial failure for distributed systems:
>>
>> http://research.sun.com/techrep/1994/abstract-29.html
>>
>>> I'd expect that a service remote proxy would throw some unchecked
>>> exception
>>> in case of network errors.
>>
>> This is one way. But there's still the problem of detecting the
>> remote failure in the first place. Another is to throw checked
>> exceptions. There's a large debate about checked vs. unchecked
>> exceptions for such things (e.g. RMI uses checked
>> exceptions...RemoteException).
>>
>> The ECF remote services API does both (unchecked exceptions for
>> proxys, checked exceptions for explicit synch/asynch
>> invocations)...just to be diplomatic :).
>>
>>>
>>>> With the ECF remoteservices API we've left the invocation 'style' up
>>>> to the client. So rather than getting a proxy to a service and
>>>> calling it, it's possible for the client to send a message to a
>>>> remote service and provide a listener for eventual callback (e.g.
>>>> org.eclipse.ecf.remoteservice.IRemoteService.callAsynch(IRem oteCall
>>>> call, IRemoteCallListener listener)), or call and block for a
>>>> specified timeout (e.g. IRemoteService.callSynch(IRemoteCall call)),
>>>> or 'fire and go' (e.g. IRemoteService.fireAsynch(IRemoteCall call)),
>>>> or even get a proxy as in R-OSGI and invoke it (e.g.
>>>> IRemoteService.getProxy()).
>>>
>>> I believe that the invocation style is some sort of cross cutting
>>> concern
>>> which does not necessarily have to be integral part of a business
>>> interface.
>>
>> I think it depends upon what the 'business interface' is...as you sort
>> of allude to below.
>>
>>> In general it's possible to convert either style into the other by
>>> additional
>>> (separate) API and Java 5 makes this even easier with the concurrent
>>> infrastructure.
>>> Of course in certain cases it could be convenient to have these
>>> offerings at the
>>> level of the business interface.
>>
>> Yes. For some apps it makes sense to be able to invoke services
>> asynchronously (in addition to/instead of RPC).
>>
>>
>>>
>>>> So anyway...the main point here is to give control of the
>>>> synchrony/asynchrony to the client/service caller, by having a
>>>> remoteservices API that looks very much like the 'normal' OSGi
>>>> services API. And, of course, if desired all of this could be
>>>> hidden as well (i.e. by just using getProxy()).
>>>>
>>>> But IMHO 'network transparency' can be tricky business, so it makes
>>>> sense to give an explicit remote services API rather than force
>>>> programmers to always use proxies/rpc.
>>>>
>>>> Here's a brief discussion about this on eclipsezone
>>>>
>>>> http://www.eclipsezone.com/forums/thread.jspa?messageID=9213 4186�
>>>>
>>>
>>> Hmm, my browser just shows an empty page...
>>
>>
>> Strange...works for me in Firefox (both yesterday and today).
>>
>>>
>>>> Anyway, the ECF remoteservices API takes an explicit/non-transparent
>>>> approach to exposing a remoteservices API...not to force asynch
>>>> options to be used, but rather to just make them available.
>>>
>>> I'll have a look at this API to see how it works.
>>>
>>> I have a suggestion on how we could proceed to integrate our
>>> technologies.
>>> Instead of producing an arbitrary example application on top of Net4j
>>> for you
>>> I could try to implement something that does things similar to the
>>> ones you
>>> need to form new ECF providers (or other concepts). Could you briefly
>>> describe
>>> which entities you need on client-side, server-side respectively?
>>> What information
>>> do they exchange in which order and what state is maintained on
>>> server-side?
>>
>> The basic entity for ECF is the IContainer
>> (org.eclipse.ecf.core.IContainer in the org.eclipse.ecf bundle).
>>
>> Providers (both clients and servers) must implement IContainer.
>>
>> http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/ecli pse/ecf/core/IContainer.html
>>
>>
>> Then the provider plugin register's itself with ECF by defining an
>> extension for the ECF containerFactory extension point:
>>
>> http://wiki.eclipse.org/index.php/ECF_Core_Bundle#Container_ Factory
>>
>> Further, providers can implement other ECF APIs as adapters off of
>> IContainer.getAdapter(Class)...e.g. with datashare:
>>
>> IChannelContainerAdapter adapter = (IChannelContainerAdapter)
>> container.getAdapter(IChannelContainerAdapter.class);
>>
>> // Use adapter if it's non-null to create channel
>> IChannel channel = adapter.createChannel(channelid,listener,properties);
>>
>> This is also documented on IContainer.getAdapter():
>>
>> http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/ecli pse/ecf/core/IContainer.html#getAdapter(java.lang.Class)
>>
>>
>> There are plenty existing examples of doing this...just let me know if
>> you want them and I'll point you to code and/or other docs.
>>
>> Scott
|
|
| |
| |
  |
Goto Forum:
Current Time: Tue Apr 23 14:00:15 GMT 2024
Powered by FUDForum. Page generated in 0.05615 seconds |
] 
Search
Help
Register
Login
Home
