#jython IRC Log (v0.9)

Index

IRC Log for 2010-06-01

Timestamps are in GMT/BST.

[0:11] * pigletto (~pigletto@dynamic-78-8-98-236.ssp.dialog.net.pl) Quit (Remote host closed the connection)
[1:29] * mannaz (~mannaz@chello084113205242.2.14.vie.surfer.at) Quit (Ping timeout: 265 seconds)
[1:46] * lucian_ is now known as lucian
[1:59] * ttmrichter (~ttmrichte@221.234.132.38) has joined #jython
[2:18] * agronholm_ (agronholm@nblzone-211-17.nblnetworks.fi) has joined #jython
[2:21] * agronholm (agronholm@nblzone-211-17.nblnetworks.fi) Quit (Ping timeout: 265 seconds)
[2:26] * agronholm_ (agronholm@nblzone-211-17.nblnetworks.fi) Quit (Read error: Connection reset by peer)
[2:26] * agronholm_ (demigod@xdsl-413aed8979966cfd61d6.v6.nebulazone.fi) has joined #jython
[2:31] * ttmrichter (~ttmrichte@221.234.132.38) Quit (Ping timeout: 272 seconds)
[2:35] * ttmrichter (~ttmrichte@59.173.203.49) has joined #jython
[2:40] * ohumbel (~5390f2dc@gateway/web/freenode/x-gzjpvfqnfgbvjimj) Quit (Ping timeout: 252 seconds)
[2:48] * lopex (lopex@chello089076044027.chello.pl) Quit ()
[2:50] * lucian (~lucian@cpc3-benw9-2-0-cust344.gate.cable.virginmedia.com) Quit (Quit: Leaving...)
[3:30] * jareth (~jareth@74-133-71-235.dhcp.insightbb.com) has joined #jython
[3:35] * jareth (~jareth@74-133-71-235.dhcp.insightbb.com) Quit ()
[7:13] * juneau001 (~juneau@pool-72-69-205-224.chi01.dsl-w.verizon.net) Quit (Quit: juneau001)
[7:16] * pigletto (~quassel@188.33.1.162) has joined #jython
[7:21] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) Quit (Ping timeout: 265 seconds)
[8:15] <Oti> pjenvey: i think i have a fix for #1567 and #1594, and it also enables test_subprocess on windows (see #1356)
[8:16] <Oti> but i have no idea how enable test_subprocess.py in regrtest (http://www.acm.uiuc.edu/jython-buildbot/builders/asm-winxp-x86-java1.6/builds/1186/steps/regrtest/logs/skipped)
[8:18] <Oti> could you give me a hint, please ? (i'll read the logs)
[8:51] * Oti (~ohumbel@adsl-84-227-188-134.adslplus.ch) Quit (Quit: Oti)
[8:51] * stakkars (~tismer@82.113.104.242) Quit (Ping timeout: 245 seconds)

[09:23] == ohumbel [~5390f2dc@gateway/web/freenode/x-yfilsiuizqfzrhbw] has joined #jython
[09:23] == Oti [~5390f2dc@gateway/web/freenode/x-gzrwthwlatklrnrj] has quit [Ping timeout: 252 seconds]
[09:28] == Oti [~5390f2dc@gateway/web/freenode/x-shwvfrnuzwqzuedy] has joined #jython
[09:35] == thobe [~Adium@212-162-171-110.skbbip.com] has quit [Quit: Leaving.]
[09:45] == thobe [~Adium@212-162-171-110.skbbip.com] has joined #jython
[11:02] == hipertracker [~hipertrac@89.167.220.4] has joined #jython
[11:25] == mannaz [~mannaz@78.142.150.242] has joined #jython
[11:38] == thobe [~Adium@212-162-171-110.skbbip.com] has quit [Quit: Leaving.]
[11:49] == thobe [~Adium@212-162-171-110.skbbip.com] has joined #jython
[12:43] == juneau001 [~juneau@131.225.24.190] has joined #jython
[13:00] <agronholm_> does someone know what's been done in jython to support bzip2?
[13:00] <agronholm_> or what's been planned
[13:11] <agronholm_> hm, the trac issue sheds some light into this
[13:18] == verterok [~ggonzalez@unaffiliated/verterok] has joined #jython
[13:31] == mannaz [~mannaz@78.142.150.242] has quit [Quit: mannaz]
[13:34] == mannaz [~mannaz@78.142.150.242] has joined #jython
[14:18] == lheuer [~heuer@unaffiliated/lheuer] has joined #jython
[14:33] == lolsuper_ [~super_@unaffiliated/lolsuper-/x-9881387] has joined #jython
[14:43] == pigletto [~quassel@188.33.1.162] has quit [Remote host closed the connection]
[15:45] == mannaz [~mannaz@78.142.150.242] has quit [Quit: mannaz]
[15:45] == mannaz [~mannaz@78.142.150.242] has joined #jython
[15:55] == skay [~skay@pat1.orbitz.net] has joined #jython
[16:52] == skay [~skay@pat1.orbitz.net] has quit [Quit: skay]
[16:56] == mannaz [~mannaz@78.142.150.242] has quit [Quit: mannaz]
[17:00] == lheuer_ [~heuer@dyndsl-091-096-052-210.ewe-ip-backbone.de] has joined #jython
[17:00] == lheuer [~heuer@unaffiliated/lheuer] has quit [Ping timeout: 252 seconds]
[17:01] == lheuer_ has changed nick to lheuer
[17:03] == enebo [~enebo@97-127-0-32.mpls.qwest.net] has joined #jython
[17:17] == lheuer [~heuer@dyndsl-091-096-052-210.ewe-ip-backbone.de] has quit [Quit: Closing Time]
[17:39] == lopex [lopex@chello089076044027.chello.pl] has joined #jython
[17:52] == Oti [~5390f2dc@gateway/web/freenode/x-shwvfrnuzwqzuedy] has quit [Ping timeout: 252 seconds]
[17:54] == ttmrichter [~ttmrichte@59.173.203.49] has quit [Ping timeout: 260 seconds]
[17:57] == Oti [~5390f2dc@gateway/web/freenode/x-zaqtmttyfzbmjvwe] has joined #jython
[18:22] <pjenvey> Oti - I have test_subprocess require the 'subprocess' resource because it's such a slow test
[18:22] == dany2_ [~dan@2001:470:1f06:309:21f:5bff:fef5:c3fb] has joined #jython
[18:23] == dany2 [~dan@2001:470:1f06:309:21f:5bff:fef5:c3fb] has quit [Read error: No route to host]
[18:23] <pjenvey> we could either temporarily enable it everywhere by removing the test_requires() call in test_subprocess, or we could reconfigure one, two or all of the buildbots to run with that requirement
[18:23] == dany2_ has changed nick to dany2
[18:23] <pjenvey> the former option sounds easiest for now
[18:24] <pjenvey> agronholm_ - yea the latest patch I pasted is somewhat far along (minus the streaming decompressor bit), it just needs some attention
[18:25] <Oti> pjenvey: thanks - i'll try!
[18:25] <agronholm_> pjenvey, I thought the bzip2 package supported incremental reads
[18:26] <agronholm_> I mean, it has a method for reading a certain amount of data from a certain offset
[18:26] <agronholm_> hm
[18:29] <agronholm_> oh ic
[18:29] <agronholm_> the one at www.kohsuke.org/bzip2/ doesn't have this feature
[18:29] <agronholm_> but the one in ant's svn does
[18:30] <agronholm_> pjenvey, did you know that?
[18:31] <agronholm_> the newer version looks totally different
[18:31] <agronholm_> right, the new one is licensed with apache 2.0 license, the old one with 1.1
[18:31] <agronholm_> is that a problem?
[18:35] <pjenvey> agronholm_ - no version I've seen supports the streaming BZ2Decompressor needs
[18:36] <agronholm_> what does it need then?
[18:36] <pjenvey> my patch originally used the kohsuke version but now it's using the apache commons compress bz2 lib
[18:36] <pjenvey> which is based on the other ones anyway
[18:38] <pjenvey> well it needs incremental reads I guess, where are you seeing that it can do that
[18:38] <pjenvey> more specifically it needs to be able to decompress a small chunk of compressed bz2 data without blowing up
[18:39] <agronholm_> public int read(final byte[] dest, final int offs, final int len) <- not sure this does what you want
[18:39] <agronholm_> offs is offset in the byte array
[18:39] <agronholm_> len is the number of bytes to read from the input stream
[18:39] <pjenvey> a chunk that isn't an entire valid bz2 compressed file
[18:41] <agronholm_> the implementation here isn't very fast
[18:42] <agronholm_> commons-compress bzip2 has this same method
[18:42] <agronholm_> probably the same code anyway
[18:42] == lucian [~lucian@cpc3-benw9-2-0-cust344.gate.cable.virginmedia.com] has joined #jython
[18:43] <pjenvey> they all blow up when you give them a small chunk
[18:43] <pjenvey> they're made to have the entire bz2'd file on hand
[18:44] <agronholm_> what exactly happens
[18:44] <pjenvey> they throw an exception, something like "bz2 footer not found at EOF" or something along those lines
[18:44] <pjenvey> i'll brb
[18:45] <agronholm_> InputStream does not support seeking
[18:45] <agronholm_> so
[18:45] <agronholm_> how exactly do they get to EOF
[18:47] == Oti [~5390f2dc@gateway/web/freenode/x-zaqtmttyfzbmjvwe] has quit [Quit: Page closed]
[18:47] == headius [~headius@216.160.3.79] has joined #jython
[18:48] == hipertracker [~hipertrac@89.167.220.4] has quit [Quit: hipertracker]
[18:51] <agronholm_> meh, I guess we'll have to get to java coding
[19:00] * pr3d4t0r hugs pjenvey.
[19:00] * pr3d4t0r smiles at agronholm_.
[19:01] == sgithens [~sgithens@2001:18e8:3:443:223:aeff:fe01:c4d] has joined #jython
[19:01] <pr3d4t0r> I'm doing a revamped version of Mule punching/Python next week in Dublin :)
[19:02] <agronholm_> pr3d4t0r, I've decided to build a python appserver
[19:02] <agronholm_> one that supports several protocols at once, not limited to web apps
[19:03] <agronholm_> it'll support clustering and hot redeployments with no service disruptions
[19:05] <agronholm_> bbl, feel free to comment while I'm away
[19:07] <pr3d4t0r> agronholm_: That sounds like a great idea.
[19:07] <pr3d4t0r> agronholm_: Let's talk later if you want to discuss. That's exactly what Mule is, but in Java planet.
[19:08] <pr3d4t0r> agronholm_: A combination app server and ESB.
[19:14] == JythonLogBot [~PircBot@adsl-178-38-158-18.adslplus.ch] has joined #jython
[19:14] == Oti [~ohumbel@adsl-178-38-158-18.adslplus.ch] has joined #jython
[19:34] * Oti (~ohumbel@adsl-178-38-158-18.adslplus.ch) has joined #jython
[19:38] <pjenvey> agronholm_ - anyway I don't mind including a bz2 module with limited BZ2Decompressor functionality for now
[19:38] <pjenvey> most use cases are with the one shot API calls
[19:39] <pjenvey> mercurial might use it though
[19:43] * enebo (~enebo@97-127-0-32.mpls.qwest.net) Quit (Quit: enebo)
[20:09] <agronholm_> pr3d4t0r, back
[20:09] <pr3d4t0r> agronholm_: :)
[20:09] <pr3d4t0r> agronholm_: Check out Mule.
[20:09] <agronholm_> I have
[20:09] <pr3d4t0r> agronholm_: What do you think?
[20:10] <agronholm_> well, it seems to be pretty close to what I had in mind
[20:14] <agronholm_> what license does mule offer
[20:19] <pr3d4t0r> agronholm_: It's on a Mozilla-like license. The company makes money from subscriptions and non-open licenses.
[20:19] <pr3d4t0r> agronholm_: The community edition is open source, stable, somewhat buggy, but free.
[20:19] <pr3d4t0r> agronholm_: The enterprise edition is open source + proprietary extensions, more stable, has bug fixes not available in the CE, and it's attached to whatever support contract you have.
[20:20] <agronholm_> this is what I had in mind
[20:21] <agronholm_> you develop an application around controller classes
[20:21] <agronholm_> controllers can be exposed as endpoints from the application
[20:22] <pr3d4t0r> agronholm_: OKi.
[20:22] <agronholm_> when you deploy your application, you decide where to mount those endpoints
[20:22] <agronholm_> (which addresses/ports to bind to, and in case of http, which root url to bind them under)
[20:23] * enebo (~enebo@207.148.207.230) has joined #jython
[20:23] <pr3d4t0r> agronholm_: Both Mule and ServiceMix work like that.
[20:23] <agronholm_> ok great
[20:23] <pr3d4t0r> agronholm_: Rather than a controller, though, they're structured around POJOs. The POJO standardized model doesn't translate well into Python common practices, though.
[20:24] <agronholm_> how so
[20:24] <pr3d4t0r> agronholm_: The infrastructure component (Mule, ServiceMix) is the controller and traffic cop.
[20:24] <agronholm_> perhaps you misunderstood the term controller
[20:24] * thobe (~Adium@212-162-171-110.skbbip.com) Quit (Quit: Leaving.)
[20:24] <pr3d4t0r> agronholm_: The business logic and so on is implemented in POJOs - that's where the value is for the users. They don't have to screw with protocols/controllers/etc.
[20:24] <pr3d4t0r> agronholm_: Ah, perhaps.
[20:25] <agronholm_> in that case, the POJOs are the controllers
[20:25] <agronholm_> controllers are the parts that contain the business logic
[20:25] <pr3d4t0r> agronholm_: OKi...
[20:25] <agronholm_> I meant controller as in MVC
[20:25] <pr3d4t0r> agronholm_: There's terminology for describing these things in place already, by the way.
[20:25] <agronholm_> MVC is pretty established I think :)
[20:25] <pr3d4t0r> agronholm_: Did you have a chance to check out Enterprise Integration Patterns?
[20:26] <agronholm_> briefly I think
[20:26] <agronholm_> if you have an url, I can take another look
[20:26] <pr3d4t0r> agronholm_: There are whole SOA/EIA terms defined for describing systems like this.
[20:26] <pr3d4t0r> agronholm_: "Controller" might be confusing.
[20:26] <pr3d4t0r> agronholm_: Use "component" instead.
[20:26] <pr3d4t0r> agronholm_: But then, I'm biased. I've been working on this for 3.5 years :)
[20:27] <pr3d4t0r> agronholm_: As far as POJOs, Java has something really cool that I haven't seen in Python (yet): Spring.
[20:28] <agronholm_> I've always look at spring as an extra layer of bloat
[20:28] <agronholm_> *looked
[20:28] <pr3d4t0r> agronholm_: As far as I know, there is no standard, de facto or institutional, for defining POJO-like entities in Python.
[20:28] <pr3d4t0r> agronholm_: Well... yes and no. Spring lets you wire applications together with little or no coding if you already have the components.
[20:29] <agronholm_> pr3d4t0r, wire together, in what way
[20:29] <pr3d4t0r> agronholm_: Or to write minimal components and then use whatever is lying around to complete the app.
[20:29] <pr3d4t0r> agronholm_: You can put together a Spring application without coding a single line of Java code.
[20:29] <pr3d4t0r> agronholm_: (Assuming that the components already exist.)
[20:29] <pr3d4t0r> agronholm_: That's why everyone gets hardons about Spring.
[20:30] <agronholm_> could you give me a practical example?
[20:31] <pr3d4t0r> agronholm_: A Mule configuration file is a great example. Stand by.
[20:31] <agronholm_> besides, don't you then have to write those annoying deployment descriptors anyway?
[20:32] <pr3d4t0r> agronholm_: Yeah, but those are trivial to write if you already have a complex, working component that you want to reuse.
[20:32] <pr3d4t0r> agronholm_: http://eugeneciurana.com/musings/dynamic_mule_updates/mule-punch-config.xml.html
[20:32] <pr3d4t0r> agronholm_: A Mule file is really just a Spring file.
[20:32] <pr3d4t0r> agronholm_: Over there I'm using Java and Python components, of which I only wrote a single one of them.
[20:32] * enebo (~enebo@207.148.207.230) Quit (Ping timeout: 272 seconds)
[20:33] <agronholm_> I was planning to make an UI for configuring deployments
[20:33] * _hlouis (~chatzilla@capsdevhg01.usc.edu) has joined #jython
[20:33] <agronholm_> and you'd have an option for exporting or importing deployment information
[20:33] <pr3d4t0r> agronholm_: The Sample endpoint declaration on line 14 brings out a complete, fully configured, HTTP/HTTPS server and servlet container. All you do is include "http:" and its name space.
[20:34] <agronholm_> I see little point in that, over a couple lines of python
[20:34] <pr3d4t0r> agronholm_: That'd be grand.
[20:34] <pr3d4t0r> agronholm_: You're assuming that people who'll use this *want* to use Python.
[20:34] <agronholm_> or java
[20:34] <pr3d4t0r> agronholm_: The targets for this are the deployment IT guys.
[20:35] <pr3d4t0r> agronholm_: Python is "live" code.
[20:35] <pr3d4t0r> agronholm_: XML isn't.
[20:35] <pr3d4t0r> agronholm_: YAML isn't.
[20:35] <pr3d4t0r> agronholm_: JSON *could* be, but you may sneak that one past them.
[20:35] <agronholm_> the application just has to expose its endpoints
[20:35] <pr3d4t0r> agronholm_: Right.
[20:35] <pr3d4t0r> agronholm_: But someone has to configure those.
[20:35] <agronholm_> then the admin decides where to mount them
[20:36] <agronholm_> no xml/yaml/whatever is necessary, expect maybe behind the scenes
[20:36] <pr3d4t0r> agronholm_: Yup. That's how a Mule config or a ServiceMix config works.
[20:36] <pr3d4t0r> agronholm_: Yup.
[20:36] <pr3d4t0r> agronholm_: The "behind the scenes" part is where it gets tricky.
[20:36] <agronholm_> how so?
[20:36] <pr3d4t0r> agronholm_: Governance is an issue.
[20:36] <agronholm_> how so?
[20:37] <pr3d4t0r> agronholm_: That's why Python config vs. YAML/XML/etc. isn't always a good idea. Python code is "live".
[20:37] <pr3d4t0r> agronholm_: XML isn't.
[20:37] <agronholm_> you are not making any sense
[20:37] <agronholm_> what python config?
[20:37] <pr3d4t0r> agronholm_: You said that you wanted to configure these things with a GUI. That GUI is driving something, probably Python.
[20:38] <agronholm_> driving, in what way?
[20:38] <pr3d4t0r> agronholm_: You spoke of a controller that you will configure directly.
[20:38] <agronholm_> programmers decide what endpoints are exposed
[20:38] <agronholm_> server admins decide which endpoints are mounted and where
[20:39] <agronholm_> they don't need to see a single line of python or whatever
[20:39] <pr3d4t0r> agronholm_: OKi.
[20:39] <pr3d4t0r> agronholm_: The way Mule/ServiceMix works, the programmers don't even bother with the endpoints.
[20:39] * enebo (~enebo@207.148.207.230) has joined #jython
[20:39] <agronholm_> umm
[20:39] <pr3d4t0r> agronholm_: If I wanted to expose that component in the example I showed you a second ago over some other protocol, let's say raw tcp:, all I'd do is:
[20:39] <agronholm_> don't they at least have to declare which pojos can be used as endpoints?
[20:40] <pr3d4t0r> <tcp:endpoint name='rawSocket' address='tcp://localhost:9090/some_random_name' />
[20:40] <pr3d4t0r> agronholm_: No.
[20:40] <agronholm_> well, suppose a pojo wants to use a database
[20:41] <agronholm_> how does that happen?
[20:41] <pr3d4t0r> agronholm_: That's the point. You DO NOT want the programmers doing that because that compromises reusability. You *can* write components that are tied to a protocol/transport/whatever, but that's a BAD idea.
[20:41] <agronholm_> if the method that is called throws an exception, you probably want to roll back any running transactions
[20:41] <pr3d4t0r> agronholm_: There are two ways of doing the database thing.
[20:41] <pr3d4t0r> agronholm_: You can inject the database using Spring.
[20:42] <pr3d4t0r> agronholm_: Essentially, you define the database as a component, the data source, authentication, etc.
[20:42] <pr3d4t0r> agronholm_: And define a reference to it.
[20:42] <pr3d4t0r> agronholm_: When you define the component that uses it, then you specify the database as a configuration parameter:
[20:43] <pr3d4t0r> agronholm_: <spring:bean property='database' ref='whateverMySQL' otherProperty='true' />
[20:43] <pr3d4t0r> agronholm_: That's one way, for a component that takes the database from a factory or during construction.
[20:44] <agronholm_> yep, resource injection...I know that from EJB
[20:44] <pr3d4t0r> agronholm_: The other way (preferred for enterprise integration) is to define your component as a service provider that takes some input (e.g. Object) and returns some output (e.g. Object).
[20:45] <pr3d4t0r> agronholm_: If you want to perform database operations, then you define your component, and routers that "wire" the data flow from your component, over to the database component (which runs the query or update, give you a result set), then back to your component, then back to the caller.
[20:45] <pr3d4t0r> agronholm_: If you need to change the sequencing, then you just change the routing, the filtering, the transformations, or add/remove components.
[20:46] <pr3d4t0r> agronholm_: The point is that you want to insulate your coders 100% from having to deal with database details, or protocol handling, etc. The guys writing business logic should be writing business logic, not parsing HTTP codes or POST URL decoding, or whatever.
[20:47] <pr3d4t0r> agronholm_: In the database example, the business logic programmers would never see a database result set.
[20:47] <agronholm_> well, we don't have to bother with that even now
[20:47] <pr3d4t0r> agronholm_: Instead, they would get either a dictionary, or a list, or something appropriate and implementation neutral.
[20:47] * thobe (~Adium@c83-249-235-76.bredband.comhem.se) has joined #jython
[20:47] <pr3d4t0r> agronholm_: I hear you.
[20:48] <agronholm_> but the fact is, controllers written for a web app are hardly usable for SOAP or any other form of RPC
[20:48] <pr3d4t0r> agronholm_: I think what I'm saying is that, in order to make this palatable (and I'd love to see a Python-based integration platform) it'd have to be better than Mule and ServiceMix and provide a credible challenge.
[20:48] <pr3d4t0r> agronholm_: I beg to disagree.
[20:49] <pr3d4t0r> agronholm_: We have rolled out very complicated applications that used the same components for both SOAP, REST, web, and JMS.
[20:49] <pr3d4t0r> agronholm_: Same component.
[20:49] <agronholm_> component = class, right?
[20:49] <pr3d4t0r> agronholm_: Let me find a diagram that I presented at a conference recently.
[20:49] <pr3d4t0r> agronholm_: No.
[20:49] <pr3d4t0r> agronholm_: Component == object.
[20:49] <agronholm_> ok, an instance of a class then
[20:49] <agronholm_> my point is
[20:49] <pr3d4t0r> agronholm_: It's a concrete implementation. It's instantiated and live.
[20:50] <pr3d4t0r> agronholm_: Hold on.
[20:50] <agronholm_> that a method that outputs data for a web page usually gives very different output from a method that returns a result for an RPC call
[20:52] <pr3d4t0r> agronholm_: Yup.
[20:52] <pr3d4t0r> agronholm_: But the business logic shouldn't have to change.
[20:52] <pr3d4t0r> agronholm_: http://rifers.org/paste/content/paste/836/image
[20:52] <pr3d4t0r> agronholm_: Wait, that won't work.
[20:52] <agronholm_> Raw pastebin content can't be downloaded directly
[20:52] <pr3d4t0r> agronholm_: http://rifers.org/paste/show/836 - there you go, then click on the image.
[20:53] <agronholm_> ok but this does not explain how template rendering etc. is done
[20:53] <pr3d4t0r> agronholm_: If you need template rendering, you do it on the output transformer.
[20:53] <pr3d4t0r> agronholm_: Payload2HTTP transformer.
[20:53] <agronholm_> but you need a transformer for every such method
[20:53] <pr3d4t0r> agronholm_: Maybe.
[20:53] <agronholm_> isn't that a PITA to configure in XML?
[20:54] <pr3d4t0r> agronholm_: "Yes" for purposes of this discussion.
[20:54] <pr3d4t0r> agronholm_: It's sort of a pain, but the alternative is more painful.
[20:54] <agronholm_> well if I had to do it, I'd implement it as a decorator
[20:54] <pr3d4t0r> agronholm_: The alternative is that someone modifies the application code for every little change.
[20:54] <pr3d4t0r> agronholm_: Sure.
[20:54] <pr3d4t0r> agronholm_: But keep them *separate*.
[20:54] <agronholm_> separate from what?
[20:54] <pr3d4t0r> agronholm_: From the business logic.
[20:55] <agronholm_> isn't decorator separate enough?
[20:55] <pr3d4t0r> agronholm_: The components SHOULD NOT KNOW about protocol, presentation, database, etc.
[20:55] <pr3d4t0r> agronholm_: It could be, yes.
[20:55] <pr3d4t0r> agronholm_: How would I use the decorator, though, if I'm not a Python programmer?
[20:56] <pr3d4t0r> agronholm_: Expose the ability to call decorators from a configuration file, and you'll have real gold in your hands.
[20:56] <agronholm_> outputs from different methods are rarely interchangeable with different templates
[20:56] <agronholm_> do you even know what a decorator is?
[20:57] <pr3d4t0r> agronholm_: We have lots of those, fully interchangeable, in Java planet.
[20:57] <pr3d4t0r> agronholm_: And when in doubt, we write a custom component, yes. If the payload is XML, we use XSLT. No coding.
[20:58] <agronholm_> I have never encountered a practical use for XSLT
[20:59] <agronholm_> transformers might be a good idea, but I can't imagine a web app where controller output was decoupled from the template
[20:59] <pr3d4t0r> agronholm_: We run into those all the time.
[20:59] <agronholm_> ok
[20:59] <pr3d4t0r> agronholm_: Here is a very common thing we solve:
[20:59] <agronholm_> but you didn't answer my question yet
[21:00] <pr3d4t0r> agronholm_: Old system service consumers (e.g. authentication) use some old XML/DTD format for data exchange.
[21:00] <pr3d4t0r> agronholm_: New system uses different XML/XSD format for data exchange authentication.
[21:01] <pr3d4t0r> agronholm_: Making your 6,000 service consumers scattered across 3 continents change their code to adopt the new system on a given date is impractical, and you may not even be able to do it because of governance/contractual obligation/etc.
[21:02] <pr3d4t0r> agronholm_: So, you put Mule or ServiceMix in front of this to handle all the conversation, add a couple of transformers to the inbound and outbound endpoints, and to the responders, and you're done. Time to develop: 24 hours.
[21:02] <pr3d4t0r> agronholm_: Time to regression test: 24 hours.
[21:02] <pr3d4t0r> agronholm_: Production roll out: 72 hours.
[21:02] <agronholm_> I see
[21:02] <pr3d4t0r> agronholm_: Systems affected: zero.
[21:02] <agronholm_> too bad I've never been involved in government/mnc operations :(
[21:02] <pr3d4t0r> agronholm_: Heh - this is all commercial.
[21:03] <agronholm_> which is why I added mnc
[21:03] <pr3d4t0r> agronholm_: None of this was for government. This was all for e-commerce, actually.
[21:03] <agronholm_> (multinational corporations)
[21:03] <pr3d4t0r> agronholm_: Ah.
[21:03] <pr3d4t0r> agronholm_: This was across multiple corps, not a single one with multiple subsidiaries.
[21:03] <pr3d4t0r> agronholm_: In another case, everyone was in the US. Some of the legacy apps were in our own servers.
[21:03] <pr3d4t0r> agronholm_: But we couldn't touch them for whatever reason.
[21:04] <agronholm_> so...other corporations use your servers for authentication?
[21:04] <pr3d4t0r> agronholm_: Yup.
[21:04] <agronholm_> mmkay...
[21:04] <pr3d4t0r> agronholm_: http://www.leapfrog.com - go to the interactive forums (I don't recall the link).
[21:04] <pr3d4t0r> agronholm_: The forums are hosted by a third-party, but they authenticate against our system.s
[21:04] <pr3d4t0r> Er, systems.
[21:04] <agronholm_> well, those transformers are a nice idea considering all that
[21:05] <pr3d4t0r> agronholm_: The case that I showed you in the diagram is a little bit different.
[21:05] <pr3d4t0r> agronholm_: It's a "web service" implemented as a form because the fucking retards who implemented it in the first place didn't understand what that was.
[21:06] <pr3d4t0r> agronholm_: So we had to "parse" a form POST or GET. There were multiple services developed by different entities at different times, all using different variables and stuff. Some were XML, some were forms.
[21:06] <pr3d4t0r> agronholm_: So what we did was normalize the internal format to something we liked and that was independent of the protocols.
[21:07] <pr3d4t0r> agronholm_: (green boxes).
[21:07] <pr3d4t0r> agronholm_: We did the magic (in this case, hit SQL Server and some IIS C# SOAP shit), then packaged the response in another neutral format; I think it was a Java dictionary (hash map).
[21:08] <pr3d4t0r> agronholm_: Then, based on whoever made the call, we would transform that into whatever screwed up piece of shit retarded "format" they had.
[21:09] <pr3d4t0r> agronholm_: So in this case the clients were doing transactional stuff and thinking they were talking to IIS/C#/.Net services. In reality they were talking now to a Java-based, enterprisey, normalized Mule server that started to remove all the bad code dependencies on protocol, format, business logic, etc.
[21:10] <pr3d4t0r> agronholm_: The "claims system module" or "claims system component" was reused. As you can see, there were guys from China calling. When the guys from Mexico called, using their own entirely different protocol, all we had to worry about were the transformers for the request and response. Everything else wasn't touched at all.
[21:10] <agronholm_> ok
[21:11] <agronholm_> so, we've established that transformers are a Great Idea
[21:11] <agronholm_> how exactly are they configured?
[21:11] <pr3d4t0r> agronholm_: Heh.
[21:11] <agronholm_> in the xml, of course
[21:11] <pr3d4t0r> agronholm_: Something like this (I'd have to look at the docs and I'm about to go to a meeting):
[21:12] <agronholm_> but do they have different configuration constructs, or do you think it could be done as a key-value pair dictionary?
[21:12] <agronholm_> ie. how feasible is the idea of building a GUI to configure them
[21:12] <pr3d4t0r> agronholm_: <xsl:transformer ref='Bullshit2NiceData' file='~/mystuff/b2nd.xsl' />
[21:12] <agronholm_> ok but what about non-xml data?
[21:12] <pr3d4t0r> agronholm_: They could be done as key-value pair dictionaries, and the GUI idea is very, very feasible.
[21:13] * juneau001 (~juneau@131.225.24.190) Quit (Quit: Take care...)
[21:13] <pr3d4t0r> agronholm_: Non-XML:
[21:14] <pr3d4t0r> agronholm_: <custom-transformer ref='MyTransformer' class='python.whatever.MyTransformer' returns='java.lang.String' />
[21:14] <pr3d4t0r> agronholm_: You can configure the transformer too, if it has that ability.
[21:15] <pr3d4t0r> agronholm_: In this case (super simple) we're saying something like "I have a custom transformer, written in Python and running in Jython, that returns a standard Java string."
[21:15] <pr3d4t0r> agronholm_: Let's say that your transformer converts some weird HTTP craziness into a string. You'd use it like this in your endpoint:
[21:16] <pr3d4t0r> agronholm_: <inbound-endpoint address='http://localhost:8080/my_app' synchronous='true' transformer-refs='MyTransformer' />
[21:17] <agronholm_> when the meeting's over, come talk to me some more
[21:17] <pr3d4t0r> agronholm_: That means that your server will listen on port 8080, and if you hit http://agronholm.com:8080/my_app the payload, whatever it is, will be converted into a string by your transformer. The component associated with that inbound endpoint will only ever see a string.
[21:17] <pr3d4t0r> agronholm_: OKi.
[21:17] <agronholm_> I want to talk about clustering and redeployment too
[21:18] <pr3d4t0r> agronholm_: Heh - I just did a presentaiton about that in Poland two weeks ago. Wanna see while I'm gone?
[21:18] <pr3d4t0r> agronholm_: http://0921ccnz33vh1pvcmg02.images.s3.amazonaws.com/cdn/HA-FT-ROC-main.pdf
[21:18] <pr3d4t0r> agronholm_: HA-FT-ROC == High-availability, fault-tolerant, resource-oriented computing.
[21:19] <pr3d4t0r> agronholm_: It got one of the highest ratings at the conference.
[21:19] * juneau001 (~juneau@131.225.174.134) has joined #jython
[21:21] <agronholm_> very interesting
[21:21] <pr3d4t0r> agronholm_: Check it out -- I'll ping you when I return, in an hour.
[21:21] <pr3d4t0r> agronholm_: You can also email eugenex AT cime.net if you want.
[21:22] <pr3d4t0r> agronholm_: Or... check your private messages.
[21:28] <pr3d4t0r> agronholm_: It may also go to their head but if you start matching names to Google/Amazon you'll see that everyone there's authoring hardcore shit for O'Reilly, Apress, and so on. Lots of very smart peeps. Hence they make it hard for new blood at first.
[21:29] * juneau001 (~juneau@131.225.174.134) Quit (Quit: juneau001)
[21:34] * pigletto (~pigletto@dynamic-78-9-0-215.ssp.dialog.net.pl) has joined #jython
[22:52] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 260 seconds)
[23:24] * pigletto (~pigletto@dynamic-78-9-0-215.ssp.dialog.net.pl) Quit (Remote host closed the connection)
[23:33] * sgithens (~sgithens@2001:18e8:3:443:223:aeff:fe01:c4d) Quit (Read error: Operation timed out)
[23:48] * headius (~headius@216.160.3.79) Quit (Ping timeout: 260 seconds)
[23:51] <Oti> pjenvey: test_subprocess is indeed very slow, it takes 461 seconds on my machine
[23:51] <Oti> so i'll keep it as it is
[23:52] <pjenvey> Oti - I suppose we could turn it on for the buildbots temporarily, to verify the fix, then back off =P
[23:53] * headius (~headius@216.160.3.79) has joined #jython
[23:53] <Oti> ok, that's a good idea - a bit of danger since i could forget to turn it off again ...
[23:54] <pjenvey> I'm sure someone will eventually notice there regrtest times almost doubling =]
[23:54] <Oti> but let's do it this way

Index

These logs were automatically created by JythonLogBot_ on irc.freenode.net using a slightly modified version of the Java IRC LogBot (github).