Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Net4j - why not ECF?
Net4j - why not ECF? [message #420461] Tue, 01 July 2008 08:55 Go to next message
Roland Tepp is currently offline Roland TeppFriend
Messages: 336
Registered: July 2009
Senior Member
Hello,

I was looking through the EMF related projects and while reading about
CDO, I found myself wandering, why you've created a whole networking
stack of your own, when there is a perfectly valid existing software
stack that would possibly solve the same problems.

Was this because ECF did not exist way back when you started with the
CDO or are there actually some technical reasons for that.

--
Roland Tepp (just curious)
Re: Net4j - why not ECF? [message #420468 is a reply to message #420461] Tue, 01 July 2008 11:45 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33141
Registered: July 2009
Senior Member
Roland,

A few times Eike has mentioned having chatted with Scott about moving
Net4j to ECF. I think that would make good sense.


Roland Tepp wrote:
> Hello,
>
> I was looking through the EMF related projects and while reading about
> CDO, I found myself wandering, why you've created a whole networking
> stack of your own, when there is a perfectly valid existing software
> stack that would possibly solve the same problems.
>
> Was this because ECF did not exist way back when you started with the
> CDO or are there actually some technical reasons for that.
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Net4j - why not ECF? [message #420491 is a reply to message #420461] Tue, 01 July 2008 14:45 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------060907030509000502090400
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Roland,

Comments below...


Roland Tepp schrieb:
> Hello,
>
> I was looking through the EMF related projects and while reading about
> CDO, I found myself wandering, why you've created a whole networking
> stack of your own, when there is a perfectly valid existing software
> stack that would possibly solve the same problems.
>
> Was this because ECF did not exist way back when you started with the CDO
Yes, that was the main reason.
Sufficient in its own ;-)

> or are there actually some technical reasons for that.
Might be the case as well. More interesting we have a 2.0 plan item to
decouple the CDO network layer from Net4j, making Net4j one of possibly
several alternatives. I've attached the diagrams to illustrate the idea.

A pure ECF implementation of this layer would also be a cool idea and
should be easily feasible with the appropriate knowledge about ECF.
Would you like to contribute such an ECF based CDOProtocolFacade?

Cheers
/Eike




--------------060907030509000502090400
Content-Type: image/png;
name="DirectFacade.png"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="DirectFacade.png"

iVBORw0KGgoAAAANSUhEUgAAAVMAAAFJCAIAAACpZFneAAAAAXNSR0IArs4c 6QAAAARnQU1B
AACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgA ABdwnLpRPAAA
HARJREFUeF7tnd+rHVWWx3v+Ev8N0WkaBl/0yRfxoXVohVFmCAz4oijxQSGQ MKQnotKEwStE
OmCQiNKJEGNso8HEcNEETdQbokSNEokSgxKC3P7GZdeUdX5UrVO7qnbV+oQi 3Ftn7127vmt9
an1rn7rn/Mvm5ubv+IcCKBBNAZHPPxRAgWgK/C7aCXO+KIACN5w+KqAACgRU APIDBp1TRgFq
PjmAAiEVoOaHDDsnHV4ByA+fAggQUgHIDxl2Tjq8ApAfPgUQIKQCkO8O+z2P rd187w623BRQ
XNyxDNwB8t3BV8ZvfHWFLTcFFBd3LAN3gHx38CE/N+ZtPpDvSmXId8l1ozHk Q747afLrAPnu
mEA+5LuTJr8OkO+OCeRDvjtp8usA+e6YQD7ku5Mmvw6Q744J5EO+O2ny6wD5 7phAPuS7kya/
DpDvjkkm5L9z+oubbt+67/XTK3PYfoSVD91FR97Vc6Uy5LvkyuhdvfbcVka4 ++HntXXBZD9j
Qr4rlSHfJddkyX9/41JC8nftPSo/oitLP8zzJI87ifk0rhUkw+3X8rztucOQ v0Jq9dmFmu9W
ux/y3zt70SqnSvGeg+sGm3Y++swB7dyy/SXtrNzn7375uBpXulQoXTKCdbT2 +ln02gReOXpW
e2QK7FdtmkNRz2fnadgXW+1lIlUD3L4rlSHfJVd/bl9sl/kx0gzs8las8NkV obwV14syWktG
sL4F+cVQdojKfDSOrgWz+zVPyHen1BAdIN+teg81/8j6Z1bYjS4Vc5VWW5DT ToNTQBY1v9L+
teMb5QJekL9kBKvzFfKLwm7jC2kbyoq/jjJ3nmqA23dnVe8dIN8teQ/kl6ku uLWdugrYnvLK
vL1ULvJljJuMMJf8SseKp9BdwNx5Qr47pYboAPlu1Xsg34p2ueaL86LAztb8 SvtFNX/JCMvJ
L2q+eZBimzvPgnz1SnUP32Qc7vNdqQz5Lrn6u8+v3JDX3ucvuYG3l3S/sHyl YNbtL18gsFfn
zlPGhBU+d2L12wHy3Xr3UPNFVLEIX17bVxW1lTb9b3W4WOEr1tjt1fKzfWXy l4xQXhqYXSYo
j1++Rsydp3YW82xSrpO0oea7UhnyXXL1V/OTwBBqEMh3pTLku+SC/Hw/gBDy XakM+S65IB/y
3QmTZwfId8eln/v8UEY9yclS812pDPkuuaj51Hx3wuTZAfLdcaHmJynRyQeh 5rtSGfJdclHz
qfnuhMmzA+S740LNT16ukwxIzXelMuS75KLmU/PdCZNnB8h3x4Wan6REJx+E mu9KZch3yXWj
8W0P7lKSTWC79f5d//bff/39A3+ZwLnoFBQXdywDd4D8oME/tP7lH3f8/a9v ntP/a4c+DapC
4NOG/HDBv3b95537P9zy7LsXLl3VyV/96frWPesP7T5x+Ydr4bQIfMKQHyv4 ov2Bp449/eoZ
8V8+8xffOn/XtiMnP/k2lhyBzxbyAwXfHP6bpy7OPeczF77H+cfJBsgPEeuK w190zjj/ENnw
y0lC/vRjvcjhLzpznP/0cwLyJx/j5Q5/0enj/CefGNT8yYa4ocPH+U82A5ae GORPM+5eh4/z
n2YeLD4ryJ9gxOXw9RbdojV87wnj/L2KjaI95I8iTE0naQ5f79jbUzqp/rHm n0rJfMaB/Hxi
0XYm5vBFfuUpnbbj/rM/a/6plMxhHMjPIQoJ5mAOX/8nGGvxEDj/TuXtc3DI 71PtTo7VkcNf
NFecfydR7H1QyO9d8qQH7NrhL5oszj9pGAcYDPIHED3VIftx+Itmi/NPFcdB xoH8QWRve9Ce
Hf5y5//I2kn+wrdtRHvvD/m9S976gEM5/CXOX3/kd+r85dZnxgD9KQD5/Wmd 5EjDOvzlzv+F
N84lOUcG6UEByO9B5DSHyMThL3H+sv04/zTB7n4UyO9e4xRHyM3hLzonlX2c f4qAdz4G5Hcu
cfsD5OnwF52XbvgFP86/fdw7HQHyO5W37eCZO/xFp6elfpx/29h33B/yOxa4 xfBjcfg4/xZB
Hqwr5A8m/fIDj8vh4/wzTaPF04L87EI2UoeP888uk5ZOCPLzitfYHT7OP698 ouaPIh7TcPg4
/1EkGzU/izBNzOHj/LPIKtx+5mEwh79932n96XvmU00yPZ72SSJjy0Go+S0F bNvdHP7fTlxo
O9Co+vO0z+DhgvzBQlA4/HMXrww2ieEOzNM+w2l/48iQP4z+0Rw+a/7D5Blr +1nprk/C15Pt
0Rw+a/5ZJSE1v9dwyOHru+u1nhfT4bPm32u2sbafidxy+FuefTfOGr5Xdtb8 vYq1aU/Nb6Oe
oy8Ov4lYrPk3USlJG8hPIuOyQXD4LolZ83fJtXJjyF9ZukYdcfiNZJpptHbo Uz7bZzXpGvaC
/IZCrdIMh7+Kav/sc/KTb/WME5/t00bDJX0hvxNhcfhJZJXzf2j3CT7VM4mY lUEgP72qOPy0
muL80+ppo0F+YlVx+IkF/WU4nH9yVSE/maQ4/GRSzhsI559WXshPoycOP42O daPg/OsUavo6
5DdVakk7HH4CERsPgfNvLNWyhpDfSkYcfiv5Vu2M819Vuf/vB/mra4jDX127 FD1x/m1UhPwV
1TOHv//Y5yv2p1sKBXD+K6sI+W7pzOHft/PtMxe+d3emQ2oFCucf5FMMU+kH +T4lzeE/ufcD
8swnXMetzflzLW4uM+Q312oTh+8Qq/em5vxffOt870ce5QEhv1HYcPiNZBq6 kTn/rXvWcWS1
oYD8Wok2cfj1GuXUAuffJBqQX6MSDr9JGuXWBudfGxHIXygRDr82e3JugPNf Hh3In68PDj9n
qpvPDee/SKvQ5H/93Y9zl4Jw+M3Ryr/lsY++WbTmL1unS3z+p9DFDEOTr3Vg pUVZVhx+F0k2
+Ji6xM9d89d+PQWgoA8+w/4nEJd8fddFJeo4/P7zr7cjCu/dBz+efdpHH/Wl LzXtbRr5HCgu
+XoCVzeBRSRw+PkkZXczmXX+2qOHMrs7YrYjByVft/d3PnFYy78KDA4/2+zs YmIV56/oywgE
/LKzoOTrb+z07L0SC4ffBV2Zj1lx/vpg7537P8x8zsmnF5R8faelHvbA4SfP pxENWDh/WT8t
/psBjPMvIvkKucjnL23jZPmiMy2cv9b5on3UQkTy5fPvePyQ1nV0CVDZl9nT Up9iry3mYk+c
S4C+yNi+ukPXfcVdq/qyfvpV+aC7/Tg66EzDka/LvMKsTQZPIdffdSkDtOlb XLXFfGs3VMbr
b/gVaFV4BV0XAuWAPmTFUqLycMe0ZWlE/j2Prd18745pbLf86c+33r9rAuei oGSSmtNIj8kk
huV2bXo0Il8DbXx1hS0rBRSUTMgnPbJKDJtMbXpA/livaLWh7e26APmQP1aK Moxc7ZQgv1ai
yA1q04OaP9arVW1oqfmQvyQHIB/y214icPsZXmJqCwPkQz7kjzUHllxxIH+C QW24eNsW6Mb9
qfnU/Nwxe+f0FzfdvnXf66czDJV3SrUX9cbktm04OPlTCqs3DRa1r02PWG5/ SilSG9q2QDfu
D/mpcE04Tm16QH7uPmXli3pjcts2hPyExKYaCvJ/AzY1vy3l8/pDfipcE44T i/z3zl7ctfeo
7uTvfvj5PQfXTUftfPSZA9q5ZftL2lm5z9/98nE1rnRJGIDuhqoNbReQzx2z a/I7CquWeyz0
Sowj658pUu9vXLL80aacUZ2w8OnXbc8dtpdeOXpWP+uH4lWlkH51jdBdVhQj 16bHpNy+Qmhh
s81iY9Etb8UKn10RyltxveghNi0PURvayZDfRVgFquGtZBDSlhKVAylzdC0w 8otNLQW/fhXw
FkFLMPu54QgtQ9+ke216TId8i6Wkt2gpMKoVZu+108RS2IqaX2n/2vENq/xN ZM2hTW1op0F+
R2EtyLdarc32qJ7br1bhlRUF+UWRV4IVqWK91Ng1Qg/5U5se0yG/THWhrO0s Ls/l+3x7qVzk
7breQ1SSHKI2tNMgv7uw2q2fFQYlhh2osqm8F+SXo2aGX9iXrb5rhCQ5sGSQ 2vSYDvlWtMs1
X+EsKsZsza+0p+avfKXo9D6/67Cadbdbfav55hnL22xJsFnZIlHhE10jQH7K N9Uqt/S19/lL
lgC6Dkz78Wsv6iuT7O3YKfnFjXRRjduE1SKu20ABbzf5VvnN5M/mg4Vprhks 5lM4Su8I7XOA
mv/r5aNYxi+v7etKbOsuxXW9WOErFo3t1XE92xeH/IRhLcjX5aNY39Vdug4h isr5UKZ97gKQ
+Xxtxf2/dwTIT1n2O1Uzq8HjkJ+V7GOZTG16TOc+fywhSTXP2tB6TfvK7bt2 +6kUCzVObXpA
/lgdR21oVybZ2xHyM7ym1KYH5EO+l/Rqe8iH/LFSlGHkaqdUe1FvC3Tj/pBf G6z+G9SmBzV/
rFer2tA2JrdtQ8jvH+zaI9amB+RDPuSPNQd4P3+CkWt/UW8LdOP+1PzaYPXf gJo/2YtCbWgb
k9u2IeT3D3btEWvTA7c/1ktDbWjbAt24P+TXcth/g9r0aET+bQ9O4SsopYW2 3z/wF23286g3
BaUxm902nEZ66HtW//Bfz406JcqTr02PRuR3mzj9jq4vUdY3pa8d+rTfw3K0 rBU4tP6lsuLN
UxeznmXSyYUjX+pd/en61j3rD+0+cfmHa0nFZLDxKXDt+s8793+45dl3L1y6 Or7Zt5hxRPJN
rhffOn/XtiMnP/m2hXp0HbcCov2Bp449/eoZ8T/uM/HPPi750grn70+Y6fQI 6PDLwQtNPs5/
Ohx7ziSsw4f8aprg/D3gjLttZIcP+XNyF+c/bqCbzT64w4f8+WnCmn8zfEbZ CodfCVv0+/zZ
LMb5j5LspZPG4c/KA/k4/+mR/pszksPX27ehntJpElHIx/k3yZNRtjGHr3fs oz2l0yRakL9M
JZx/kxzKs405fJEf8CmdJhGB/BqVWPNvkka5tTGHr/9zm1g+84H8+liw5l+v UTYtcPgNQwH5
DYXiOf+mQg3YDoffXHzIb64Vz/k7tOq/KQ7fpTnku+T69S98H1k7yV/4+oTr sjUOfwV1IX8F
0W44f32Qw6nzl1fpTJ+kCuDwV5MT8lfT7Vfn/8Ib51bsT7cUCuDwV1YR8leW 7obzl+3H+a+u
YIueOPwW4t3oCvktBdxU2cf5txXR2R+H7xRsTnPIb6/hpm74BT/OP4GUDYbA 4TcQqb4J5Ndr
1KSFlvpx/k2EatMGh99GvUpfyE8oJs4/pZiVsXD4acWF/LR64vwT62nD4fCT ywr5ySXdxPkn
1BSHn1DM8lCQ35GwOP8EwuLwE4i4YAjI705bnH8rbXH4reSr6wz5dQq1ex3n v4J+OPwVRPN2
gXyvYqu052mf5qqZw9++77QekWzei5ZeBSDfq9iK7Xnap4lw5vD/duJCk8a0 aaMA5LdRz9cX
579Er8Lhn7t4xScrrVdSAPJXkq1FJ5z/rHg4/BYJtWJXyF9RuDbdcP5l9fRJ +PqrBxx+m4xa
oS/kryBagi44f4koh6/vrtd6Hg4/QUo5h4B8p2BJm0d2/nL4W559lzX8pAnl GAzyHWJ10TSm
88fhd5FLrjEh3yVXJ41DOX8cfic55B8U8v2addNj7dCnk/9sHxx+N7mzyqiQ v4pqHfU5+cm3
eo5lqp/tg8PvKG1WGxbyV9Otq15y/g/tPjGxT/XE4XeVLi3GhfwW4nXWdUrO H4ffWZq0Ghjy
W8nXXedpOH8cfncZ0nJkyG8pYIfdR+38cfgdZkaKoSE/hYpdjjFG54/D7zIj 0owN+Wl07HSU
cTl/HH6nyZBqcMhPpWS344zC+ePwu02CpKNDflI5Ox4sZ+ePw+84+ImHh/zE gnY9XJ7O3xz+
/mOfd336jJ9KAchPpWR/4xTOP4dPqjOHf9/Ot89c+L4/CThSawUgv7WEAw1g zn9Y3szhP7n3
gxyuQQPFYayHhfyxRk7zNuf/4lvnBzkHHP4gsqc6KOSnUnKYccz5b92z3mfV xeEPE+ykR4X8
pHIONFifzh+HP1CQEx8W8hMLOtRw/Th/HP5Q8U1+XMhPLulgA3bq/HH4g8W1 mwNDfje6Djdq
F84fhz9cPLs6MuR3peyA4x776JtFa/4q3cJ47ty+/u7HucuEOPwBQ9ndoSG/ O22HHFkYz13z
1349BSD+Zyen9rpklPfj8IcMYcfHhvyOBR5ueHG7++DHs0/76KO+9MWVlXnp uy4qVwQc/nCh
6+PIkN+HygMeY9b5a48evKtMSU/gaoGg2InDHzBk/Rwa8vvRecijVJy/vIDK e/kLrXR7f+cT
h/XWgGaJwx8yVD0eG/J7FHu4Q1Wcvz7Ye+f+D4vp6G/s9Oy9fsXhDxeivo8M +X0rPuDxCuev
8q7Ffyvy+qfvtNSDQDj8AUPT/6Ehv3/Nhzxi4fy1zmd/Tq/LgcjnL22HjMoQ x4b8IVTv8Zj6
slr76g6xLZOvVX2Vd/16x+OHdLevicjn62et+ekSoLKvNlrqUwNtswuBPU6c Q3WrAOR3q28O
o+tv+PWNvarwoloXAiGtD9IQ7doOvHfBfpD51379zZ/aaFN7bXPf9s/hjJhD ewUg363hPY+t
3Xzvjglst/zpz//6H8/cev+uCZyLTkFxcccycAfIdwdfSbbx1RW23BRQXNyx DNwB8t3Bh/zc
mLf5QL4rlSHfJdeNxpAP+e6kya8D5LtjAvmQ706a/DpAvjsmkA/57qTJrwPk u2MC+ZDvTpr8
OkC+OyaQD/nupMmvA+S7YwL5kO9Omvw6QL47Jr2R/87pL266feu+10/nSVpu s+JdPVcqQ75L
rl7f1YN818UF8l2pDPkuuSA/34cXId+VypDvkgvyId+dMHl2gHx3XFLd5793 9uKuvUd1J3/3
w8/vObhuzlY7H33mgHZu2f6Sdlbu83e/fFyNK10qlnjusGqzqK9G2/bcYR3L RtYPGkF7bA66
47DxGzZrfiDNx2XmaxtT812pDPkuuVLWfHElnIrNGDP8yluxwmdXhPJWXC/K VMwddknfypiV
XzVaQf6SlkUz14FeOXq2lufmDSDflcqQ75IrGflH1j+zovr+xiWrk6q0tqRX UCTmi5pfaf/a
8Q2r/BUw5g67vK/xbBCaBxG9mpXmYy+VyV/erPmBzM7ocM3Brm0J+a5UhnyX XMnIL1Nd5LTt
LGxweW3fXioX+TKWlREqbwQu71sepzKrWfLtQIuaNT+QnZruKWp5bt4A8l2p DPkuuZKRb0W7
XPMFQ1EzZwGrtF9U8+cOu7xvQvKbHwjy3WmXugPkuxVNtcJXuaWvvc9fsgRg L8mfz64U1A6b
kPzl6xTlA0G+O+1Sd4B8t6KpyC+W8ctr+yr7tkSn/80CFNa9WLS3V8uWvkz+ 3GGX9F1Cvg1b
vs+f6/bLzRoeyMjnPt+dfOk6QL5by1TkN7+DpWUTBbjPd6Uy5LvkSnaf3ySV aeNSAPJdqQz5
Lrkgn2f43AmTZwfId8cFt+8qxb01pua7UhnyXXJR86n57oTJswPku+NCze+t jLsORM13pTLk
u+Si5lPz3QmTZwfId8eFmu8qxb01pua7UhnyXXJR86n57oTJswPku+NCze+t jLsORM13pTLk
u+S60fi2Byfy5bNC5Q//+X+33Pe/+mECm+LijmXgDpAfOPibm4+snTx1/nJo CaKePORHjfwv
5w35YcMP+WFDD/mhQw/5ocNPzQ8bfsgPG3pqfujQQ37o8FPzw4Yf8sOGnpof OvSQHzr81Pyw
4Yf8sKGn5ocOPeSHDj81P2z4IT9s6Kn5oUMP+aHDT80PG37IDxt6an7o0EN+ 6PBT88OGH/LD
hp6aHzr0kB86/NT8sOGH/LChp+aHDj3khw4/NT9s+CE/bOip+aFDD/mhw0/N Dxt+yA8bemp+
6NBDfujwU/PDhh/yw4aemh869JAfOvzU/LDhh/ywoafmhw495IcO/5Zn3z13 8UpoCaKePORH
jfwv533fzre//u7H0BJEPXnIjxp5yA8d+U3IDx1/an7Y8EN+2NDj9kOHHvJD h5+aHzb8kB82
9NT80KGH/NDhp+aHDT/khw09NT906CE/dPip+WHDD/lhQ0/NDx16yA8dfmp+ 2PBDftjQU/ND
hx7yQ4efmh82/JAfNvTU/NChh/zQ4afmhw0/5IcNPTU/dOghP1b4L/9wTVtx zpWaz9/qx8kG
yI8T6xtnemj9y6171ueSv//Y5zv3fxhLjsBnC/mxgn/t+s/6BK5jH31jp13U fBmBu7YduXDp
aiw5Ap8t5IcLvrB/4KljugSUyVe1Xzv0aTgtAp8w5EcM/pN7P5C3L8jXh3D+ ccff7VrAvyAK
QH6QQP/mNOXq5e3l8M3ty/+/eepiRCECnzPkBw3+7oMfP/3qGZH/whvn9H0b QVUIfNqQHzT4
V3+6Lod/5xOHVfz5yP2ASQD5AYP+6ynrVv+Oxw+p+MeVIPCZQ37g4G9u6r19 Ff/QEkQ9ech3
R/6ex9ZuvnfHRLZ//5+JnMi9OxQXdywDd4B8d/CFysZXV9hyU0BxcccycAfI dwcf8nNj3uYD
+a5UhnyXXDcaQz7ku5Mmvw6Q744J5EO+O2ny6wD57phAPuS7kya/DpDvjgnk Q747afLrAPnu
mEA+5LuTJr8OkO+OCeQvJ//uh5/X1v/VgbV9VypDvkuu0a/t73v99E23b9Wm HwzOLdtf0q/v
nb3YhtUy7TZ+m9FW6wv5rlSGfJdcoyF/196jwu+d01+UKXp/45IQrZBve1zk Vwa3YYs6D/nu
lBqiA+S7VR+F29/23OFZ8o1Ye6mo+SsU2LmDF+NAvjulhugA+W7V+yffcN1z cN3q8+6XjxeY
qd4az9oefeaAFXkjs9issV7SHg1ihr8g3xrP8q+dRRm3vtZl7uDlxpDvTqkh OkC+W/VByC+T
rJ9fOXq2fJdevCpWdS2YC6fu57WpV3PyiytCE/KLxpDvTqkhOkC+W/WhyDfa VbSFluq8fj6y
/pnZAbsKWPF/7fhGUZmL+3yj3X5tSf7s4NpTph3y3Sk1RAfId6s+FPll0260 Fwv1ZUdgF4jK
rXjFBVh7G2SJ259b8yHfnTFZdoB8d1jyIb+o+XL4lRt141kNynagcsvQhHxb 859rE4rBqfnu
HMqgA+S7g5AP+UKueJeusp6nVcDKnuLSsMTtl9/hs/f5y1uxKDg7OG7fnUZD d4B8dwRyIN/u
87WpJhdr+2X8tN/QtVW98qbbgUVr+2XyixH0loGZi4L82cEra/s8w+fOqt47 QL5b8v7Jn33L
LeEeoz3hgEMNxTN8rlSGfJdco3mGrwl+9l5duVw36ZVtG8h3pTLku+SaFPky 7Ya9vRE49g3y
XakM+S65JkX+2FGvzB/yXakM+S65ID9fawD5rlSGfJdckA/57oTJswPku+My sbX9yXh+ar4r
lSHfJRc1n5rvTpg8O0C+Oy7U/DxtAjXflcqQ75KLmk/NdydMnh0g3x0Xaj41 3500+XWAfHdM
bntw12S+f3ZKJ6K4uGMZuAPkBw4+px5YAcgPHHxOPbACkB84+Jx6YAUgP3Dw OfXACkB+4OBz
6oEVgPzAwefUAysA+YGDz6kHVgDyAwefUw+sAOQHDj6nHlgByA8cfE49sAL/ APxdApB8KoN/
AAAAAElFTkSuQmCC
--------------060907030509000502090400
Content-Type: image/png;
name="Net4jFacade.png"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="Net4jFacade.png"

iVBORw0KGgoAAAANSUhEUgAAAgkAAAFQCAIAAAC6aXoNAAAAAXNSR0IArs4c 6QAAAARnQU1B
AACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgA ABdwnLpRPAAA
LnlJREFUeF7tnf3PHsV573v+kvwblCZCNC+n8Ev5BeUHQk+IGlAT99CQNrFI HSkgWbLbQ2Ia
aONGPElNYwWHYwQidmWMAwQXGx8X/AgwYNcgExxkZCKCEiEUuV969QzTvV92 Z3d2d14+aIUe
3/fsNdd8r5fvzLVzz/6Py5cv/x7/gQAIgAAIgICPgLiB/0AABEAABEDAR+D3 gAMEQAAEQAAE
GgjADbgECIAACIBAEwG4AZ8AARAAARCAG/ABEAABEACBNgRYN7QhxPcgAAIg UB8CcEN9NmfE
IAACINCGANzQhhDfgwAIgEB9CMAN9dmcEYMACIBAGwIt3PC5b2xcceNOrqQQ kFHazMr3IDAz
AqSOpJKGKROUOlq4QeLOvPkuV1IIyCgzxz3dg0AbAqSOpJKGKROUOuCG/Jgv yMBtIcz3IDAK
AnAD3JBfbk3QZkEqwQ2jJDOERkUAbggK6mkaB6UO1g35cVuQgaPGO8JAoCsC cMM06T6ol6DU
ATfADV2jnXYg0B0BuCEoa0/TGG7IL90HeUaQgbsHMy1BICICcENQUE/TOCh1 sG7Ij0iCDBwx
2hEFAt0RgBumSfdBvQSlDrgBbuge77QEga4IwA1BWXuaxiVzw9Obb3zsmm37 HtucBso0ewky
cNdQph0IREUgFjcQ8hGzUFDqyGzdMLujiJZETj4/bdnxoP757OkLEU24XlSQ gaPGO8JAoCsC
cEPchBAl8wSlDrhheU1p196nlPFFRb6Bnztz8bNf/0GDG+wTuKFrzqBdHQjA Df24YdTMAzdE
eISw/b7Di9xgZrOvZqxrBRm4jkTEKJNDAG7oxw2jZp6g1JHWukGzb8u/mozv OXDSwNWHt9/z
U32o6o0+bOTl3Q8ds5m7f0vDKpbQda+11C2ugZYC1qMu9WILBTOPu6yxlbMk xBZ3jhuscT8/
6HdXkIGTyxkoVAcCHblhpJBXeFqwK2kcOfmaAm1ppOtzSw6WBB5+6nQjNStX 6PMgCX5Qp5Z5
glJHWtxgtXt3WaZ2ZRz3ucvLxhn+5RilYaFGMzmBNWj0qL7kQ0u5QS116Ra4 oY7kxigHIdCR
G8YIeaVym+opVJX0LV0sjXTjBj+xKDP400dLPmtyxaKElDNPrtxgFpUJlZ2F rxhbcwqbrVtS
buTlRvuDx87Y6mFxMm62Nz6wlYc8Rn+bBDGB3WJzB8lxSwf3vMH4wP4JNwzK GdxcBwJduGGk
kHfcYPP99ZFuycFFupKPSyMmpzVXNCQsckM6mSdXbmjkXJ8MXBXI36dk7f2F ghlpFTf4pSHj
A/fo3587mCEbS8vGSsLamxBqSnXkOkYZhkAXbhgv5G0KaNNKJY01kb6YNCyi RQx+QSlIgktB
vnDLXfNmnly5wSb+/rpBaLqZxeK6odG+dd2wyA1u3WArFf9y/uEvKXwKgRvC UgWtK0OgCzeM
F/IWtlYgskcOFrCLkb7IDaaVPch0dYggCa3cMFfmyZUbBGjj0ULr84Y1jyL8 raWr2HuxR7fs
sCnD0oUINaXKshzD7YNAF24YKeRFCfawwVYPNlVfzBWWwZfGuIt9f99KRwkp Z56MucFtSfI3
HYlj7TmS43/3LNptcrBv/X2l6y1kNURdvgTfS/S567SxpLDJCPuU+iQM7qkG gY7cMEbIa07p
dqko0u23R6siXbG8+JDSTQ39Xzh1lJBy5smYGxYfFaT/ib+TYRptgwxcTS5i oGkh0JEbpgmZ
InvpkXmCUkdae1jzMqE9XFo67xh1IEEGTithoE01CMAN4yWB3pknKHXADf1/ RK01phGDbXud
7AoycDW5iIGmhQDcMF5C6J15glIH3DBdTo/lK0EGTithoE01CMANseI9opyg 1AE3wA3VpCsG
OiECcEPEnB5LFNyQX7oPsn2QgSfMBnQFAh8hADcEBfU0jYNSB+uG/IgkyMCk KxCYBQG4YZp0
H9RLUOqAG+CGWVIHnRaOANwQlLWnaQw35JfugzwjyMCFZyCGlyoCcENQUE/T OCh1sG7Ij0iC
DJxq6kCvwhGAG6ZJ90G9BKWOFm741C27JK6M6w9v/ec//MreP/hC9iOSUQrP KwwvfwQKSB1X
fv7bV2/54Sdv+/GVN32njBwYlDpauCF/F/1oBF/ZfWznTzZvuuvnt+0+/ujx 8+/99oOSRsdY
QAAEoiDw/ge/+9mpC9v2nLx++5HvPvLS//6HZ06duxRFcl5CKuKGrRsnzMYn Xnn7rv0vyPA7
9m3q77wMhrYgAAIjIfDS+V+JDJQZRAyiB5GEOnJ5Y6ROkxVbIzeYMbRuOHTy F1pD3LDziY1D
r56/+F6yRkIxEACB8RC49Ov3H3jy3M13H9WlP/RPvy+4YTzkU5G8ysa/fOc3 4gZqTanYCT1A
YBIEGrUjLRqWdgs3TGKNWTtptTG1plntQ+cgMBECS2tHq/puzRsTKT15N/XW lFZBTa1pciek
QxCYAoH1tSO4oYEA3LDSKak1TRGv9AECIyPQsXYEN8ANwZ5IrSkYMm4AgQQQ CKodwQ1wQ0+f
pdbUEzhuA4FpEehXO4Ib4IahfkqtaSiC3A8CIyAwsHYEN8AN0bzSrzUdffGt aHIRBAIgEIJA
lNoR3AA3hDhdh7Z+rWn3gZf5DV0HzGgCAhEQiFs7ghvghghOuVSEqzVtufcZ zmsaC2XkVo/A
SLUjuAFuGD22rNZ03R2HdV4TtabR4aaDahAYtXYEN8ANE0UStaaJgKab0hGY pnYEN8ANU0cS
taapEae/IhCYuHYEN8ANs8UNtabZoKfjrBCYpXYEN8ANM0cJtaaZDUD3qSIw b+0IboAbUokM
ak2pWAI9ZkUgkdoR3AA3zBoHyzqn1pScSVBoEgSSqh3BDXDDJF4f3gm1pnDM uCNLBNKsHcEN
9XKDXv+ZxTvBqTVlmfBQug0B1Y70Fl69ilkvZNZrmVe9Z61NzNTf55I3ouNS 0fsb9NbPLLjB
2ZhaU3R3R+AsCIgG9GtQUcKde5//2akLIolZ1OjXaXZ5o98wF++CG2IhOZYc ak1jIYvckRHQ
CviBJ88pt95899H9R19XKWnkDkcRDzeMAmtSQnO3MbWmpNwJZVYh0Kgdnb3w btZY5Z43eoPP
uqE3dLPdSK1pNujpeC0CjdpRGWjBDWXYcd0oCrMxtabyXTaTEZZRO1oFdmF5 o7tPsW7ojlWi
Lak1JWqY0tUqrHYENzQQgBvKiWBqTeXYMu2RFFk7ghvghrTDbrB21JoGQ4iA 5QiUXTuCG+CG
WiKfWlMtlh55nJXUjuAGuGHkSEpPPLWm9GySh0ZV1Y7gBrghj7CMriW1puiQ liqwztoR3FA1
N8jpS43n7uNytSb9WvXR4+cz/bVq9/HSsiMCldeO1nBDnXmjrn1Kddp4ldP7 tSadctMxg9Cs
PASoHa2xqX7fUGfegBvKi/SwEfm1Jp2Oef7ie2H30zpbBKgddTEd3NAFpbzb VGvjjmaj1tQR
qNybUTsKsmC1eYN1Q5CfVNGYWlOpZqZ21MOycEMP0DK7pVob97MTtaZ+uCV4 F7WjIUapNm+w
bhjiNlXcS60pUzNTO4piOLghCoxJC6nWxrGsQq0pFpJjy6F2FBHhavMG64aI XlSFKGpNyZqZ
2tEYpoEbxkA1LZnV2ngkM1BrGgnYULHUjkIRC2pfbd5g3RDkJzReggC1prnc gtrRBMjDDROA
PHMX1dp4GtypNU2Ds3rRiu3+x8/Kn3Xqyf6jr3PqyajIV5s3WDeM6lc1Cvcz F+c1RfQAqx1t
3Thx/fYj+gX72QvvRhSOqFUIwA3l+0a1Np7LtKfOXbpr/wvX3XF4x75Nzmsa YgWH5J17nwfJ
IUj2uLfavMG6oYe3cEsAAm62e8POJzivKQA4akdBYI3WGG4YDdpkBFdr40Qs QK2poyGoHXUE
appm1eYN1g3TOBi9fIQAtaZV3kDtKME4gRsSNEpklaq1cWQcI4mj1uSAZN9R JJ8aRUy1eYN1
wyj+hNDuCFRba6J21N1JZmwJN8wI/kRdV2vjifAd3E09tSZqR4OdZToB1eYN 1g3TORk9dUGg
4FoTtaMuDpBaG7ghNYvE16daG8eHchKJxdSaqB1N4i9jdVJt3mDdMJZLITcW AvlWYPLVPJbt
CpADNxRgxJYhVGvjMkyb0eyb2lEZLmejqDZvlLxu0Blk/jFkDRsrgEvy4HrG kmzmzYi96vGW
HiNV0tDBke7GRt7wv+ohPKNbSuYGHUy2bc/JpTbW6ZU66icjO6HqIgLpVGzS 0QQ/GY6A8obO
rVqVN3Q42PAuspBQMjdoHrfl3meOvvhWY22oeYFOsuRk4ywctFXJ0Nm6Ir/L cXU65XT3gZfX
957sCqYVNBqsQUAepbO/xPeLeaOq+lLJ3CDTihh0xr2M7dcNtWJ44MlzhEdh CHTM1OcvvqfI
11tx1gxf8wZlATeraLQMZaPCcK5hODK9ppUNbtBcYePQqzUM38ZYODdohFoe qoLkuEHzQYW9
sQX/FYlAa4VHkS8fWLVwlG/ctvv40tlDq+Qi8axzUPIBvX3EzxuaUlSVN8rn Bs0TrYJk60G/
ylSn01cy6vWze6V+Bf/SUNey0i83C66OK5JKgK1kmJpEigz05NnyhrylSymy JHDK5wZZS4tB
vTlANtabFP2n0yUZkrGsQmBVZhcBLD5X1BLTFSGpHVXuVEoaSh3KG5pJ6HV7 taFRBTeI/DUF
0AvItIDgTYq1ubgbb6MipNQvGvBrRydeeVseIi6hdlStk/gDV7FBeUMuodRR Yd6oghtkb80H
r/3modadJ4RE8Qj4qwEtIuUVogSN2mqPmh5qnijOkMOwk614Z2gdYM15o4Ub PveNjStu3FnG
9em/evCKP/nbAsYio7T6dNwGJbmBc4BP3PK9z3ztIXHDNX998ON/+t0/uv1R /a3/X/Wl+wpw
ksYQpveZuB44lzTNJDRdqHOW0MIN8rAzb75bxqVti2UMREaZOFQKcIOnX3zr kWfO/93DL237
p3/70j3/KhrQ+mDrxv/TJ//36dceffb8wRNvNL796veP27dPbF7I3XOm95ly 5hNFTChtrhA0
RaiIG3IPb6f/9HFeADds//GpW793TLn+nx8/+9i/vdnqDOIDsYLaiyFEIblP LPCZVovX0CDI
DeCG/FZFQQaOssIogBtqiPw1Y8RnKncAG36QG8ANcEM7fcANuWeWoKTQ7hAd WuAzCfpMkBvA
DXBDe6AT5wnGeZBKQUmh3SE6tMBnggw0TeMgN4Ab4Ib2QCfOpwnd8XoJSgrt DtGhBT4znjV7
Sw5yA7gBbmgPdOK8dzQmcmNQUmh3iA4t8JlETO+rEeQGcAPc0B7oxHmCcR6k UlBSaHeIDi3w
mSADTdM4yA1q4YanN9/42DXb9j22OY0NRu0lyMAdori9SZQ4L8kEo9p3DOGZ +swQKPC3RfSC
3ABuYN0AN+ThA5rZaH7jT3G27HhQ/3z2dPtP84KSQrtDdGgRZT4BNwxBAG7o FNglTSIyjfOS
TBA3YhvSdu19ShlfcPmfP3fm4me//oMGN9gncMNSc+BvcAPc0GEWN6xJlDkg sdqRUbbfd3iR
G4ww7KsepdFM5xMdEYMbOgIV5AaF1JQ0dbLg0Uxqz4GThpQ+vP2en+pDLb31 YSOodj90zKZd
/i0dIZ63WZCBh5HCf93dhRtGMsFSscJ/lfksgcrcZlz9IQmWUuUGbjLesVn3 jqTPUq9odOQ3
01LAnFaXHNV0M1XdZTKNVjUWKys5brDGXbwxTZ/povmqNiP5m7A1z5G3HDn5 mnpfaiZ9bpY1
Cz781OkGo8vQ+jxIwhA0Ot4b5AaFcIMVXt1lYebW4O5zF1TGGf7lGKUjyjM2 CzLwZNwwkgmW
il1jvoZZG/+UNDNcx2ZBHSlBLHrFYkeuWWNocleloaXcoJamOdzgEB7D35TK jaeFs5K+pYul
Zmq4kFrKrLrXcb8lH9O2o4QJUkpQ6iiBG8yiMoBCyyZ6mlPYVMvlAj+oGu0P Hjtjq4cJbBOl
iyADT8MNI5lgqdj15rNcbPnX5nQKdTmGXMK+8rlhfbPuHdmqVN2t4gbryG9m wsUEdoupKld0
Swe3xDHXtX/CDQbXqP4mh7H5vutoqZnMnZyZ5GMujZh65g9rDN2QECU5rBcS lDpK4IZGwBg6
9qGjcb/YbV/5CwU/a0xgoYFdBBl4Gm4YyQRrxK4yn2/Kxu2L3OC7iltTumbr /cSXZt7lMohv
31XN3KYjf2FhFNKoTjRWEtbe+qq2pjSSvzn+tmmlzLrGTItJw8whMvALSkES BmaG1tuDUkcJ
3GATf3/dIKO6mcVi/Dfas25o5Y/W5w0jmWCp2PXmi8gN3TvqwQ1uOmmLXf9y KcZfUvgUAjeM
5G/OClYgskcOhvaimRa5wbSyJ2GuDhEkoTW5D2xQHTcIr8ajhdbnDWseRQxE f4Lbgwzcmve7
NGjlhrgm8Ldmhlo2IjcsDkrCF5cXatbgBl//NcuLRSc057FZ59K1LDUlF1+h jrEm5J29RAn2
sMGqf7Y4W2WmpQZyhvM3HQRJGDWBBKWOEtYNQtNtSfI3HYmx7SmQ438X2G6T g33bY1PgqCaM
WDTskvpb23Thhogm8HPrUrFrzLeGG/zHgx2bdezIuME9b1jPDa6ZL9zXR587 v214gs1n2acU
N+SdvWRHt/tAZrIfjqwykwyx+JDS8br/85QgCaMmlhq5YVRAUxMeZODWvN+l QRduSA2lGvTx
2S7H+UQNNkpqjEGpo5B1Q1IGGFuZIAN3Sf2tbeCGsW0aKt9WKkunrktF4TOh CBfZPsgN4IZO
P6tOylGCDNya97s0gBuScgArdBgx2LbX1gufaYWohgZBbgA3tMdVak4TZOAu qb+1DdyQmg+E
6oPPhCJWZPsgN4Ab4IZWargMN+SeKYKSQrtDdGiBzyToM0FuADfADe2BTpwn GOdBKgUlhXaH
6NACnwky0DSNg9wAboAb2gOdOJ8mdMfrJSgptDtEhxb4zHjW7C05yA3gBrih PdCJ897RmMiN
QUmh3SE6tMBnEjG9r0aQG8ANcEN7oBPnCcZ5kEpBSaHdITq0wGeCDDRN4yA3 gBvghvZAJ86n
Cd3xeglKCu0O0aEFPjOeNXtLDnKDFm741C27JK6M6xO3fO/qW+//gy9kPyIZ pUNsxmxSkhss
deZifGNVqOIzPZLYlZ//9lVf3tDV4940bwlygxZuiJlg5pZ1/uJ7G4devWHn E7ftPv7o8fPv
/faDuTWi/1QQwDdSsUQaevzs1IU79z5//fYj333kpZfO/yoNpabWoiJucNCe eOXtHfs2ZXj9
X39PDTn9JYwAvpGwcUZX7eyFd0UGygzb9pwUPbz/we9G7zLhDmrkBjOH1g1a PWgNoZWE1hOa
OSZsJlSbFAF8Y1K45+7s0q/f33/09ZvvPqrrgSfP6Z9za5RE//Vyg4Pfrycc OvkLak1JOGYa
SlBrSsMOY2lB7WgNsnDDR+C4esJd+1+g1jRWOOYpF9/I027LtaZ21MWacEMT JVdPuOmun6vW
9Mt3ftMFR9rUgAC+kbWVXe1IoU3tqNWUcMNKiKg1tXpPtQ3wjbxM72pHKglU u+8o1GRwQzti
R198SzuarrvjMLWmdrAqa0GtKWWD+7UjPUqsfN9RqKXghq6IWT1hy73PUGvq Clk17ag1JWXq
Ru2IsnA/68ANwbipnrD7wMv2Gzr2NQXDV/QN1JrmNS+1o4j4ww39wfRrTafO XeoviDuLQ8Bq
TdQhpzEstaMxcIYbhqLq15ruf/wsC9ihgBZ0P3XIUY1J7WhUeOGGaPC6WtPW jRM8+IoGaxGC
qEPGNSO1o7h4LpUGN8QHWY7r6gnUmuLjm7NE9rwNsZ4oVucd6VGfzjti+jUE yS73wg1dUOrT
Rgte7WvSCS3a10StqQ+C5d5DrSnItn4o6TdrlG2D0OvdGG7oDV3XG91kh1pT V8iqaUcdcr2p
/SU4v1mbOCzghukAp9Y0Hda59cSeN99iTKdS8F+4YWorUGuaGvF8+qt8zxuh kZSrwg2zmYMH
a7NBn3zHtdWaWFIn6JJww/xGYUPe/DZIVYOya03UjlL1uw/1ghtSsQ4/5EnF EunpYbWmYva8
UTtKz8WWaAQ3JGcmDgBIziTJKJT7RJvaUTKu1K4I3NCO0VwtqDXNhXz6/eaV ZHOntPT9YQwN
4YYxUI0pk1pTTDTLkpV4cSZx9cryhfijgRviYzqSRGpNIwFbgNjUJuZ5LWsK cIAxhgA3jIHq
uDIVeDpP5vrtR3S2DD8WHRfr3KRbUpZvzPLyy9QoKjfrpaUv3JCWPbprowW7 zpbR3hVdvBi9
O241tJz4ACKOhyrSqeCG7M2qpYMWEJoqajGhaSMvxc3eovEGMPbvKzlWNp6t kpMENyRnkn4K
iRKoNfWDroa74taaeB1FDT4DN5RmZWpNpVk03ngG1pqoHcUzRQaS4IYMjNRP RWpN/XCr4a7Q
WhO1oxq8ojFGuKFwo1NrKtzAw4a3/veV1I6GoZv33XBD3vbrrr3VmvQSOvY1 dQetkpaN31f+
+y9/reObttz7jLxl49CrvGetEjdg3VCnoT8atWpN2vyufU137n1e08ba4WD8 HgL7j772p7ue
vvabh2782yf/8cDL7Hmr2TtYN1RqfYW93sbufkOnH11XCgTDvnx5sXbEWV74 BdxQuw+oYuBq
TfuPvq7yQu2IVDP+1n1HjVoTvlGNa3w4ULihKnOvGyy1pnpcwe070gEbJ155 u3Xg/lle/L6y
Fa4yGsANZdgx2iioNUWDMj1Bfu1IT5u1bgjV0dWaOMsrFLrs2sMN2ZlsIoWp NU0E9PjduNrR
DTuf0L4jMcTAPl2tiT1vA5FM+Xa4IWXrJKHbqXOXtK/pujsOs68pCXuEKKF6 kapGsl3H2lGI
7A/bUmsKRSyj9nBDRsaaU1WrNW3dOGFngw+fe845mNL7lnW0PtAq4bbdx/vV jkIRotYUilj6
7eGG9G2UloaqNd3/+Fn7DZ3yDntX0jGP1Y7EB7FqR6FD4yyvUMRSbg83pGyd pHVztSbVK/gN
3bymstqRlnQj1Y5CR8dZXqGIJdgebkjQKDmp5GpNmqtSa5rYctPXjoIGyFle QXCl1hhuSM0i
uepDrWkyy81eOwodKbWmUMRSaA83pGCFonRQfcP2NVFrim7X1GpHoQNs1JpC b6f9lAjADVOi
XVFfmttqX5M9F6XWNNDwideOQkfXqDVxllcogNO0hxumwbneXlRr0n5Kt6+p x29xq8XOrx3t
PvByefuG/VoTZ3ml5udwQ2oWKVYfv9ak83yKHWeMgfm/WasBK1dr4veVMdwn jgy4IQ6OSOmI
gF9rKnIu3BGHpc1c7Ujv1ZnmN2tDtI1+L7Wm6JAOEQg3DEGPe/sj4GpNdeZB H7jia0ehXkKt
KRSxMdrDDWOgiswABGqrn/jQ1Dz2Li5CrakLSiO1gRtGAhaxYQhUNXeuvHYU 5hmXL3NufChi
UdrDDVFgREg0BArOmzxrGeglnBs/EMCg2+GGILhoPB0CJdVb2KMV1294R2Fc PJdKgxsmAJku
+iOQ3fkQ/lB53t7f8B3upNbUAaT+TeCG/thx55QIZPTbYGpHUzqG+vJrTZwb Hwt8uCEWksiZ
CIGx32U2ZBicJTUEveH3uloTZ3kNBxNuGI4hEmZAIPo7kIeMoXEuCO87GgLm 8HtdrYmzvIaA
CTcMQY9750dAtSb9vrr7+y/1SiLNLlv1NrHrm3GeYCuM8zYIrTXpdEit/ObV OZ3e4YZ0bIEm
gxDQuUOqJNjZ4GsiXF/p/WjKGms6U9LX4YBrXmZH7WiQqSa/uWOtSSfCapJR 3pmG/fCGG/rh
xl2JItCl1qQjP/Wya1UeVo1h256TOjt28VtqR4lavZtaXWpNmhBoWsBpwUIU bujmVrTKDYH1
tSatLXTk59IxqZQkbvC/onaUm/Fb9F3/jsJFByhs+B2HAzd0BIpmuSLgak16 G52rNWkKqfcO
LS4OVHH2p43UjnK1eje99fBp6TsKNTlofdrUrYeMW8ENGRsP1bsjYLUmlZKU +kUJmjnqUnHZ
fzuCqtJWbqZ21B3YAlparWnrxgm3r8keOOnDAkbXewhwQ2/ouDFLBJT69Y5S 29dkc0Z7J6VR
hQpNvMc0S7vGUNqvNWndIN/osqUtRs8pyoAbUrQKOk2AgJ466tUR137zkGaI b73zW1GC/hY9
PPDkuQl6p4uUEbAn0uYP67e0pTyKgbrBDQMBrPf2z31j44obd2Z0XXnTdz5x 871X//meT972
48987SFF/v/c+vCn//In+uTjN//9VV/e+ORf/OgzX9t/zV8f1Ff6Q82u3vJD 3XLl57+d0TBl
lxScMiP3+P3/9X9kZecA1277F10fOsBX9soB5DYZWX+9qkG+ATekEEdZ6iAv PPPmu7lct37v
mGaCX/3+8b97+KUfP/nvT2xeWKP55mvvHDzxxj8efOVvfrKpG7+462guw5Se sksK/pSRe8gr
ZOVv/eg5+YbsfuzlixmZO0jVIN+AG1KIoyx1yCj4g+In98ZB8T+e5+EeCTpS kG/ADeNFR+GS
Cf4Eg591Q5pGSUQruKHwpJzI8OCGRAK+oUZQ/I/nS7hHgu4R5BusG8aLjsIl E/wJBj/rhjSN
kohWcEPhSTmR4cENiQQ864Y0DZGgVnBDIsmzcDXghgSDn3VDmkZJRCu4ofCk nMjw4IZEAp51
Q5qGSFAruCGR5Fm4GpNxw9Obb3zsmm37HttMMNgSVCko/sfz0cncI0ETJKtS kG/wLHq86Chc
8mTBDzcE5Zqg+B/PRydzjyBwIjbWZEVTFn/WsmXHg/rns6fX/awyogI9RAX5 BtwwXnQULnmy
4IcbgrJAUPyP56OTuUcQOD0a79r7lDK+nNC/97kzFz/79R80uME+gRvGcyok 54HAZMEPNwRl
NLghCK7WxtvvO7zIDUYY9lVG1c4g32DdkEciTlDLWNygeZZFmqZdew6ctFjV h7ff81N9qHW6
PmxE4O6Hjtkczb+lEeRLxarNqnst1NWXSdYfkmDBLx3ctLFjs+4dSZ/W9BTU ICj+x/OrWO4R
NPbWxg3z+eBrKWB+qEu+ZxY3B3CXybfJijzEykqOG6xxqw4zNgjyDbhhvOgo XHKs4Lcqrbss
Jt2C3X3uItA4w78co/hRt1TsmnsbMhv/lDQT3rFZUEcPP3U6Yr4Iiv/xfDSW e0REZqn5HPgN
h5EHii2WcoNamj/ADeP5D5IzRiBK8B85+ZpNzBWHNtfWbN3mZS4d+xHYaH/w 2BlbPTQyyFKx
6++1pG+ZwuaPyu/SSvrYVz43rG/WvSNbEqm7iBkQblgDpm9lH3wzmZjA7jUH kHe5pYNbOJo3
2j/hhozzF6qPh0AUbmhEl0WmfejW+/7zBvvKXyj4idslhTViV93ry2ncvsgN vp5uQeOarVfS
l2ZDcykpCkPADa3c4JeGDHy36chfF9oMoPG8obGSsPYmhJrSeNkGyTkhEIUb bOLvrxuULt28
ezEFN9qvWjcsFbv+3ojc0L0juCEKHXYXsoqY3brB1q/+ZRlfDfwlRaO0CDfk lLnQdWwEonCD
4q3xaKH1ecOaRxH+JsJQsRG5YXFQEr64vFAzuKF7Wo/Scs2ibdGvrEetXx0T NHSgpjR2kkF+
lgjE4ga3JcnfdKRpmj0b1P9tTudyq9uAZN/6Owh9blgqds29a7jBxPrPG5bW lPxmHTsybuB5
Q5S830XIIjc48H2T+c30uXPFRhcqOvmeSU0py0SG0tERiMUNXUKaNt0R4HlD d6zitvQnB3El
x5IW5BvsYY2eM2sRCDfEiti4coLifzxnrco9bP2na3HLXFzjDpQW5Btww3jR UbjkqoJ/YExO
eXtQ/I/no1W5h210FjHYttdkryDfgBvGi47CJVcV/MlG+6JiQfE/no/iHgn6 TJBvwA3jRUfh
kgn+BINfKgXF/3g+insk6B5BvgE3jBcdhUsm+BMMfrghTaMkohXcUHhSTmR4 cEMiAd9QIyj+
x/Ml3CNB9wjyDdYN40VH4ZIJ/gSDn3VDmkZJRCu4ofCknMjw4IZEAp51Q5qG SFAruCGR5Fm4
GnBDgsHPuiFNoySiFdxQeFJOZHifumWXXK2M66o/+/6VN32njLHILil4SAHu 8fEv3vPJv/jR
VV/eKMMxNIog3+B5QwpxhA4zI7B148Spc5dmVoLuE0Dg0q/fP3TyFzv2bV6/ /chtu48/8OS5
sxfeTUCvGVSAG2YAnS5TQwBuSM0iE+sjAhANiAxECSIG0YNIYmIdUusObkjN IugzAwJwwwyg
z93l+x/87menLty1/4Ubdj5x891Hdx94+aXzv5pbqYT6hxsSMgaqzIUA3DAX 8tP3e/7ie/uP
vr5tz8nr7jh8597nHz1+/pfv/GZ6NdLvEW5I30ZoODoCcMPoEM/dwYlX3tbK 4Ka7fq7ru4+8
dPTFt7RumFuppPuHG5I2D8pNgwDcMA3OE/eiZwZaFmhxoCWCniVouaBFw8Q6 5Nsd3JCv7dA8
GgJwQzQoExCkxwYbh17dcu8zepCgxwl6qPDebz9IQK/MVIAbMjMY6o6BANww BqpTylT2twfL
2mgkVhA38GB5IP5ww0AAub0EBOCGTK2oGpHtPbUHy+w9jWhHuCEimIjKFQG4 ISPL6RmyniTr
ebKeKtveUz1nzkj/XFSFG3KxFHqOiADcMCK4kURrp6k9WL72m4e0A1UPltl7 Ggna5WLghlHh
RXgeCMANydrJ9p5qfaAHy+w9ndJMcMOUaNNXogjADUkZhkONUjAH3JCCFdBh ZgTghpkN8J/d
61Cj+x8/q11G7lAj9p7OaBe4YUbw6ToVBOCGuSzh9p7aoUbsPZ3LEIv9wg3p 2AJNZkMAbpgY
eg41mhjwHt3BDT1A45bSEIAbprGoHizb3lN3qNE0/dJLDwTghh6gcUtpCMAN 41nU7T3Vz9OE
M4cajQd1XMlwQ1w8kZYlAnBDdLNxqFF0SCcWCDdMDDjdpYgA3BDFKvZg2V6o qe1G2nRU7Qs1
o+A5rxC4YV786T0JBOCGIWbghZpD0Ev2XrghWdOg2HQIwA2hWLtDjdwLNTnU KBTDxNvDDYkb
CPWmQABu6IiyHizbCzXtUCNeqNkRtxybwQ05Wg2dIyMAN6wH1B1qxAs1I3te wuLghoSNg2pT
IQA3LCLtDjWyF2rqNQk8WJ7KH5PoB25IwgwoMS8C2lRD4jMTCAd7oaYdasQL Nef1zBl7hxtm
BJ+uU0FApZKaXwbgH2rECzVTccq59YAb5rYA/SeAQJ3cYIcaqZ5mL9TkwXIC npiQCnBDQsZA
lbkQqIob3As17cEye0/n8rrE+4UbEjcQ6k2BQPHc4B9qZC/U1KJhCmTpI1sE 4IZsTYfi8RAo
lRt0qJF7oeZd+1/Qg2X9Zi0ebEgqGQG4oWTrMraOCJTEDf4LNfVgmb2nHX2A Zg0E4AZcAgQu
F8ANHGqEH8dFAG6IiyfSskQgU26wQ41ULHKHGp06dylLA6B0egjADenZBI0m RyAvbnAv1NSh
Ruw9ndxZaukQbqjF0oxzDQJZcAOHGuHDUyIAN0yJNn0likCy3GAPlrU4cIca sfc0UR8qTi24
oTiTMqBwBFLjBvdCTR1qZHtPdaxF+LC4AwT6IwA39MeOO4tBIAVu4FCjYtyp jIHADWXYkVEM
QmBGbrAHyzoE2w41UgVJdaRBg+FmEIiBANwQA0VkZI7AxNzgXqipfm+++6h+ usyhRpl7UIHq
ww0FGpUhhSIwDTe4Q43shZocahRqJtpPiQDcMCXa9JUKAqrb+KWbBjfEfZeD fo/mH2qkX6tx
qFEqfoAeqxGAG/COGhFQWV8zdzdynxs0ndfWoIGg+Ica8ULNgWBy+ywIwA2z wE6nMyOgmbvO
odMU3vRw3KCcrm2jvX9DYIcauRdq8mB5ZjPT/QAE4IYB4HFrzgiIGPQc2Mo7 jhu0YtDbkvWJ
ykr6sMvxRJKg3x/4hxrp1wk5A4PuIPAhAnADflAvAtozqgqS4wbN+nVonXK9 fmog2tA7MtdA
4w414oWa9TpQ0SOHG4o2L4Nbi4DyuypIqiPZukG1IPsFsv64//GzS2+1Q43U 3l6oyYNlXKxU
BOCGUi3LuDohoESvFK9ELzLYunHCnkM0iEHkoTWEHWqkNuw97YQsjTJHAG7I 3ICoPwwBrRJU
R1LS1wLi9Bu/0uYlt0nJHWqkBhxqNAxm7s4PAbghP5uhcVwEtA7Qj9H+/tHT IgYtDlRW2rFv
U1ShBYSeS+shRNzukAYCWSAAN2RhJpQcFwGxws6fbIohtIAQMbD3dFy4kZ4D AnBDDlZKUsfP
fWPjiht3lnFdedOuq2+9/zNfe+jabf/y6b968OotP/z4F+/JdGiyS5L+glKZ IQA3ZGawdNRV
6jzz5ruFXXrG8Mgz57+9/4Uv3fOvf/ytw1/9/nHVmp7YvJDRMGWXdJwETfJF AG7I13Yza14k
N/gc4HjiWz96Dm6Y2dvofnIE4IbJIS+lw+K5ISM+8FVl3VBKhM08DrhhZgPk 2z3ckCZ5wA35
xlRSmsMNSZkjJ2XgBrghJ39F10AE4IZAwGj+/xGAG+AGoqFgBOCGgo077tDg BrhhXA9D+qwI
wA2zwp9z53DDem747Nd/oGt6/uB5Q85RlZDucENCxshLlay5Yd9jmx+7Zpsu /WHpe8uOB/XP
Z08P+imDzwcmH27Iy6vR1iEAN+AMPRHIght27X1KCfrpzTf8HP3cmYtK4g1u sE+CuKEh3MS6
tQLc0NOxuC0NBOCGNOyQoRZZcMP2+w4vcoPldPvKrRt6TPCXCndy4IYMnRqV P0IAbsAbeiIw
PTdYQt9z4KTN8Xc/dMwlYs3ZLePruv2en9pCwXK3u6yxvtInEmJlJccN1niR IfShWwrYvXbL
UuF+Y7ihp2NxWxoIwA1p2CFDLWbhBj/X6++HnzrtPy1w3yqbiy2Wpm89V9Cl u7pzg+OMLtzg
GsMNGTo1KrNuwAcGIzAXNxgfaOKv5Ku1gv4+cvI1W1IYT9gC4uCxM2527543 GB/YPwdyw6Jw
feLzAdww2MUQMCcCrBvmRD/rvufiBr80ZHzgNh35qwqjkMYjgcZKwtqbkDU1 paXrBrgha+9F
+VYE4IZWiGiwHIF0uMGtG1RHajwwsIyvBv6SolGY6sINtn9p6VLDCWfdQKiU hADcUJI1Jx1L
OtygpOz2pDaePOt5deMTRx5rakr+flb73YN/ucfXi8KpKU3qgnQ2JgJww5jo Fi07BW6w5w26
NK93+5T8BK3PLbnb82f/UtFp1T4lnxucBG1/sgWK44ZF4Y19SvwuuugIKHxw cEPhBh5veNNz
w+IG04ifGB9EFDiXKM7MGM/nq5IMN1Rl7piDLYYbbGeqP+WfK61H6RduiOnl FcuCGyo2/rCh
F8MNKg0ZMdi219wvuGGYX3P3fyEAN+AKPREohhtyJ4OG/nBDT4fmtv+OANyA R/REAG5Ik1Tg
hp4OzW1wAz4QBQG4AW6I4kgISRMB1g1p2iUDreAGuCEDN0XFvgjADX2Rq/4+ uAFuqD4ISgYA
bijZuqOODW6AG0Z1MITPiwDcMC/+GfcON8ANGbsvqrchADe0IcT3KxCAG+AG gqNgBOCGgo07
7tA+dcsu0QNXagjILuMaHul1IAA31GFnRgkCIAACIQjADSFo0RYEQAAE6kAA bqjDzowSBEAA
BEIQgBtC0KItCIAACNSBANxQh50ZJQiAAAiEIAA3hKBFWxAAARCoAwG4oQ47 M0oQAAEQCEEA
bghBi7YgAAIgUAcCcEMddmaUIAACIBCCANwQghZtQQAEQKAOBOCGOuzMKEEA BEAgBAG4IQQt
2oIACIBAHQjADXXYmVGCAAiAQAgCcEMIWrQFARAAgToQgBvqsDOjBAEQAIEQ BOCGELRoCwIg
AAJ1IAA31GFnRgkCIAACIQj8B1E5PvxOcdWNAAAAAElFTkSuQmCC
--------------060907030509000502090400--


Re: Net4j - why not ECF? [message #420494 is a reply to message #420468] Tue, 01 July 2008 14:58 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Hi Ed, Roland,

Yes, mostly correct ;-)

To be exact, Scott and I worked together to develop a Net4j based ECF
provider:

203406: Develop an ECF provider with Net4j
https://bugs.eclipse.org/bugs/show_bug.cgi?id=203406

At the recent EclipseCon we agreed that we want to continue this work
during the summer.
Btw. there is already an indirect integration between Net4j and ECF via
the experimental JMS provider implementation on top of Net4j.

So far I did not talk with Scott about a move of Net4j from Modeling to ECF!
Well I cc'ed him so this might be a start ;-)

I talked to Nick about this and we decided to let sleeping dogs lie
until the Ganymede preparation efforts are over.
Note that this transition would be of a purely organizational nature,
although it might have technical influences as well.
My main precondition to concretely think about this move is that ECF
fully supports Nick's build infrastructure.
I'm not going to maintain two different builds!

Cheers
/Eike




Ed Merks schrieb:
> Roland,
>
> A few times Eike has mentioned having chatted with Scott about moving
> Net4j to ECF. I think that would make good sense.
>
>
> Roland Tepp wrote:
>> Hello,
>>
>> I was looking through the EMF related projects and while reading
>> about CDO, I found myself wandering, why you've created a whole
>> networking stack of your own, when there is a perfectly valid
>> existing software stack that would possibly solve the same problems.
>>
>> Was this because ECF did not exist way back when you started with the
>> CDO or are there actually some technical reasons for that.
>>


Re: Net4j - why not ECF? [message #420504 is a reply to message #420494] Tue, 01 July 2008 16:12 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Hi Eike and EMFers,

Eike Stepper wrote:
> Hi Ed, Roland,
>
> Yes, mostly correct ;-)
>
> To be exact, Scott and I worked together to develop a Net4j based ECF
provider:
>
> 203406: Develop an ECF provider with Net4j
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=203406
>
> At the recent EclipseCon we agreed that we want to continue this work
during the summer.
> Btw. there is already an indirect integration between Net4j and ECF
via the experimental JMS provider implementation on top of Net4j.
>
> So far I did not talk with Scott about a move of Net4j from Modeling
to ECF!
> Well I cc'ed him so this might be a start ;-)

I would love to have a Net4j provider that implements one or more ECF
APIs (likely datashare, possibly remote services and/or shared object APIs).
Further, I would like to attempt to enlist Eike, Net4j, Ed, and the
wider EMF community cooperatively in work we are beginning to do for
'replicated model synchronization'. Just to explain this a little
bit...we recently have done some work in real-time shared editing

http://wiki.eclipse.org/DocShare_Plugin
(see bottom for technical references)

The underlying technology here (cola) essentially replicates the
IDocument model into a receiver process and then as changes are
introduced by either process, the changes are represented by a small set
of model-type-specific primitives (in the case of documents, insertChar,
deleteChar). These primitive operations are serialized and communicated
to the other process asynchronously, and then they are locally
transformed (via cola) in order to resolve any conflicts in real time.
There is a useful generalization of this approach, we believe, for other
model types (i.e. not just documents). For example, say that there was
an extension point that allowed EMF/GMF models of various types to
define their own primitive operations, as well as the
appropriate/necessary transformations of those primitives. Then new
model types with new operations/primitives can/could be communicated via
ECF and transformed appropriately to resolve network-induced
synchronization conflicts.

I would like to see the EMF and ECF communities work together to define
a framework for EMF-based model distribution and synchronization. This
can/would be very useful for e4 work...as it provides a much better
distribution architecture for client server and/or group and/or
peer-to-peer interaction. I expect that Eike and Net4j communities
can/would be able to help with this.

In terms of project organization I would not have any objection to
having Net4j within ECF, but there are some things going on with ECF
that you should know about:

1) ECF is moving from technology to runtime top-level project (soon)
2) We don't have any corporate support currently, so although this gives
us a certain freedom (positive side), it means we don't have very much
in terms of PMC, marketing/promotion, server/hw resources, build
support, etc.

