Loading ...
Sorry, an error occurred while loading the content.

Re: [interopathon] Re: [soapbuilders] SOAPVerse - the kernel of an idea for an interoperability test/de mo

Expand Messages
  • Paul Kulchenko
    Hi, Court! ... Yes. Several maps means several games. ... Exactly, interface for client. ... That s absolutely fine. It s just like class and you create
    Message 1 of 1 , Mar 21 6:39 AM
    • 0 Attachment
      Hi, Court!

      --- Court Demas <court@...> wrote:
      > - so Map is centralized - there is only one?
      Yes. Several maps means several games.

      > - Is a crawler something which itself moves from room to room? Or
      > is it an interface for the client to move between rooms?
      Exactly, interface for client.

      > - You say "get list of crawlers, choose one, etc...". What if two
      > clients choose the same crawler?
      That's absolutely fine. It's just like class and you create instance
      of it. Just means that they use the same implementation. All
      information should go back and forth, and there is nothing to keep on
      server side for crawler as far as I can see.

      > - when is it "over"? It seems there should be some goal or ending
      > point... for example, that each room was visited by a particular
      > implementation.
      As soon as you (as a user) wants to stop it. The goal is to draw the
      map (you can draw your personal map, how did you go) for the whole
      game that will show what rooms are most visited (server
      implementations are most interoperable) and what crawlers are most
      successful (clients are most interoperable) and more important what
      the promblems were.

      > Maybe you could have some information in each room which gets
      > collected, and
      > once you've been to each room you can easily determine whether all
      > rooms
      > have been visited (prime number in each room, add them all up, or
      > something like that).
      Kind of. I'm not sure about stat that will be collected yet, but
      that's the idea. Thank you.

      Best wishes, Paul.
      >
      > thanks,
      > court
      >
      > Paul Kulchenko wrote:
      >
      > > Hi, Glen!
      > >
      > > I was excited about the speed of decisions and the level of
      > > understanding yesterday and now I'm observing the number of
      > political
      > > issues around it today and it makes me ...hm, kind of sick, so
      > I'll
      > > talk ONLY about technological aspects and I would be the first to
      > > implement it as soon as we agree on it (and maybe even befor :)).
      > >
      > > --- Glen Daniels <gdaniels@...> wrote:
      > > > This is a quick writeup of an idea that a bunch of folks had
      > last
      > > > week while
      > > > discussing interoperability demos and tests. It's a pretty
      > simple
      > > > system
      > > > which we thought was a) fun, b) technically interesting, and c)
      > > > quite a compelling demo. I'd like to know what people think of
      > the
      > > > idea - is this too ambitious, is it something you'd be psyched
      > to
      > > I hope it's not and I agree with goals.
      > > > help design/implement, is it cool?
      > > I think it is and here is my view on that.
      > >
      > > Map (A x B rooms)
      > > Every room is server implementation (server)
      > > Several crawlers are available to go throuh map (client and
      > server)
      > >
      > > Procedure for participants:
      > > GET list of crawlers from Map
      > > choose one
      > > START with this crawler ([x,y]) and get back information where
      > you
      > > are (crawler will MOVE_IN into specified room)
      > > you may GET_LIST of other crawlers in this room, WRITE_NOTE for
      > > other crawlers, READ_NOTEs posted by others
      > > now you may MOVE your crawler somewhere (direction) and crawler
      > > will tell current room MOVE_OUT and new room MOVE_IN. MOVE_OUT
      > > shouldn't fail (otherwise you're locked in :)), because you
      > already
      > > succesfully moved in, but MOVE_IN may fail, so you'll be in the
      > same
      > > room.
      > >
      > > Why do we need crawlers and do not tell directly where we want to
      > go
      > > (MOVE_OUT to one room/server and MOVE_IN to another one)? First,
      > if
      > > we really want to test interop both sides should be under some
      > > control (not political :)) to log in errors and be sure that both
      > > sides are doing it right. Second, it will let us to test
      > > interoperability on two levels: from user to crawler and between
      > > crawlers and servers. It'll let user switch crawler and keep
      > moving,
      > > so after some time we will have map how crawlers are moving (and
      > > where) and problem spots on our map. Providing different
      > interfaces
      > > to crawler (it could be web, GUI or something else) you can drive
      > it
      > > thru the map, so it becomes accessible to (almost) everybody. Yet
      > > you're able to call servers directly, but that's your
      > responsibility
      > > to handle and deal with errors, interfaces, etc.
      > >
      > > Map interface
      > > add_field(endpoint, details) -- register server to participate
      > > add_crawler(endpoint, details) -- register crawler
      > > get_list_of_crawlers
      > > draw_the_map -- :)
      > >
      > > Room interface
      > > move_in
      > > move_out
      > > write_note
      > > read_notes
      > > get_list_of_crawlers_here
      > >
      > > Crawler interface
      > > start([x,y])
      > > move(direction) -- does move_out from one and move_in into
      > another
      > > one
      > > write_note -- "I was here"
      > > read_notes
      > > get_list_of_crawlers_in_this_room
      > > get_room_information
      > >
      > > In my understanding central point IS required, just because both
      > > server and crawler implementation should be REALLY simple and
      > DOES
      > > NOT require any back-end, like persistent storage, databases,
      > etc.,
      > > not because it difficult or will take time, but just because
      > we'll
      > > cut implementations that otherwise could participate, like Kafka
      > > (XSLT) or I don't know, maybe SOAP.py. In my understanding (since
      > we
      > > have both client and server in crawler) crawler should try to go
      > > inside the room (different implementation) and then report to
      > server
      > > result (no one else will be able to do it, current room doesn't
      > care
      > > about it and new room may not know about it, because message
      > wasn't
      > > parsed). That's another reason why I think it shouldn't be just
      > > client to talk to server, but specific crawler that will have
      > little
      > > bit logic inside. Another important piece is that all reauired
      > > information going back and forth and is not stored somewhere
      > except
      > > client's computer (or maybe yet central point for stat) and it'll
      > let
      > > switch crawler and keep going farther.
      > >
      > > So, the picture is:
      > >
      > > [any client: client, could be browser, applet, application,
      > whatever]
      > >
      > > /----- game borders ----------------------------
      > > |
      > > | [crawler: implements both client and server]
      > > |
      > > | [room: server only]
      > > |
      > > | [map: central point, control the game, server only]
      > > |
      > > \----------------------------------------------
      > >
      > > In this picture Map should be MOST interoperable implementation
      > at
      > > this time, because anyhow crawler and any other client should be
      > able
      > > to talk to it. Then everybody can write server (interface is
      > simple)
      > > and see how it goes. More efforts required to write crawler, but
      > it's
      > > more interesting also, and could be done independently. Anyway,
      > we'll
      > > be able to check interop between users and crawlers and register
      > > (hopefully) all issues and problems in interoperability between
      > > crawlers and rooms.
      > >
      > > Having central point will slightly modify the interface, so let
      > me
      > > know if you think it IS or ISN'T required. Any thoughs will be
      > > greatly appreciated.
      > >
      > > Best wishes, Paul.
      > >
      > > >
      > > > The SOAPVerse : A long-term SOAP interoperability demo
      > > > ------------------------------------------------------
      > > >
      > > > [1.0 Introduction - the view from outside]
      > > >
      > > > I'll start explaining the idea by giving a brief scenario. You
      > > > connect a
      > > > browser to SOAPVerse.org, which gives you three choices - 1)
      > enter
      > > > the
      > > > SOAPVerse, 2) look at the map, and 3) learn about joining. You
      > > > choose #1,
      > > > and are offered a list of available clients and "entry portals"
      > > > (i.e.
      > > > clients (no, not "IE clients", necessarily...)) on the web.
      > You
      > > > choose a
      > > > local entry portal, and a Java applet appears, primarily
      > composed
      > > > of a text
      > > > window:
      >
      === message truncated ===


      __________________________________________________
      Do You Yahoo!?
      Get email at your own domain with Yahoo! Mail.
      http://personal.mail.yahoo.com/
    Your message has been successfully submitted and would be delivered to recipients shortly.