Camelia, the Perl 6 bug

IRC log for #bioclipse, 2008-04-06

| Channels | #bioclipse index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
09:01 egonw joined #bioclipse
10:40 edrin joined #bioclipse
10:40 edrin hi egon
10:43 egonw hi edrin
11:03 egonw_ joined #bioclipse
12:06 edrin joined #bioclipse
12:06 edrin egon, did you follow the (standards) discussion?
13:00 egonw yeah, a bit
13:01 egonw saw several new +'s
13:01 edrin yes
13:01 edrin it's quite positive
13:01 egonw yeah
13:01 egonw with good, constructive comments
13:01 egonw not sure about the 'webservices for xmpp
13:01 egonw '
13:01 egonw though...
13:01 egonw one argument: it's not HTTP, so not web
13:02 edrin ok :)
13:02 egonw just realized that
13:02 edrin better not call it Web Service ;)?
13:02 egonw no, indeed
13:02 egonw will comment that now
13:02 edrin stpeter: "Maybe we should change the title to "Web Services over XMPP"?  "
13:03 edrin but wait
13:03 egonw ok, I'll wait...
13:03 egonw for what?
13:04 edrin The German "WebService" wikipedia article says: Webservices sind jedoch nicht an HTTP gebunden und lassen sich auch mit anderen Protokollen wie SMTP oder FTP �bertragen und sind somit offen f�r verschiedene Anwendungsszenarien geeignet.
13:05 egonw yeah, that's caused by the overloading of the term
13:06 edrin I think most people that know the word Web Service (and that are not SOAP specialists) wont associate it automatically with http
13:06 egonw for many, a webservice is even a webpage which provides some services
13:06 edrin yes
13:07 egonw what about "XMPP-based webservices"
13:07 edrin yes
13:07 edrin i like this
13:07 egonw nah, that does not really add anything, does it?
13:07 egonw over XMPP even is more informative...
13:07 egonw as it indicates that XMPP is the transport layer
13:07 edrin yes
13:08 egonw titles are always tricky
13:08 edrin this stpeter is the XEP editor
13:08 egonw yeah, I know
13:12 egonw might you please send around (Ola, Rajarshi, Mark F., me, etc) an overview of the changes you made, when you submitted a revised XEP?
13:12 edrin The comment of Richard Smith about adding "error infromation" is good. i think i will add this
13:13 egonw that was about the <cancel/> ?
13:13 egonw that was a nice one...
13:13 edrin ok, will send around revised XEP
13:13 egonw yeah, and please talk us through the changes...
13:13 edrin yes, the cancel example i will add, too
13:13 egonw that's I think something SOAP does not support, does it?
13:13 edrin i dont think so
13:14 edrin the Richard Simth said he would like to have the possibility of defined process specific error info in the data container, too
13:14 edrin i agree.
13:15 edrin the data container could therefore should also contain <error/>
13:15 edrin sorry
13:15 egonw ah, yes, that sounds like a good idea
13:15 edrin the data container could therefore also contain an <error/> Schema. this would be similar to a Java Exception
13:15 egonw I can appreciate that... having used Java stacktraces for so long now :)
13:15 egonw ah, indeed :)
13:16 edrin fo other languages they will find a way to handle this, too...
13:17 edrin although the Exception-way would make sense in a non-listener based code realisation (the old blocking result=f.invoke() way)
13:17 edrin i mean
13:17 edrin to really compare it with a Java Exception
13:18 edrin anyway
13:19 edrin stpeter suggested to add additional error options to the Ad-Hoc Command abstraction layer. I disagree here. because these errors are specific for our data container. they should therefore be in the data container...
13:19 edrin errors are possible on several abstraction layers
13:20 egonw yes
13:20 egonw but that's part of the design, which appears to need to be more clear :)
13:20 edrin example: abstraction layer 1: <iq/>, abstraction layer 2: ad hoc command, abstraction layer 3: IO DATA - where we come to the next criticism of Fabio Forno
13:21 edrin abstraction layer 4: RESTified services
13:23 edrin if i understand him right he wants to remove all the input/output definitions from IO DATA to make it completely open what is in there (because he is obviously thinking in a total REST way)
13:23 edrin but i cannot imagine how someone could write a less complicated web service library if we do so...
13:24 edrin i think we first need a f(x)
13:24 edrin he does not want the async f(x) but wants to push REST stuff directly...
13:25 edrin i think it is a better solution to first have f(x) and then ... x will just be a RESTfull object...
13:26 egonw sorry, can't follow you
13:26 egonw think I missed that comment
13:26 edrin heh
13:26 egonw the REST discussion was about session management not?
13:26 edrin he wrote so many mails
13:26 edrin yes, this too
13:26 egonw but I can't relate that to what you just wrote
13:26 edrin just a second
13:28 edrin Fabio Forno's mail from 05.04.2008 00:19
13:29 edrin The type of the the
13:29 edrin http://xmpp.org/protocol/io-data child tries to fix this limitation
13:29 edrin with some possible meanings of the command: input/output/get-schemata,
13:29 edrin but it still uses a fixed vocabulary. Perhaps if you just allow any
13:29 edrin value for type attribute we reach full flexibility and equivalence
13:29 edrin with REST.
13:30 edrin .
13:30 edrin .
13:30 edrin if we do this ... its almost impossible to have a general rule how a remot function invokation will look like
13:30 egonw mom
13:31 edrin the other comment "Finally I think that the <in/> and <out/> children are unnecessary" he is right... will fix this
13:32 egonw about the last... following the line that was is send to the service is input,
13:32 egonw and what the service sends is output?
13:32 egonw makes sense...
13:32 edrin yes
13:32 edrin and
13:33 edrin it is defined by the type attributes (input/output/io-schemata-get/io-schemata-result) anyway
13:33 egonw ok
13:33 egonw ah...
13:33 * egonw just opened the XEP
13:33 egonw 0.0.2 is the latest, right?
13:33 edrin but he also suggest to not even define the type attributes... if we do this it will be impossible to write a simple to use web service lib
13:33 egonw btw, does the font size have to be this small?
13:33 edrin yes
13:34 egonw right...
13:34 egonw let me think about the controlled vocab for @type... or not
13:34 egonw the XML way to go, would be to separate the vocab from the XEP...
13:34 edrin egonw: heh the font size had to be that small to reduce the size of the pdf to send it to the mailing list. took me one houre to make this...
13:34 egonw quite the way XML Schema Data Types works...
13:34 egonw ah, IC...
13:35 egonw ok, fine...
13:35 egonw so, I'd suggest to do this:
13:35 egonw have a default XEP-IO-Data based vocab for @type's...
13:35 edrin i will even add another type attribute: "error" - for error info
13:35 egonw so, iodata:input, iodata:output, etc
13:36 egonw and iodata:error
13:36 edrin yes
13:36 egonw then it is trivial to add additional commands later
13:36 egonw without having to change the XEP
13:36 edrin hm, i disagree here
13:36 egonw ok, explain
13:37 egonw ummm... regarding dropping <in> and <out>
13:38 edrin in my opinion with the current xep it is easy to write a (optinal: listener based) web service remote function invokation library. if we allowe other data types we risk incompatibilities between the libraries/services...
13:38 egonw how you'll do Example 5 then?
13:38 egonw ah, correct, but the incompatibility would be tracable...
13:38 edrin yes
13:38 edrin exmample 5. just a second, first the othe rthing
13:38 egonw that is, the library would support the XEP IO-DATA + the vocabulary of IO-data-default-io-types
13:39 edrin in my opinion the REST stuff would be another absraction layer:
13:39 egonw much like libraries support XML Schema + XML Schema Data Types
13:39 edrin like:
13:39 egonw if a different namespace for the data types is used, then the library would eaily detect this, based on the namespace
13:40 edrin y = f(x); while y=f() is our XEP, and X may be for example a RESTified object...
13:40 egonw please define y, f() and x
13:40 egonw x is the <in>?
13:40 egonw f, the service?
13:40 edrin i think if you do REST you will hae something like service.invoke(my_rest_object)
13:40 egonw and y is the <out>?
13:41 edrin yes
13:42 edrin how else would someone do a REST service if not calling a function
13:42 egonw and what's the difference between y=f(x) and y=f()?
13:43 egonw and why do you say the XEP defines y=f() ?
13:43 edrin sorry for being confusing
13:43 egonw np
13:43 edrin lets say the xep defines y=f(x);
13:43 egonw the XEP, or some service?
13:44 edrin if someone wants to do something in a restful way, he will - if I understand REST right - depend on a y=f(x) anyway.
13:45 edrin so i think if he needs REST this will be the next abstraction layer anyway
13:45 egonw mmm... I think I need to read up about REST principles...
13:45 * egonw does not think y=f() makes sense at all
13:46 egonw why have a webservice that takes no input?
13:46 edrin like layer 0: xmpp, layer 1: <iq/>, layer 2: ad hoc command, layer 3: IO DATA (y=f(x)), layer 4: a RESTfull service
13:47 edrin egonw: forget about the y=f(), that was stupid from me
13:47 egonw ok, that explains ... :)
13:47 egonw hahaha...
13:47 egonw ummm... sorry :)
13:47 egonw ok, this layering looks good...
13:48 egonw but please explain me how RESTfull is a layer on top of IO DATA
13:48 edrin all i mean, REST would rather depend on a well defined remote function call protocol than the other way round
13:49 egonw right
13:49 egonw agreed
13:49 egonw 1+2+3 == HTTP/GET/POST
13:49 egonw yep, agreed...
13:49 * egonw is reading WP on REST
13:50 edrin you would just have input/output schemata that conatain yet another session ID. and then your remote procedure call  will just finish imediately... I anyway wonder how he wants to have a generalized asynchronous notification in combination with REST
13:52 egonw well, reading the WP on REST, it does not make sense either
13:52 edrin maybe a "something changed" notification message that can occure multible times...
13:52 egonw WP actually is close to what I had in mind with REST
13:53 egonw WP mentions a claim that it "Depends less on vendor software than mechanisms which layer additional messaging frameworks on top of HTTP"
13:53 egonw hahaha.. messaging framework: XMPP, XEP-IO-DATA...
13:53 edrin where can I read WP on REST
13:53 egonw http://en.wikipedia.org/wiki/R​epresentational_State_Transfer
13:53 edrin ah
13:53 egonw and caching is menioned...
13:54 egonw it's more in the area of object exchange
13:54 egonw not unlike io-data
13:54 egonw which the major exception...
13:54 egonw that caching does not make sense in this case,
13:54 egonw as the input is seldomly the same
13:54 egonw or so diverse... like chemical space without about 10^60 druglike molecules :)
13:55 edrin now I am lost
13:55 edrin :)
13:56 egonw anyway... REST versus IO-data, not REST on top of IO-data...
13:56 egonw there simply is state in this XEP
13:56 edrin so far i considered it to be a shared xml document where both, the client and the server, can change content
13:56 egonw someone commented on that...
13:56 egonw calculating, finished...
13:56 edrin yes, Fabio
13:56 egonw clear states, I'd say
13:57 edrin what do you mean? "anyway... REST versus IO-data, not REST on top of IO-data..."
13:57 egonw if I read the WP, REST is much like something completely different to what the XEP tries to acchieve
13:58 egonw which would indicate that doing a RESTfull service on top of XEP a bit weird...
13:59 edrin am I wrong when I consider REST to be seomthing like a shared xml document where both, the client and the server, can change content?
14:00 egonw no, I think something RESTful is really like this:
14:00 egonw ...
14:01 egonw http://depth-first.com/articles/tag/rest
14:01 egonw eg http://www.chemspider.com/InCh​IKey=DEIYFTQMQPDXOT-RERXVCSDCZ
14:01 egonw so, one URI for one particular service call
14:02 edrin ic
14:02 edrin hm
14:02 egonw wp: "An important concept in REST is the existence of resources (sources of specific information), each of which can be referred to using a global identifier (a URI)."
14:02 edrin yes
14:02 egonw possible with some operation on them...
14:02 * egonw wonders of that doctoral thesis is available online...
14:03 edrin your's?
14:03 egonw anyway, I think the REST on top of IO-Data is a good idea...
14:03 edrin yours?
14:03 egonw no, the one on REST
14:03 edrin ah
14:03 edrin ok
14:03 egonw by Roy Fielding
14:04 egonw not sure yet if is makes sense...
14:04 egonw but seeing REST as layer on top of IO-Data makes sense
14:04 edrin to have REST?
14:04 edrin yeah
14:04 egonw to have REST on top of IO-Data... not sure if that makes sense, but apparently people see a need for that...
14:04 egonw and then as layer on top, that makes sense
14:05 edrin but i think we should not give up a/the strictly defined type atribute vocabulary
14:05 egonw anyway... you'd still have to think about how to support that with a 'fixed' set of @type's...
14:07 egonw so I think the use of customizable, but controlled vocab's is a good idea then
14:07 egonw then a library would support the io-data XEP + at least the in the XEP defined controlled vocab of @type's
14:08 egonw plus possibly more later...
14:08 egonw then you still have the advantage that a library can support 100% of the XEP
14:08 edrin yes
14:08 egonw and that this XEP-supporting lib can provide 100% of the functionality
14:09 egonw ummm... that users can be sure to have 100% of the functionality in the XEP
14:09 edrin yes, this is important
14:10 edrin considering what happened with all the SOAP libaries that are not compatible with each other because there were too many specs
14:16 egonw and, using namespace approaches, you can ensure that no future incompatibilities can creep in
14:16 egonw sorry... got a phone call
14:16 edrin no problem
14:17 egonw have to get the kids under the shower now...
14:17 egonw I understand your concerns...
14:17 egonw and much appreciate your worries about Axis 1.3/1.4/2.x crap
14:18 egonw but think that controlled vocabs can deal with this...
14:18 egonw bbl
14:35 * egonw is back
14:44 edrin egon, one thing. I really hope that it will be possible to dynamically marshal java objects at runtime from XML Schemata. this will be not important for Java development but for dynamically written/generated Rhino javascript scripts where the IO Schemata are discovered at runtime...
14:45 egonw what's a XML schemata when compared to a XML Schema?
14:45 edrin for java development someone could just push the Schemata to a XML Schema to Java Code Generator/API application...
14:45 egonw for example
14:45 edrin it's plural
14:45 egonw ah...
14:45 egonw ic ...
14:45 egonw :)
14:45 egonw well, one could also use a general XML library
14:45 egonw e.g. XOM for Java
14:45 edrin yes
14:46 edrin sure
14:46 edrin but it would be excelent if we would have something like this:
14:46 edrin var schemata = function.getIoSchemata();
14:46 edrin var inputOutputFactory = new IoFactory(schemata);
14:46 edrin var input = inputOutputFactory.createInputObject();
14:46 edrin input.setWavFile( ...base64-encoded-audio... );
14:51 egonw well, talking about controlled vocabs :)
15:06 edrin egon, i just sent you a 6 sildes presentation via email
15:19 egonw ok
15:23 edrin have to leave now
15:23 edrin cu later maybe :)
15:23 edrin is the presentation somehow clear?
15:24 egonw will email
15:24 egonw making dinner
15:24 edrin ok :)
15:24 edrin cu
17:46 egonw joined #bioclipse
17:48 ChanServ joined #bioclipse
17:53 ChanServ joined #bioclipse
18:03 egonw_ joined #bioclipse
21:07 edrin joined #bioclipse
23:06 edrin joined #bioclipse

| Channels | #bioclipse index | Today | | Search | Google Search | Plain-Text | summary