>
> I talked to Nick about this and we decided to let sleeping dogs lie
until the Ganymede preparation efforts are over.
> Note that this transition would be of a purely organizational nature,
although it might have technical influences as well.
> My main precondition to concretely think about this move is that ECF
fully supports Nick's build infrastructure.


We currently have our own build, but it's not something we're married to
:) . That is, we would be happy to use Nick's build infrastructure (and
Nick's expertise), but there's been no organizational way to do that to
this point, so by necessity we've created our own project build (as have
all the other smaller non-EMF projects).

But our build is based upon PDE-build and ant scripts, etc...so I would
not guess there is any incompatibility with what Nick has in place for
the EMF family as I understand it. We are not doing anything
particularly exotic (the closest thing is doing some OS-specific
fragments for Skype).


> I'm not going to maintain two different builds!


Me neither! We would be happy to have the ECF build maintenance be
outside our (my and Ted's) direct responsibility. But of course that
would mean that Nick's build would have to take on/build non-EMF
features/projects. I'm perfectly willing to go there, and technically
don't see any problems with that, but will this work for Nick, EMF PMC,
EF, IBM, etc?


Scott


>
> Cheers
> /Eike
>
>
>
>
> Ed Merks schrieb:
>> Roland,
>>
>> A few times Eike has mentioned having chatted with Scott about
moving Net4j to ECF. I think that would make good sense.
>>
>>
>> Roland Tepp wrote:
>>> Hello,
>>>
>>> I was looking through the EMF related projects and while reading
about CDO, I found myself wandering, why you've created a whole
networking stack of your own, when there is a perfectly valid existing
software stack that would possibly solve the same problems.
>>>
>>> Was this because ECF did not exist way back when you started with
the CDO or are there actually some technical reasons for that.
>>>


Eike Stepper wrote:
> Hi Ed, Roland,
>
> Yes, mostly correct ;-)
>
> To be exact, Scott and I worked together to develop a Net4j based ECF
> provider:
>
> 203406: Develop an ECF provider with Net4j
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=203406
>
> At the recent EclipseCon we agreed that we want to continue this work
> during the summer.
> Btw. there is already an indirect integration between Net4j and ECF via
> the experimental JMS provider implementation on top of Net4j.
>
> So far I did not talk with Scott about a move of Net4j from Modeling to
> ECF!
> Well I cc'ed him so this might be a start ;-)
>
> I talked to Nick about this and we decided to let sleeping dogs lie
> until the Ganymede preparation efforts are over.
> Note that this transition would be of a purely organizational nature,
> although it might have technical influences as well.
> My main precondition to concretely think about this move is that ECF
> fully supports Nick's build infrastructure.
> I'm not going to maintain two different builds!
>
> Cheers
> /Eike
>
>
>
>
> Ed Merks schrieb:
>> Roland,
>>
>> A few times Eike has mentioned having chatted with Scott about moving
>> Net4j to ECF. I think that would make good sense.
>>
>>
>> Roland Tepp wrote:
>>> Hello,
>>>
>>> I was looking through the EMF related projects and while reading
>>> about CDO, I found myself wandering, why you've created a whole
>>> networking stack of your own, when there is a perfectly valid
>>> existing software stack that would possibly solve the same problems.
>>>
>>> Was this because ECF did not exist way back when you started with the
>>> CDO or are there actually some technical reasons for that.
>>>
Re: Net4j - why not ECF? [message #420507 is a reply to message #420504] Tue, 01 July 2008 16:25 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33141
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------040408050400060900020204
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Scott,

Given my new found freedom to work on whatever I choose, all this sounds
very cool and exciting to me!


So Long and Thanks for All the Open Source
< http://ed-merks.blogspot.com/2008/06/so-long-and-thanks-for- all-open-source.html>

But I need to get out from under the deluge of personal issues facing me
for the next few weeks, not to mention finish planting the 10,000
seedlings I grew, before I can do anything concrete to act on this though.


Scott Lewis wrote:
> Hi Eike and EMFers,
>
> Eike Stepper wrote:
> > Hi Ed, Roland,
> >
> > Yes, mostly correct ;-)
> >
> > To be exact, Scott and I worked together to develop a Net4j based
> ECF provider:
> >
> > 203406: Develop an ECF provider with Net4j
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=203406
> >
> > At the recent EclipseCon we agreed that we want to continue this
> work during the summer.
> > Btw. there is already an indirect integration between Net4j and ECF
> via the experimental JMS provider implementation on top of Net4j.
> >
> > So far I did not talk with Scott about a move of Net4j from Modeling
> to ECF!
> > Well I cc'ed him so this might be a start ;-)
>
> I would love to have a Net4j provider that implements one or more ECF
> APIs (likely datashare, possibly remote services and/or shared object
> APIs).
> Further, I would like to attempt to enlist Eike, Net4j, Ed, and the
> wider EMF community cooperatively in work we are beginning to do for
> 'replicated model synchronization'. Just to explain this a little
> bit...we recently have done some work in real-time shared editing
>
> http://wiki.eclipse.org/DocShare_Plugin
> (see bottom for technical references)
>
> The underlying technology here (cola) essentially replicates the
> IDocument model into a receiver process and then as changes are
> introduced by either process, the changes are represented by a small
> set of model-type-specific primitives (in the case of documents,
> insertChar, deleteChar). These primitive operations are serialized
> and communicated to the other process asynchronously, and then they
> are locally transformed (via cola) in order to resolve any conflicts
> in real time.
> There is a useful generalization of this approach, we believe, for
> other model types (i.e. not just documents). For example, say that
> there was an extension point that allowed EMF/GMF models of various
> types to define their own primitive operations, as well as the
> appropriate/necessary transformations of those primitives. Then new
> model types with new operations/primitives can/could be communicated
> via ECF and transformed appropriately to resolve network-induced
> synchronization conflicts.
>
> I would like to see the EMF and ECF communities work together to
> define a framework for EMF-based model distribution and
> synchronization. This can/would be very useful for e4 work...as it
> provides a much better distribution architecture for client server
> and/or group and/or peer-to-peer interaction. I expect that Eike and
> Net4j communities can/would be able to help with this.
>
> In terms of project organization I would not have any objection to
> having Net4j within ECF, but there are some things going on with ECF
> that you should know about:
>
> 1) ECF is moving from technology to runtime top-level project (soon)
> 2) We don't have any corporate support currently, so although this
> gives us a certain freedom (positive side), it means we don't have
> very much in terms of PMC, marketing/promotion, server/hw resources,
> build support, etc.
>
> >
> > I talked to Nick about this and we decided to let sleeping dogs lie
> until the Ganymede preparation efforts are over.
> > Note that this transition would be of a purely organizational
> nature, although it might have technical influences as well.
> > My main precondition to concretely think about this move is that ECF
> fully supports Nick's build infrastructure.
>
>
> We currently have our own build, but it's not something we're married
> to :) . That is, we would be happy to use Nick's build infrastructure
> (and Nick's expertise), but there's been no organizational way to do
> that to this point, so by necessity we've created our own project
> build (as have all the other smaller non-EMF projects).
>
> But our build is based upon PDE-build and ant scripts, etc...so I
> would not guess there is any incompatibility with what Nick has in
> place for the EMF family as I understand it. We are not doing
> anything particularly exotic (the closest thing is doing some
> OS-specific fragments for Skype).
>
>
> > I'm not going to maintain two different builds!
>
>
> Me neither! We would be happy to have the ECF build maintenance be
> outside our (my and Ted's) direct responsibility. But of course that
> would mean that Nick's build would have to take on/build non-EMF
> features/projects. I'm perfectly willing to go there, and technically
> don't see any problems with that, but will this work for Nick, EMF
> PMC, EF, IBM, etc?
>
>
> Scott
>
>
> >
> > Cheers
> > /Eike
> >
> >
> >
> >
> > Ed Merks schrieb:
> >> Roland,
> >>
> >> A few times Eike has mentioned having chatted with Scott about
> moving Net4j to ECF. I think that would make good sense.
> >>
> >>
> >> Roland Tepp wrote:
> >>> Hello,
> >>>
> >>> I was looking through the EMF related projects and while reading
> about CDO, I found myself wandering, why you've created a whole
> networking stack of your own, when there is a perfectly valid existing
> software stack that would possibly solve the same problems.
> >>>
> >>> Was this because ECF did not exist way back when you started with
> the CDO or are there actually some technical reasons for that.
> >>>
>
>
> Eike Stepper wrote:
>> Hi Ed, Roland,
>>
>> Yes, mostly correct ;-)
>>
>> To be exact, Scott and I worked together to develop a Net4j based ECF
>> provider:
>>
>> 203406: Develop an ECF provider with Net4j
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=203406
>>
>> At the recent EclipseCon we agreed that we want to continue this work
>> during the summer.
>> Btw. there is already an indirect integration between Net4j and ECF
>> via the experimental JMS provider implementation on top of Net4j.
>>
>> So far I did not talk with Scott about a move of Net4j from Modeling
>> to ECF!
>> Well I cc'ed him so this might be a start ;-)
>>
>> I talked to Nick about this and we decided to let sleeping dogs lie
>> until the Ganymede preparation efforts are over.
>> Note that this transition would be of a purely organizational nature,
>> although it might have technical influences as well.
>> My main precondition to concretely think about this move is that ECF
>> fully supports Nick's build infrastructure.
>> I'm not going to maintain two different builds!
>>
>> Cheers
>> /Eike
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Roland,
>>>
>>> A few times Eike has mentioned having chatted with Scott about
>>> moving Net4j to ECF. I think that would make good sense.
>>>
>>>
>>> Roland Tepp wrote:
>>>> Hello,
>>>>
>>>> I was looking through the EMF related projects and while reading
>>>> about CDO, I found myself wandering, why you've created a whole
>>>> networking stack of your own, when there is a perfectly valid
>>>> existing software stack that would possibly solve the same problems.
>>>>
>>>> Was this because ECF did not exist way back when you started with
>>>> the CDO or are there actually some technical reasons for that.
>>>>

--------------040408050400060900020204
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Scott,<br>
<br>
Given my new found freedom to work on whatever I choose, all this
sounds very cool and exciting to me!<br>
<blockquote>
<h3 class="post-title entry-title"><small><small><a
href=" http://ed-merks.blogspot.com/2008/06/so-long-and-thanks-for- all-open-source.html">So
Long and Thanks for All the Open Source</a></small></small></h3>
</blockquote>
But I need to get out from under the deluge of personal issues facing
me for the next few weeks, not to mention finish planting the 10,000
seedlings I grew, before I can do anything concrete to act on this
though.<br>
<br>
<br>
Scott Lewis wrote:
<blockquote cite="mid:g4dl1i$mrv$1@build.eclipse.org" type="cite">Hi
Eike and EMFers,
<br>
<br>
Eike Stepper wrote:
<br>
&gt; Hi Ed, Roland,
<br>
&gt;
<br>
&gt; Yes, mostly correct ;-)
<br>
&gt;
<br>
&gt; To be exact, Scott and I worked together to develop a Net4j based
ECF provider:
<br>
&gt;
<br>
&gt; 203406: Develop an ECF provider with Net4j
<br>
&gt; <a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=203406">https://bugs.eclipse.org/bugs/show_bug.cgi?id=203406</a>
<br>
&gt;
<br>
&gt; At the recent EclipseCon we agreed that we want to continue this
work during the summer.
<br>
&gt; Btw. there is already an indirect integration between Net4j and
ECF via the experimental JMS provider implementation on top of Net4j.
<br>
&gt;
<br>
&gt; So far I did not talk with Scott about a move of Net4j from
Modeling to ECF!
<br>
&gt; Well I cc'ed him so this might be a start ;-)
<br>
<br>
I would love to have a Net4j provider that implements one or more ECF
APIs (likely datashare, possibly remote services and/or shared object
APIs).
<br>
Further, I would like to attempt to enlist Eike, Net4j, Ed, and the
wider EMF community cooperatively in work we are beginning to do for
'replicated model synchronization'.  Just to explain this a little
bit...we recently have done some work in real-time shared editing
<br>
<br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/DocShare_Plugin">http://wiki.eclipse.org/DocShare_Plugin</a>
<br>
(see bottom for technical references)
<br>
<br>
The underlying technology here (cola) essentially replicates the
IDocument model into a receiver process and then as changes are
introduced by either process, the changes are represented by a small
set of model-type-specific primitives (in the case of documents,
insertChar, deleteChar).  These primitive operations are serialized and
communicated to the other process asynchronously, and then they are
locally transformed (via cola) in order to resolve any conflicts in
real time.
<br>
There is a useful generalization of this approach, we believe, for
other model types (i.e. not just documents).   For example, say that
there was an extension point that allowed EMF/GMF models of various
types to define their own primitive operations, as well as the
appropriate/necessary transformations of those primitives.   Then new
model types with new operations/primitives can/could be communicated
via ECF and transformed appropriately to resolve network-induced
synchronization conflicts.
<br>
<br>
I would like to see the EMF and ECF communities work together to define
a framework for EMF-based model distribution and synchronization.  This
can/would be very useful for e4 work...as it provides a much better
distribution architecture for client server and/or group and/or
peer-to-peer interaction.  I expect that Eike and Net4j communities
can/would be able to help with this.
<br>
<br>
In terms of project organization I would not have any objection to
having Net4j within ECF, but there are some things going on with ECF
that you should know about:
<br>
<br>
1) ECF is moving from technology to runtime top-level project (soon)
<br>
2) We don't have any corporate support currently, so although this
gives us a certain freedom (positive side), it means we don't have very
much in terms of PMC,  marketing/promotion, server/hw resources, build
support, etc.
<br>
<br>
&gt;
<br>
&gt; I talked to Nick about this and we decided to let sleeping dogs
lie until the Ganymede preparation efforts are over.
<br>
&gt; Note that this transition would be of a purely organizational
nature, although it might have technical influences as well.
<br>
&gt; My main precondition to concretely think about this move is that
ECF fully supports Nick's build infrastructure.
<br>
<br>
<br>
We currently have our own build, but it's not something we're married
to :) .  That is, we would be happy to use Nick's build infrastructure
(and Nick's expertise), but there's been no organizational way to do
that to this point, so by necessity we've created our own project build
(as have all the other smaller non-EMF projects).
<br>
<br>
But our build is based upon PDE-build and ant scripts, etc...so I would
not guess there is any incompatibility with what Nick has in place for
the EMF family as I understand it.  We are not doing anything
particularly exotic (the closest thing is doing some OS-specific
fragments for Skype).
<br>
<br>
<br>
&gt; I'm not going to maintain two different builds!
<br>
<br>
<br>
Me neither!  We would be happy to have the ECF build maintenance be
outside our (my and Ted's) direct responsibility.  But of course that
would mean that Nick's build would have to take on/build non-EMF
features/projects.  I'm perfectly willing to go there, and technically
don't see any problems with that, but will this work for Nick, EMF PMC,
EF, IBM, etc?
<br>
<br>
<br>
Scott
<br>
<br>
<br>
&gt;
<br>
&gt; Cheers
<br>
&gt; /Eike
<br>
&gt;
<br>
&gt;
<br>
&gt;
<br>
&gt;
<br>
&gt; Ed Merks schrieb:
<br>
&gt;&gt; Roland,
<br>
&gt;&gt;
<br>
&gt;&gt; A few times Eike has mentioned having chatted with Scott about
moving Net4j to ECF.   I think that would make good sense.
<br>
&gt;&gt;
<br>
&gt;&gt;
<br>
&gt;&gt; Roland Tepp wrote:
<br>
&gt;&gt;&gt; Hello,
<br>
&gt;&gt;&gt;
<br>
&gt;&gt;&gt; I was looking through the EMF related projects and while
reading about CDO, I found myself wandering, why you've created a whole
networking stack of your own, when there is a perfectly valid existing
software stack that would possibly solve the same problems.
<br>
&gt;&gt;&gt;
<br>
&gt;&gt;&gt; Was this because ECF did not exist way back when you
started with the CDO or are there actually some technical reasons for
that.
<br>
&gt;&gt;&gt;
<br>
<br>
<br>
Eike Stepper wrote:
<br>
<blockquote type="cite">Hi Ed, Roland,
<br>
<br>
Yes, mostly correct ;-)
<br>
<br>
To be exact, Scott and I worked together to develop a Net4j based ECF
provider:
<br>
<br>
203406: Develop an ECF provider with Net4j
<br>
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=203406">https://bugs.eclipse.org/bugs/show_bug.cgi?id=203406</a>
<br>
<br>
At the recent EclipseCon we agreed that we want to continue this work
during the summer.
<br>
Btw. there is already an indirect integration between Net4j and ECF via
the experimental JMS provider implementation on top of Net4j.
<br>
<br>
So far I did not talk with Scott about a move of Net4j from Modeling to
ECF!
<br>
Well I cc'ed him so this might be a start ;-)
<br>
<br>
I talked to Nick about this and we decided to let sleeping dogs lie
until the Ganymede preparation efforts are over.
<br>
Note that this transition would be of a purely organizational nature,
although it might have technical influences as well.
<br>
My main precondition to concretely think about this move is that ECF
fully supports Nick's build infrastructure.
<br>
I'm not going to maintain two different builds!
<br>
<br>
Cheers
<br>
/Eike
<br>
<br>
<br>
<br>
<br>
Ed Merks schrieb:
<br>
<blockquote type="cite">Roland,
<br>
<br>
A few times Eike has mentioned having chatted with Scott about moving
Net4j to ECF.   I think that would make good sense.
<br>
<br>
<br>
Roland Tepp wrote:
<br>
<blockquote type="cite">Hello,
<br>
<br>
I was looking through the EMF related projects and while reading about
CDO, I found myself wandering, why you've created a whole networking
stack of your own, when there is a perfectly valid existing software
stack that would possibly solve the same problems.
<br>
<br>
Was this because ECF did not exist way back when you started with the
CDO or are there actually some technical reasons for that.
<br>
<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>

--------------040408050400060900020204--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Net4j - why not ECF? [message #420510 is a reply to message #420504] Tue, 01 July 2008 16:29 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Hi Scott,

Comments below...


Scott Lewis schrieb:
> Hi Eike and EMFers,
>
> Eike Stepper wrote:
> > Hi Ed, Roland,
> >
> > Yes, mostly correct ;-)
> >
> > To be exact, Scott and I worked together to develop a Net4j based
> ECF provider:
> >
> > 203406: Develop an ECF provider with Net4j
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=203406
> >
> > At the recent EclipseCon we agreed that we want to continue this
> work during the summer.
> > Btw. there is already an indirect integration between Net4j and ECF
> via the experimental JMS provider implementation on top of Net4j.
> >
> > So far I did not talk with Scott about a move of Net4j from Modeling
> to ECF!
> > Well I cc'ed him so this might be a start ;-)
>
> I would love to have a Net4j provider that implements one or more ECF
> APIs (likely datashare, possibly remote services and/or shared object
> APIs).
Let me work on some outstanding work items related with the loved
documentation and then we can continue on our initial prototype.

> Further, I would like to attempt to enlist Eike, Net4j, Ed, and the
> wider EMF community cooperatively in work we are beginning to do for
> 'replicated model synchronization'. Just to explain this a little
> bit...we recently have done some work in real-time shared editing
>
> http://wiki.eclipse.org/DocShare_Plugin
> (see bottom for technical references)
>
> The underlying technology here (cola) essentially replicates the
> IDocument model into a receiver process and then as changes are
> introduced by either process, the changes are represented by a small
> set of model-type-specific primitives (in the case of documents,
> insertChar, deleteChar). These primitive operations are serialized
> and communicated to the other process asynchronously, and then they
> are locally transformed (via cola) in order to resolve any conflicts
> in real time.
> There is a useful generalization of this approach, we believe, for
> other model types (i.e. not just documents). For example, say that
> there was an extension point that allowed EMF/GMF models of various
> types to define their own primitive operations, as well as the
> appropriate/necessary transformations of those primitives. Then new
> model types with new operations/primitives can/could be communicated
> via ECF and transformed appropriately to resolve network-induced
> synchronization conflicts.
>
> I would like to see the EMF and ECF communities work together to
> define a framework for EMF-based model distribution and
> synchronization. This can/would be very useful for e4 work...as it
> provides a much better distribution architecture for client server
> and/or group and/or peer-to-peer interaction. I expect that Eike and
> Net4j communities can/would be able to help with this.
Did you know that CDO (currently implemented on top of Net4j) already
offers a complete solution and an extensible framework for model
repositories and distributed shared models? If you want to I can give
you a short Yugma presentation (see yugma.com) to demonstrate usage and
design. Please contact me privately so that I can give you my skype id.
Apologies for not having ECF installed at the moment ;-)

