Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 2934B200BB3 for ; Wed, 19 Oct 2016 03:37:48 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 2794F160AF7; Wed, 19 Oct 2016 01:37:48 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id EA9F2160AE5 for ; Wed, 19 Oct 2016 03:37:46 +0200 (CEST) Received: (qmail 19249 invoked by uid 500); 19 Oct 2016 01:37:46 -0000 Mailing-List: contact log4j-user-help@logging.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Log4J Users List" Reply-To: "Log4J Users List" Delivered-To: mailing list log4j-user@logging.apache.org Received: (qmail 19238 invoked by uid 99); 19 Oct 2016 01:37:45 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Oct 2016 01:37:45 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 643AC1A0865 for ; Wed, 19 Oct 2016 01:37:45 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.879 X-Spam-Level: ** X-Spam-Status: No, score=2.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_REPLY=1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=msn.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 8QsItaY7o6y9 for ; Wed, 19 Oct 2016 01:37:38 +0000 (UTC) Received: from SNT004-OMC3S17.hotmail.com (snt004-omc3s17.hotmail.com [65.55.90.156]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 38E475F257 for ; Wed, 19 Oct 2016 01:37:37 +0000 (UTC) Received: from NAM03-BY2-obe.outbound.protection.outlook.com ([65.55.90.137]) by SNT004-OMC3S17.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 18 Oct 2016 18:36:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=msn.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ufo4T3bDggYeJCLrHL5m8Wq9Q+/VftyN0rezl7ywO/A=; b=DVV5q2u7BimW8HrTpGwCPjI1NNdQjZ7E7KzMtuAB5UGYHld8035s2iEmTH9TNzAXulqtUIHazZDUzQ5mnLonBv+/GOw9GABZrUtIfpwEwcA9Z5wHqpRKsGvKqNjOKu9HQGwq4MS5/c5hlX39cGlgnbVuiIHc9VhdZSuIhCU9DAiqL+jBIsWRFOLkVJxIi8hscHORkT620l9qy9XUZ/uVqVDxyBigik4oKykehWZ2LJb7X087m7lJ2QvlfyjwXUUW/3F2kUlUQ+aLkJQX+C5bMqVPVlltbznkCw08kHVALRL2RTEgMZL6K4bxoagHNiFgyvD7n9ONRgO1v8JwL0innw== Received: from CO1NAM03FT046.eop-NAM03.prod.protection.outlook.com (10.152.80.56) by CO1NAM03HT132.eop-NAM03.prod.protection.outlook.com (10.152.81.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.7; Wed, 19 Oct 2016 01:36:44 +0000 Received: from BLUPR10MB0833.namprd10.prod.outlook.com (10.152.80.59) by CO1NAM03FT046.mail.protection.outlook.com (10.152.81.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.7 via Frontend Transport; Wed, 19 Oct 2016 01:36:44 +0000 Received: from BLUPR10MB0833.namprd10.prod.outlook.com ([10.163.216.11]) by BLUPR10MB0833.namprd10.prod.outlook.com ([10.163.216.11]) with mapi id 15.01.0659.025; Wed, 19 Oct 2016 01:36:43 +0000 From: Nicholas Duane To: Log4J Users List Subject: Re: porting log4j2 to .NET Thread-Topic: porting log4j2 to .NET Thread-Index: AQHSKM5PdGBmcAi+J0aO4tkELpnZlKCtxscAgAB0lYGAAAQzAIAAAm/BgAAGvgCAAAB/EYAABtAAgAACIYCAABO8gIAADlYPgAA1uwCAAAaMRIAAN6EAgAAXiks= Date: Wed, 19 Oct 2016 01:36:43 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: logging.apache.org; dkim=none (message not signed) header.d=none;logging.apache.org; dmarc=none action=none header.from=msn.com; x-incomingtopheadermarker: OriginalChecksum:05544358082403623F16C38275C9093A0FAEAB138089A7DD120CB792D175B8FB;UpperCasedChecksum:E7819C619AFEF3FB54190D8FF4812347C368E244DD4F499F490B199B44CFC2A8;SizeAsReceived:8231;Count:38 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [w6MZMqM3BWFFKY5iyHxj8poZu7gWntCA] x-incomingheadercount: 38 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1;CO1NAM03HT132;6:dIuzCzsT/GSgMc+sRqpoixVMVsNS/uM72by5uLhhQlcnxytoG+Xql2+pl23qTgNVXmjD6tYgWRVaVuyaR4oS1zD0oCqNrl6GCg+JnfAXF/kykUR1elcx/n5RH4CA048+aNAG5u4r7tNVs0YspXp5jcoHho7TM/uU09xEtncuo6GAA7nW4iGUBZQITeC1XlwMvxcJ9RQ1+mvHuIfI65/BCQ/m7IqLrquPEv6o2JLGxTCRMVotPWAJS70dGMlxkizvmzmSZ/QduLw2xQalKwYiq6/Lzrfq9AP0FCv2g4vadHAtEfXvx5GPgtW0HrKN3FOy;5:cYPqCxCRFA3FBP1QBGesEUJjiyRTLkOytx2VZES19D4s6zwiDuK5m6IDqsLhDViR6+xKKTOebZcA+1s+if1E8SVjF+7pcpUE5Pl4iQ2vWZBzP/a90WuTbzpf4wL1WfzLRt0TgiQ2XlOc653spvVym9lCvwMtIxqxKq8eWTXjQ+g=;24:4m2IXyml6gU+gfuM8KrPJmRm/3kY8lIG3Zl8yQ1t50U8C6tewTx0/xYojuzM0Y1U7rgj0ypbO9BXVAmUwQLd2pOWewtyJBMkK+RCoJrlpds=;7:oZLwtxInF/rz7pv2BaaiOQ5/12+BuVBO3EJPe/grVKnsj6aYNwK2Q5Slt5v/UmPbz5Ge31fThBCsBLkfyfHVKotpGAwM2fOyq4AiDCtpSAbuA3+/5lYopSsshwUPo4Thr/ComFkxGNtYKOjk+h+jKFyd26H6TJG/285SLMuA8NiXseSwFiNvCyVmiK1/2muiUtD1Wc2M1p0vKLGYJBDABE9KSaTnicJCxFU+qUIha5y/s6S1dO8Q091j/jNt2X4j43wT4gugdmnnAtt9Cmv4Kc8EXzcn42W78bav/1gB7hUntRCwPm0DVAr1jlLGSpjhcXY/HmijecZ5VwuC862jFBDw9XvpAeFcBDKmUk5acio= x-forefront-antispam-report: EFV:NLI;SFV:NSPM;SFS:(10019020)(98900003);DIR:OUT;SFP:1102;SCL:1;SRVR:CO1NAM03HT132;H:BLUPR10MB0833.namprd10.prod.outlook.com;FPR:;SPF:None;LANG:en; x-ms-office365-filtering-correlation-id: 64462bc9-ac11-4ae1-0cee-08d3f7c061c2 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(1601124038)(1603103081)(1601125047)(1603101322);SRVR:CO1NAM03HT132; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(432015012)(82015046);SRVR:CO1NAM03HT132;BCL:0;PCL:0;RULEID:;SRVR:CO1NAM03HT132; x-forefront-prvs: 0100732B76 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR10MB0833E7752183E38B127A7D4BDBD20BLUPR10MB0833namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2016 01:36:43.3418 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM03HT132 X-OriginalArrivalTime: 19 Oct 2016 01:36:48.0383 (UTC) FILETIME=[423028F0:01D229A9] archived-at: Wed, 19 Oct 2016 01:37:48 -0000 --_000_BLUPR10MB0833E7752183E38B127A7D4BDBD20BLUPR10MB0833namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable But I'm not suggesting a code base that will run everywhere. As I said, I'= m not talking about a single source code base. What I'm suggesting is a si= ngle design/architecture which is then implemented across a set of runtimes= /OS's. As opposed to what seems to be the case now where log4j is its own = team with it's own design and log4net, I guess, was originally a port of lo= g4j but might be moving in its own direction. I suggested the same to the log4net team. And while it could be the case t= hat I could help with the log4net effort, I would not be interested in it g= oing off in its own direction as I see a big benefit in having similar logg= ing frameworks across Java and .NET. Thanks, Nick ________________________________ From: Ralph Goers Sent: Tuesday, October 18, 2016 8:08 PM To: Log4J Users List Subject: Re: porting log4j2 to .NET I feel lost because I don=92t understand the concept of a code base that wi= ll run everywhere in any language. The run everywhere part is called =93Jav= a=94. The run in any language part doesn=92t exist as far as I know, let al= one when combined with =93run everywhere=94. So I don=92t know where that p= art of the discussion is coming from. It would be possible to create implementations of the Log4j design in multi= ple languages, but we would need many more committers with skills in those = various languages to do it. To be sure, I would love to see that happen, b= ut it isn=92t possible with the set of committers who actively contribute t= o the logging project today. If you are volunteering to kick that off we wo= n=92t get in your way. Ralph > On Oct 18, 2016, at 1:53 PM, Nicholas Duane wrote: > > Doesn't sound like you're too lost. Yes, plug-ins certainly is an area w= here the implementation will cause variations, in the config for instance. = And with respect to asynchronous appenders, that might even be a feature m= issing in some implementations if support for it would be too difficult. > > > By the way, thanks to everyone for putting up with my questions as I try = to work though the issues I have with our implementation. > > > Thanks, > > Nick > > ________________________________ > From: Ralph Goers > > Sent: Tuesday, October 18, 2016 4:25 PM > To: Log4J Users List > Subject: Re: porting log4j2 to .NET > > I=92ve gotten completely lost in this conversation. > > The design certainly doesn=92t need to know about the language, but certa= in design features have to be implementable. > > For example, to use the same configuration each implementation would have= to support the plugin concept. The Java implementation relies upon annotat= ions to do this. .NET has something similar but other languages may not. A= synchronous Loggers take advantage of a highly optimized concurrent queue. = Although you might be able to create something equivalent in other languag= es it might not scale as well. Then again, some languages don=92t support m= ulti-threading so either might require all loggers to be synchronous. > > Ralph > >> On Oct 18, 2016, at 10:22 AM, Nicholas Duane wrote: >> >> I guess I don't agree. And just to be clear, I'm not talking about tryi= ng to have a huge percentage, or any at all really, of single source and th= en glue code around it for the various runtimes/OS's you're targeting. >> >> >> I'm not that familiar with log4j2 but I would assume you have: >> >> >> * a core engine with accepts events and then runs them through some chec= ks before throwing them out or sending them along their way. >> >> >> * seems the major abstraction is the appender. >> >> >> * some other abstractions like filters and layouts. >> >> >> * configuration >> >> >> * an object model such that most, if not all, can be configured programm= atically >> >> >> I'm sure there's some stuff I'm missing. Still not sure why most of the= design for this has to know what runtime/language it's targeting. >> >> >> Thanks, >> >> Nick >> >> ________________________________ >> From: Matt Sicker >> >> Sent: Tuesday, October 18, 2016 12:22 PM >> To: Log4J Users List >> Subject: Re: porting log4j2 to .NET >> >> Really, the only portable-ish way to make a common framework would be to >> write them in C or Rust or something and make glue code for every runtim= e >> out there. JVM users tend to prefer Java-native libraries over >> JNI/JNA/whatever type libraries, and I'm sure that's not uncommon in som= e >> other runtimes. >> >> On 18 October 2016 at 10:11, Mikael St=E5ldal > >> wrote: >> >>> In my opinion, one of the major benefits of Log4j is its comprehensive >>> ecosystem of plugins (appenders, layouts, etc), both bundled and 3rd pa= rty. >>> This will automatically benefit all users of Log4j, regardless of langu= age >>> (on the JVM) and OS (that you can run the JVM on). But this does not ex= tend >>> to other runtimes (e.g. .Net). >>> >>> Another benefit is that your application and 3rd party frameworks/libra= ries >>> you use can log via the same framework and you can collect the logs >>> together. This does not extend to other runtimes either, since you won'= t >>> use the same libraries. >>> >>> On Tue, Oct 18, 2016 at 5:03 PM, Matt Sicker > wrote: >>> >>>> I'm saying the architecture of the code depends on the language you're >>>> using. Different design patterns apply to different languages, for >>>> instance. A logging framework in Java and C# might be very similar, bu= t >>>> they'd look quite different from one written entirely in Clojure or F#= . >>> The >>>> general concept of appenders, loggers, filters, etc., would all probab= ly >>>> apply, but the APIs would probably differ a lot. This would affect plu= gin >>>> authors more than users of the library, but the only common things I >>> could >>>> see happening between different languages might be a similar API in a >>>> Logger class or module. >>>> >>>> On 18 October 2016 at 09:45, Nicholas Duane > wrote: >>>> >>>>> I just mentioned the config as one piece where I think it would be ve= ry >>>>> useful to have similar, if not exactly the same, configs across >>>>> implementations. I also realize that it might not be possible. >>>>> >>>>> >>>>> So are you saying that when you get to designing a logging framework >>> you >>>>> first have to know what language/runtime you're designing it for? I >>>> would >>>>> think not. Hopefully most, if not all, can be designed OS/runtime >>>> agnostic >>>>> and without having to design to a lowest common denominator. >>>>> >>>>> >>>>> Also not sure about the OOP thing. As far as I can tell, OOP is just= a >>>>> convenience thing, syntactic sugar. I believe you can do the same in= a >>>>> procedural language. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Nick >>>>> >>>>> ________________________________ >>>>> From: Matt Sicker > >>>>> Sent: Tuesday, October 18, 2016 10:37 AM >>>>> To: Log4J Users List >>>>> Subject: Re: porting log4j2 to .NET >>>>> >>>>> Every programming language has its own idioms, and that even goes for >>> all >>>>> the various JVM languages as demonstrated by the log4j-scala API. >>> Unless >>>>> you mean more of an architectural thing with a similar config format, >>>> then >>>>> that might be more possible, but even that relies on a language being >>>>> mostly OOP or mostly procedural or mostly functional or some other >>> exotic >>>>> thing. >>>>> >>>>> On 18 October 2016 at 09:23, Nicholas Duane > wrote: >>>>> >>>>>> I agree. I'm also one for not coding to the lowest common >>> denominator. >>>>>> That's one reason we're not using a logging facade as I assume with = a >>>>>> facade you get only the features that are common across the set of >>>>> logging >>>>>> frameworks the facade supports. >>>>>> >>>>>> >>>>>> What I'm suggesting is to come up with a design and architecture >>> which >>>> is >>>>>> language/runtime/OS agnostic. While it's easy for me to say that I >>>>>> wouldn't be surprised if it's more difficult to achieve. When it >>> comes >>>>> to >>>>>> implementation I would assume the features might manifest themselves >>> in >>>>>> different ways across the different languages/runtimes/OS's. For >>>>> instance, >>>>>> .NET has extension methods and Java doesn't. You might decide to >>>>> implement >>>>>> some features in .NET using extension methods and in Java you'll hav= e >>>> to >>>>>> pick a different way to implement. Configuration might be another >>> area >>>>>> where there are differences among the different runtimes and thus th= e >>>>>> implementation might be a bit different. Maybe there's even a >>> feature >>>>> that >>>>>> one implementation has that others don't just because there is no >>> way, >>>> or >>>>>> no easy enough way to implement. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Nick >>>>>> >>>>>> ________________________________ >>>>>> From: Mikael St=E5ldal > >>>>>> Sent: Tuesday, October 18, 2016 10:04 AM >>>>>> To: Log4J Users List >>>>>> Subject: Re: porting log4j2 to .NET >>>>>> >>>>>> Maybe I am nitpicking, but Log4j is also (mostly) agnostic to what >>>>> language >>>>>> you run on the JVM (Java, Scala, Groovy, Clojure, etc). >>>>>> >>>>>> I guess it would be nice to have similar logging framework for other >>>>>> runtimes (such as .Net). However, I would not like to constrain Log4= j >>>> to >>>>>> only use features available on both JVM and .Net. >>>>>> >>>>>> On Tue, Oct 18, 2016 at 3:53 PM, Nicholas Duane > >>>> wrote: >>>>>> >>>>>>> I guess platform is vague. Maybe I should have said language >>>> agnostic. >>>>>>> It would be nice to have a single logging architecture/design run >>> on >>>>>> C/C++, >>>>>>> .NET, Java, etc. Or at least it seems like a nice feature to me. >>> I >>>>>> would >>>>>>> assume there are many enterprises out there that have applications >>>>>> running >>>>>>> on different OS's and languages. If I'm trying to pick a logging >>>>>> framework >>>>>>> to use and I find a popular one which is capable and runs similarly >>>>>> across >>>>>>> the OS's and languages then that's a big plus in my mind. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Nick >>>>>>> >>>>>>> ________________________________ >>>>>>> From: Mikael St=E5ldal > >>>>>>> Sent: Tuesday, October 18, 2016 2:52 AM >>>>>>> To: Log4J Users List >>>>>>> Subject: Re: porting log4j2 to .NET >>>>>>> >>>>>>> Just to make things clear, Log4j is a logging framework for the JVM >>>>>>> platform, and it is agnostic to the underlying OS. It it well >>> tested >>>> on >>>>>> (at >>>>>>> least) both Linux and Windows. >>>>>>> >>>>>>> On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane > >>>>> wrote: >>>>>>> >>>>>>>> Figured I would send this question out to the log4j side. I have >>>>>> already >>>>>>>> had some email exchanges with the log4net mailing list regarding >>>>>> porting >>>>>>>> log4j2 to .NET. My suggestion was that the apache logging >>>> framework >>>>>> be a >>>>>>>> single architecture design which is platform agnostic and then >>>> teams >>>>>>> which >>>>>>>> port to the different platforms. It seems log4net was a port of >>>>> log4j >>>>>>> and >>>>>>>> may be going off in its own direction from that initial port. My >>>>>>> viewpoint >>>>>>>> is that's a bad idea as one of the benefits I saw was that >>> log4net >>>>> was >>>>>>>> similar to log4j2 and we're looking for logging frameworks for >>> our >>>>>>>> enterprise. We have applications on both Windows/.NET and >>>> Linux/Java >>>>>> so >>>>>>>> having a logging framework for Windows/.NET which is similar to a >>>>>> logging >>>>>>>> framework for Linux/Java was a big plus. >>>>>>>> >>>>>>>> >>>>>>>> While I have no doubt the effort to port log4j2 to .NET is >>>>>> considerable, >>>>>>>> it would be a port and thus I'm not spending time figuring out >>>> design >>>>>> and >>>>>>>> algorithms. Would anyone want to venture a guess at what that >>>> effort >>>>>>> might >>>>>>>> be? >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Nick >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> [image: MagineTV] >>>>>>> >>>>>>> *Mikael St=E5ldal* >>>>>>> Senior software developer >>>>>>> >>>>>>> *Magine TV* >>>>>>> mikael.staldal@magine.com >>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com > >> [https://de.magine.com/content/uploads/2016/09/magine_global_social.png]= > >> >> TV online with Magine TV= >> >> www.magine.com > > >> Watch the TV you love, on any device, anywhere in Germany and Sweden and= find out more about our global OTT B2B solutions. Get started today. >> >> >>> <<< >>>>> http://www.magine.com<<> > >> >>>>>> http://www.magine.com<> > >> >>>>>>> http://www.magine.com >> >>>>>>> [https://de.magine.com/content/uploads/2016/09/ > >>>>> magine_global_social.png >>>>>> ]< >>>>>>> http://www.magine.com/ > >>>>>>> >>>>>>> TV online with Magine TV> >>>>>>> www.magine.com > >>>>>>> Watch the TV you love, on any device, anywhere in Germany and >>> Sweden >>>>> and >>>>>>> find out more about our global OTT B2B solutions. Get started >>> today. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Privileged and/or Confidential Information may be contained in this >>>>>>> message. If you are not the addressee indicated in this message >>>>>>> (or responsible for delivery of the message to such a person), you >>>> may >>>>>> not >>>>>>> copy or deliver this message to anyone. In such case, >>>>>>> you should destroy this message and kindly notify the sender by >>> reply >>>>>>> email. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> [image: MagineTV] >>>>>> >>>>>> *Mikael St=E5ldal* >>>>>> Senior software developer >>>>>> >>>>>> *Magine TV* >>>>>> mikael.staldal@magine.com >>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com << > >>>>> http://www.magine.com<> > >>>>>> http://www.magine.com >> >>>>>> >>>>>> Privileged and/or Confidential Information may be contained in this >>>>>> message. If you are not the addressee indicated in this message >>>>>> (or responsible for delivery of the message to such a person), you >>> may >>>>> not >>>>>> copy or deliver this message to anyone. In such case, >>>>>> you should destroy this message and kindly notify the sender by repl= y >>>>>> email. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matt Sicker >>>>> >>>> >>>> >>>> >>>> -- >>>> Matt Sicker > >>>> >>> >>> >>> >>> -- >>> [image: MagineTV] >>> >>> *Mikael St=E5ldal* >>> Senior software developer >>> >>> *Magine TV* >>> mikael.staldal@magine.com >>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com > > >> >>> >>> Privileged and/or Confidential Information may be contained in this >>> message. If you are not the addressee indicated in this message >>> (or responsible for delivery of the message to such a person), you may = not >>> copy or deliver this message to anyone. In such case, >>> you should destroy this message and kindly notify the sender by reply >>> email. >>> >> >> >> >> -- >> Matt Sicker > --_000_BLUPR10MB0833E7752183E38B127A7D4BDBD20BLUPR10MB0833namp_--