> In terms of project organization I would not have any objection to
> having Net4j within ECF, but there are some things going on with ECF
> that you should know about:
>
> 1) ECF is moving from technology to runtime top-level project (soon)
> 2) We don't have any corporate support currently, so although this
> gives us a certain freedom (positive side), it means we don't have
> very much in terms of PMC, marketing/promotion, server/hw resources,
> build support, etc.
>
> >
> > I talked to Nick about this and we decided to let sleeping dogs lie
> until the Ganymede preparation efforts are over.
> > Note that this transition would be of a purely organizational
> nature, although it might have technical influences as well.
> > My main precondition to concretely think about this move is that ECF
> fully supports Nick's build infrastructure.
>
>
> We currently have our own build, but it's not something we're married
> to :) . That is, we would be happy to use Nick's build infrastructure
> (and Nick's expertise), but there's been no organizational way to do
> that to this point, so by necessity we've created our own project
> build (as have all the other smaller non-EMF projects).
>
> But our build is based upon PDE-build and ant scripts, etc...so I
> would not guess there is any incompatibility with what Nick has in
> place for the EMF family as I understand it. We are not doing
> anything particularly exotic (the closest thing is doing some
> OS-specific fragments for Skype).
>
>
> > I'm not going to maintain two different builds!
>
>
> Me neither! We would be happy to have the ECF build maintenance be
> outside our (my and Ted's) direct responsibility. But of course that
> would mean that Nick's build would have to take on/build non-EMF
> features/projects. I'm perfectly willing to go there, and technically
> don't see any problems with that, but will this work for Nick, EMF
> PMC, EF, IBM, etc?
As I understood Nick respective discussions have already taken place.
Maybe I misunderstood him in the noise of Ganymede ;-)
I cc'ed Nick but I also think that we should start concrete discussion
somewehere else.
What about a Net4j Bugzilla?!

Cheers
/Eike



>
>
> Scott
>
>
> >
> > Cheers
> > /Eike
> >
> >
> >
> >
> > Ed Merks schrieb:
> >> Roland,
> >>
> >> A few times Eike has mentioned having chatted with Scott about
> moving Net4j to ECF. I think that would make good sense.
> >>
> >>
> >> Roland Tepp wrote:
> >>> Hello,
> >>>
> >>> I was looking through the EMF related projects and while reading
> about CDO, I found myself wandering, why you've created a whole
> networking stack of your own, when there is a perfectly valid existing
> software stack that would possibly solve the same problems.
> >>>
> >>> Was this because ECF did not exist way back when you started with
> the CDO or are there actually some technical reasons for that.
> >>>
>
>
> Eike Stepper wrote:
>> Hi Ed, Roland,
>>
>> Yes, mostly correct ;-)
>>
>> To be exact, Scott and I worked together to develop a Net4j based ECF
>> provider:
>>
>> 203406: Develop an ECF provider with Net4j
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=203406
>>
>> At the recent EclipseCon we agreed that we want to continue this work
>> during the summer.
>> Btw. there is already an indirect integration between Net4j and ECF
>> via the experimental JMS provider implementation on top of Net4j.
>>
>> So far I did not talk with Scott about a move of Net4j from Modeling
>> to ECF!
>> Well I cc'ed him so this might be a start ;-)
>>
>> I talked to Nick about this and we decided to let sleeping dogs lie
>> until the Ganymede preparation efforts are over.
>> Note that this transition would be of a purely organizational nature,
>> although it might have technical influences as well.
>> My main precondition to concretely think about this move is that ECF
>> fully supports Nick's build infrastructure.
>> I'm not going to maintain two different builds!
>>
>> Cheers
>> /Eike
>>
>>
>>
>>
>> Ed Merks schrieb:
>>> Roland,
>>>
>>> A few times Eike has mentioned having chatted with Scott about
>>> moving Net4j to ECF. I think that would make good sense.
>>>
>>>
>>> Roland Tepp wrote:
>>>> Hello,
>>>>
>>>> I was looking through the EMF related projects and while reading
>>>> about CDO, I found myself wandering, why you've created a whole
>>>> networking stack of your own, when there is a perfectly valid
>>>> existing software stack that would possibly solve the same problems.
>>>>
>>>> Was this because ECF did not exist way back when you started with
>>>> the CDO or are there actually some technical reasons for that.
>>>>


Re: Net4j - why not ECF? [message #420514 is a reply to message #420507] Tue, 01 July 2008 17:50 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Hi Ed,

Ed Merks wrote:
> Scott,
>
> Given my new found freedom to work on whatever I choose, all this sounds
> very cool and exciting to me!
>
>
> So Long and Thanks for All the Open Source
> < http://ed-merks.blogspot.com/2008/06/so-long-and-thanks-for- all-open-source.html>


I saw...congratulations Ed. Some of us are very happy that you have
such freedom :).


>
> But I need to get out from under the deluge of personal issues facing me
> for the next few weeks, not to mention finish planting the 10,000
> seedlings I grew, before I can do anything concrete to act on this though.


Understood. I'm taking some time off in July myself, so don't assume
that lack of immediate response means lack of immediate interest :)

Thanks,

Scott
Re: Net4j - why not ECF? [message #420516 is a reply to message #420510] Tue, 01 July 2008 18:09 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Eike Stepper wrote:
<stuff deleted>
>> I would love to have a Net4j provider that implements one or more ECF
>> APIs (likely datashare, possibly remote services and/or shared object
>> APIs).
> Let me work on some outstanding work items related with the loved
> documentation and then we can continue on our initial prototype.


Yes. The source for that is available at http://ecf1.osuosl.org


>
<stuff deleted>

>> and/or group and/or peer-to-peer interaction. I expect that Eike and
>> Net4j communities can/would be able to help with this.
> Did you know that CDO (currently implemented on top of Net4j) already
> offers a complete solution and an extensible framework for model
> repositories and distributed shared models? If you want to I can give
> you a short Yugma presentation (see yugma.com) to demonstrate usage and
> design. Please contact me privately so that I can give you my skype id.


Sure...I will get in contact with you directly via skype.

I've looked at the CDO documentation briefly and will look at it
further. Don't take this as a criticism...but it seems to me focussed
on the many-clients-accessing-a-single-model-on-server architecture. In
my view this is completely fine, and applicable in many situations.
With the real-time shared editing, we have started down the road of
having peer-based replication, and actual model replicas (or partial
replicas) being present and updated on 2 or more processes...which
implies/requires some differences in approaches for
timely-but-still-synchronized update (e.g. the cola work).

So I guess what I'm saying is that I can see CDO and our
replication/op-transform-based synchronization approach as being
complimentary...which is a good thing.


> Apologies for not having ECF installed at the moment ;-)


Well, I expect you to remedy that soon...right? :). Just open
Communications group in Ganymede update site.

Scott
Re: Net4j - why not ECF? [message #420530 is a reply to message #420516] Wed, 02 July 2008 07:32 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Scott Lewis schrieb:

<stuff deleted>
>> Did you know that CDO (currently implemented on top of Net4j) already
>> offers a complete solution and an extensible framework for model
>> repositories and distributed shared models? If you want to I can give
>> you a short Yugma presentation (see yugma.com) to demonstrate usage
>> and design. Please contact me privately so that I can give you my
>> skype id.
>
>
> Sure...I will get in contact with you directly via skype.
Got you.


> I've looked at the CDO documentation briefly and will look at it
> further. Don't take this as a criticism...but it seems to me focussed
> on the many-clients-accessing-a-single-model-on-server architecture.
> In my view this is completely fine, and applicable in many situations.
Some may see it as an advantage while some may not. We've had rare but
recurring requests for better support of replication so we plan to look
at this during the current 2.0 development stream, too. I'm not
particularly sure that this will depart us fundamentally from the
client/server based approach, but hey, if you're digging deep enough
you'll always end up with two sockets, one being a client and the other
being a server ;-)


> With the real-time shared editing, we have started down the road of
> having peer-based replication, and actual model replicas (or partial
> replicas) being present and updated on 2 or more processes...which
> implies/requires some differences in approaches for
> timely-but-still-synchronized update (e.g. the cola work).
I watched the cola demo recently and I'm deeply impressed! Would you say
that it's already usable, especially from a characteristics point of view?
I'm *very* curious to see if your design will be able to accomodate
model(ing) needs as appropriately as it seems for IDocuments. Did you
know that CDO has many powerful features to cope with huge models, like
demand loading/unloading of single instances, partial collection
loading, intelligent prefetching, and, and, and... ?


> So I guess what I'm saying is that I can see CDO and our
> replication/op-transform-based synchronization approach as being
> complimentary...which is a good thing.
So do I. And yes, diversity rules ;-)


> Apologies for not having ECF installed at the moment ;-)
>
> Well, I expect you to remedy that soon...right? :). Just open
> Communications group in Ganymede update site.
Done ;-)

Cheers
/Eike


Re: Net4j - why not ECF? [message #420591 is a reply to message #420530] Thu, 03 July 2008 03:32 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Hi Eike,

>Eike Stepper wrote:
> Scott Lewis schrieb:
>
<stuff deleted>
>> timely-but-still-synchronized update (e.g. the cola work).
> I watched the cola demo recently and I'm deeply impressed! Would you say
> that it's already usable, especially from a characteristics point of view?


Yes, I would say it was very usable. Not quite sure what you mean 'from
a characteristics' point of view...we do have some generalizations and
API design things to persue...e.g.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=239048
https://bugs.eclipse.org/bugs/show_bug.cgi?id=234142

And we have some pure usability things to do also (not API related):

https://bugs.eclipse.org/bugs/show_bug.cgi?id=238785

But it is complete and working as expected right now. So far, we have
not been able to find a situation where it fails and the replicas become
inconsistent...but if we do I'm quite sure it will be an implementation
bug rather than an algorithm bug.

> I'm *very* curious to see if your design will be able to accomodate
> model(ing) needs as appropriately as it seems for IDocuments.

The key insight here is the approach of operational
transformations...generalized to non text-only operations (and
transformations). To start, see:

http://wiki.eclipse.org/RT_Shared_Editing

Did you
> know that CDO has many powerful features to cope with huge models, like
> demand loading/unloading of single instances, partial collection
> loading, intelligent prefetching, and, and, and... ?


These sound good/fine. Nice to know.


>
>
>> So I guess what I'm saying is that I can see CDO and our
>> replication/op-transform-based synchronization approach as being
>> complimentary...which is a good thing.
> So do I. And yes, diversity rules ;-)
>
>
>> Apologies for not having ECF installed at the moment ;-)
>>
>> Well, I expect you to remedy that soon...right? :). Just open
>> Communications group in Ganymede update site.
> Done ;-)


Great! Thanks.

Scott
Re: Net4j - why not ECF? [message #420593 is a reply to message #420591] Thu, 03 July 2008 05:11 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Scott Lewis schrieb:
> [...]
> Yes, I would say it was very usable. Not quite sure what you mean
> 'from a characteristics' point of view...
I read some comments on a blog complaining about performance/latency
issues. But I guess this was related to very particular network setups.


> we do have some generalizations and API design things to persue...e.g.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=239048
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=234142
>
> And we have some pure usability things to do also (not API related):
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=238785
>
> But it is complete and working as expected right now. So far, we have
> not been able to find a situation where it fails and the replicas
> become inconsistent...but if we do I'm quite sure it will be an
> implementation bug rather than an algorithm bug.
Do you know at what time it will be available via P2?


> I'm *very* curious to see if your design will be able to accomodate
> model(ing) needs as appropriately as it seems for IDocuments.
> The key insight here is the approach of operational
> transformations...generalized to non text-only operations (and
> transformations). To start, see:
>
> http://wiki.eclipse.org/RT_Shared_Editing
There seems to be even more substance about it than I thought in first
instance!

Cheers
/Eike


Re: Net4j - why not ECF? [message #420607 is a reply to message #420593] Thu, 03 July 2008 15:57 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Eike,

Eike Stepper wrote:
> Scott Lewis schrieb:
>> [...]
>> Yes, I would say it was very usable. Not quite sure what you mean
>> 'from a characteristics' point of view...
> I read some comments on a blog complaining about performance/latency
> issues. But I guess this was related to very particular network setups.


Yes. One thing we can't do is make up for a very slow network. But no
matter how slow the network, the algorithm should work and keep things
in sync. And given the asynchronous nature of ECF, local input/changes
are still responsive.


>
>
>> we do have some generalizations and API design things to persue...e.g.
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=239048
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=234142
>>
>> And we have some pure usability things to do also (not API related):
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=238785
>>
>> But it is complete and working as expected right now. So far, we have
>> not been able to find a situation where it fails and the replicas
>> become inconsistent...but if we do I'm quite sure it will be an
>> implementation bug rather than an algorithm bug.
> Do you know at what time it will be available via P2?


Not sure what you mean. The docshare plugin currently has the cola
algorithm and the docshare plugin is included as part of ECF
2.0.0/Ganymede...which is available via P2 (?).


>
>
>> I'm *very* curious to see if your design will be able to accomodate
>> model(ing) needs as appropriately as it seems for IDocuments.
>> The key insight here is the approach of operational
>> transformations...generalized to non text-only operations (and
>> transformations). To start, see:
>>
>> http://wiki.eclipse.org/RT_Shared_Editing
> There seems to be even more substance about it than I thought in first
> instance!


Yes, there is a great deal of substance.

Scott
Re: Net4j - why not ECF? [message #420615 is a reply to message #420491] Fri, 04 July 2008 07:35 Go to previous messageGo to next message
Roland Tepp is currently offline Roland TeppFriend
Messages: 336
Registered: July 2009
Senior Member
Hello Eike,

I've been looking at the ECF for a while with an interest and a hope
that one of these days I come upon a project where I can start using
this platform. Until now though, I am working on a project that has
invested a whole lot of time and money into another kind of approaches
and I have hard time convincing my project leads to switching to EMF/CDO...

Eike Stepper kirjutas mulle midagi seesugust:

>> Was this because ECF did not exist way back when you started with the CDO
> Yes, that was the main reason.
> Sufficient in its own ;-)
>
Quite true :)

>> or are there actually some technical reasons for that.
> Might be the case as well. More interesting we have a 2.0 plan item to
> decouple the CDO network layer from Net4j, making Net4j one of possibly
> several alternatives. I've attached the diagrams to illustrate the idea.
>
> A pure ECF implementation of this layer would also be a cool idea and
> should be easily feasible with the appropriate knowledge about ECF.
> Would you like to contribute such an ECF based CDOProtocolFacade?
>
I would love to, but as I currently have only a superficial
understanding of EMF, and next to no knowledge of CDO or ECF beyond
their promise of better world, peace for all and hope of salvation
through their technology, I am not sure I can be of much help. :)

Not to mention that I am currently not free to give promises of any
serious contribution commitment... :(

--
Roland Tepp
Re: Net4j - why not ECF? [message #420618 is a reply to message #420615] Fri, 04 July 2008 08:08 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Roland Tepp schrieb:
> Hello Eike,
>
> I've been looking at the ECF for a while with an interest and a hope
> that one of these days I come upon a project where I can start using
> this platform. Until now though, I am working on a project that has
> invested a whole lot of time and money into another kind of approaches
> and I have hard time convincing my project leads to switching to
> EMF/CDO...
Hopefully not for technical reasons and hopefully with success ;-)


>
> Eike Stepper kirjutas mulle midagi seesugust:
Hehe, I'm curious: What language is that?


>
>>> Was this because ECF did not exist way back when you started with
>>> the CDO
>> Yes, that was the main reason.
>> Sufficient in its own ;-)
>>
> Quite true :)
>
>>> or are there actually some technical reasons for that.
>> Might be the case as well. More interesting we have a 2.0 plan item
>> to decouple the CDO network layer from Net4j, making Net4j one of
>> possibly several alternatives. I've attached the diagrams to
>> illustrate the idea.
>>
>> A pure ECF implementation of this layer would also be a cool idea and
>> should be easily feasible with the appropriate knowledge about ECF.
>> Would you like to contribute such an ECF based CDOProtocolFacade?
>>
> I would love to, but as I currently have only a superficial
> understanding of EMF, and next to no knowledge of CDO or ECF beyond
> their promise of better world, peace for all and hope of salvation
> through their technology, I am not sure I can be of much help. :)
>
> Not to mention that I am currently not free to give promises of any
> serious contribution commitment... :(
Don't worry. Ideas are also contributions. Though they're generally not
as likely to get part of the distro soon as are patches ;-)

Cheers
/Eike


Previous Topic:[CDO]java.lang.ClassCastException
Next Topic:CDO - My generated package does not show up
Goto Forum:
  


Current Time: Fri Apr 26 02:26:25 GMT 2024

Powered by FUDForum. Page generated in 0.03311 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top