#coders log of new obj syntax by Michael Day

*Mike (~mikeday@203.42.254.4) has joined #coders
<Mike> I'm thinking you can duplicate Atlas functionality
<Mike> using one tag, <obj>, as follows:
<Mike> <obj name="..." type="..." data="..."> ..children.. </obj>
<Mike> for an example:
<Mike> <obj type="msg">
<Mike>      <obj name="to" type="id" data="777:change"/>
<Mike>      <obj name="from" type="id" data="123"/>
<Mike>      <obj>
<Mike>                    <obj type="id" data="777"/>
<Mike>                    <obj name="HP" type="int" data="40"/>
<Mike>      </obj>
<Mike> </obj>
bryce (bryce@ppp242.neptune.net) has joined #coders
<Mike> although the resulting XML looks ugly,
<Mike> it maps much more nicely to code and to alternative session layers
<Mike> as well as being easier to grok and describe I believe
<Mike> freeing up the job of specifying Atlas at a lower level,
<Mike> allowing us to actually define interfaces and messages,
<Mike> without mixing up the discussion with lower level tag questions
<Mike> which right now I think are slowing us down.
<Mike> I've been toying with some potential implementations with fex,
<Mike> he's done some good thinking on improving the libAtlas situation
<Mike> but as it could be seen as a fairly drastic change to Atlas,
<Mike> would appreciate your comments, particularly on any
<Mike> awkward aspects that I have forgotten :)
* cyanide has quit (leaving)
 aloril trying to get jamie here too ;-)
 aloril thinks
<aloril> data could be another object
<Mike> not exactly
<Mike> as the only thing object can contain is other objects
<Mike> simplifies thinking and parsing
<Mike> name/type/data are all optional
<Mike> though possibly type/data will be abstracted into one value
<Mike> (one strongly typed value, so as not to hurt non-python coders)
<Mike> the current definition for object in Mercury:
<Mike> :- type object
<Mike>      --->        object(
<Mike>                                      maybe(string),                
% name
<Mike>                                      maybe(value),          % type
<Mike>                                      list(object)            % children
<Mike>                             ).
<Mike> woops that "type" comment is inaccurate, but you get the idea
<Mike> much simpler than the previous Atlas incarnation
<Mike> yet capable of containing the same data, and more
<aloril> which is simpler than old cyphesis protocol ;-)
<Mike> heh bit of a trend, obviously :)
<aloril> next version: values: 0/1: you do rest of interpretation ;-)
<Mike> ah but the essential parts still remain
<Mike> data is in a hierarchical tree
<Mike> objects can be named or anonymous
<Mike> those are the invariant parts of the various Atlas'
<Mike> this version suffers no more from interpretation difficulties
<Mike> than the last
<Mike> and it makes a much stronger distinction between
<Mike> protocol elements and protocol interpretation
<aloril> how would you do this:
<aloril> <attr:arm><ent><attr:length><float>0.7</float></attr:length></ent></attr:arm> as part of some character entity?
<Mike> oh I was going to talk about this namespace convention you've adopted
<Mike> or rather, I was going to ask about it :)
<aloril> ahh.. just syntax change ;-)
<Mike> it seems a little inconsistent with the way
<Mike> namespaces are used in other XML based formats...
<Mike> for instance all HTML tags fall in the html: namespace
<Mike> and all XUL tags are prefixed with xul:
<Mike> how are you using it with attr?
<aloril> attribute names could be in server specific DTD doc
<aloril> ie each server has it's own attribute names
<Mike> that makes attr almost an entirely seperate DTD,
<Mike> with many tags, like arm etc?
<Mike> are you sure that is wise?
<aloril> no, it would be just list of tags
<aloril> but you may be right
<Mike> it seems like unnecessary manipulation,
<Mike> considering Atlas is not an XML format
<Mike> but rather a protocol with a potential for use
<Mike> with an XML based session layer.
<aloril> old syntax: <attr name="arm" type="ent"><ent><attr name="length" type="float">0.7</attr></ent></att> as part of some character entity?
<Mike> working on it...
<Mike> <obj name="arm" type="object">
<Mike>      <obj name="length" type="float" data="0.7"/>
<Mike> </obj>
<Mike> possibly, assuming I've interpreted correctly
<aloril> hmm.. seems right
<aloril> what about operation with more than one argument?
<Mike> type="object" would probably be replaced by something more useful
<Mike> like type="upper-limb" or something
<Mike> <obj> .. children .. </obj>
<Mike> where children is an arbitrary length list of nested objs
<Mike> so it handles lists of stuff much easier than current Atlas I feel
<Mike> where the syntax was not clear
<Mike> and the code was quite complex.
<aloril> yeah C++ version would be simpler...
<Mike> and Mercury version :)
<aloril> hmm.. it's more like syntax change, not any semantic changes
<Mike> plus it reduces the emphasis on Atlas in XML
<Mike> yep, not trying to change semantics
<Mike> that's why I've been trying to recode old Atlas examples
<Mike> to check that I haven't accidentally lost any necessary flexibility<aloril> <op><id>look</id> <id>foo_12</id> </op> ?
<Mike> it's easier to design new session layers such as binary
<Mike> for this scheme, I feel
*** bryce has quit (Leaving)
<Mike> <obj>
<Mike>      <obj name="to" type="id data="/>
<Mike>      <obj type="id" data="foo_12"/>
<Mike> </obj>
<Mike> incidentally that syntax you just gave is not correct even
<Mike> for current Atlas, should be <op id="look">
<Mike> in the translation I give, the operation name gets
<Mike> folded into the target of the message
<Mike> so that the method you're calling, or the object you're
<Mike> operating on, is just the tail end of the "to" field
<aloril> nope, it is correct syntax
<Mike> <!ELEMENT op     (from?,to?,time?,id,arg)>
<Mike> id is not optional
<Mike> woops
<Mike> sorry
<Mike> wrong line :)
<Mike> you're right
<Mike> I always get that wrong :|
<Mike> but yeah, I basically folded "to" and "id" together
<Mike> it seemed to fit better with the idea of calling remote methods
<aloril> hmm.. so <obj type="msg"> == current <op>
<Mike> or operating on remote objects, as it's all the same thing
<aloril> and <obj> == current <ent> ?
<Mike> yes basically. The type="msg" might be unnecessary,
<Mike> but I leave it in for clarity. <obj> is <op>, <ent> and <attr> :)
**wavey (~wavey@192.88.84.59) has joined #coders
<Mike> as <ent> has a list of attributes
<Mike> but <attr> also can have a list of sub attributes
<Mike> and, <op> can have lists of pretty much the same thing
<aloril> mike, see this: http://www.worldforge.org/website/protocols/proposals/operations.html#sight
<Mike> so it felt like there was a lot of overlapping functionality there
<aloril> (or from CVS same page)
<Mike> which one aloril?
<aloril> Common example: and Event example: 
<Mike> okay
<aloril> they have different 'type' of content
<Mike> I can code this up very naively and automatically
<Mike> whether it's meaningful is another question
<Mike> a higher level question
<Mike> <obj>
<Mike>      <obj name="to" type="id data="/>
<Mike>      <obj>
<Mike>                    <obj name="id" type="id" data="grass1"/>
<Mike>                    <obj name="stamp" type="time?" data="989.24"/>
<Mike>      </obj>
<Mike> </obj>
<Mike> that's a possible translation of common example
<Mike> <obj name="polygon">
<Mike>      <obj data="0,0"/>
<Mike>      <obj data="10,0"/>
<Mike>      ...
<Mike> </obj>
<Mike> that's a potential fragment from the second example
<Mike> could scrub the "data" attribute and put it in the body of the tag
<Mike> I'm not to fussed about that aspect of the syntax, and some
<Mike> people might object to attributes...
<aloril> yeah.. maybe combine type and data:
<aloril> <obj><floatlist>0,0</floatlist></obj>
<aloril> <obj name="id"><id>grass1</id></obj>
<aloril> <obj name="stamp"><float>989.24</float></obj>
<Mike> I would still like the restriction of keeping only
<Mike> one type and one chunk of data in an object though
<Mike> even though it can be a fairly complex chunk of course
<aloril> well those tags in above (id, float, int) would represent different physical formats
<Mike> <obj name="stamp" type="float">989.24 <obj> child </obj> </obj> ?
<aloril> hmm time:
<aloril> <obj name="time"><obj name="s"><float>12.34</float></obj><obj name="string"><string>0-0-0 0:12.34</string></obj>...
<Mike> seems a bit overly complex
<aloril> how you would do it?
<Mike> <obj type="time" data="12.34 0-0-0 0:12.34"/>
<Mike> wouldn't be so bad would it?
<Mike> or is s completely optional?
<aloril> s is not optional, but string part is
<Mike> oh okay
<aloril> and you left optional sadd ...
<Mike> <obj type="time" data="12.34">
<Mike>     <obj name="s" type data etc
<Mike>     <obj name="sadd" etc
<Mike> </obj>
<Mike> woops
<Mike> s/s/string-part/
<wavey> (need that rollback irc, mike)
 Mike grins
<Mike> I'll do it in Atlas after all :)
<aloril> how to differentiate between Common example: and Event example: ?<Mike> what is the actual difference between them?
<aloril> (common: you see actual object, event: you see movement event)
<Mike> oh event, I hadn't looked at that one
<Mike> in both cases you see an object
Mike (~mikeday@203.42.254.236) has joined #coders
<Mike> yeah, they're both viewing an object
<Mike> just one object is transient
<Mike> can still present the data the same way
<Mike> wrapping it in <op> doesn't simplify the code any
<aloril> another object does invoke this:
<aloril> :sight:move
<aloril> instead of :move
<aloril> yeah, but how to differenatiate? (using type?)
<Mike> if that's a valid sub-method/object, fine
<Mike> but now that's straying into actual Atlas discussion
<Mike> rather than lower level protocol discussion
<Mike> as move is a method call, "viewing" a move does not make
<Mike> much sense. Calling sight and passing an object containing
<Mike_> information pertaining to movement seem more useful
<aloril> well here is example where it does make difference:
<aloril> <op><id>sight</id>
<aloril>  <from>Joe_12</from>
<aloril>  <op><id>move</id>
<aloril>    <ent>
<aloril>           <id>vodka_12</id>
<aloril>           <loc><id>Joe_12</id><coords>0,0,0</coords></loc>
<aloril>    </ent>
<aloril>  </op>
<aloril> </op>
 Mike has quit (Ping timeout)
* Mike_ is now known as Mike
<aloril> ie you see joe getting vodka
<Mike> what is it that's tricky about that example?
<aloril> how to differentiate between <op> and <ent> argument for operation? type="msg"?
<Mike> you don't have to
<Mike> "sight" only takes one argument,
<Mike> the object that you saw
<Mike> that object is free to contain nested objects within it
<aloril> but how does sight method know which kind of argument it got?
<Mike> it gets an object!
<Mike> the object has an id
<Mike> it's either a persistent game object
<Mike> a transient event object
<Mike> or some other beast entirely
<Mike> that's not the domain of the protocol
<Mike> at this low level
<Mike> that's a higher level interfaces/specification question
<Mike> (the real business of Atlas)
<aloril> how would higher level interface differentiate between those?
<Mike> on the id
<Mike> or some other distinguishing information
<aloril> well they could be anonymous entities too (talk entity for example)
<Mike> then you witness an anonymous chunk of sound
<Mike> no harm there
<Mike> or an anonymous "chunk of movement"
<Mike> if the original <op> had an <id>...</id>
<Mike> that will need to be there
<aloril> both op and ent can have id, you can't distinguish using that
<Mike> an operation is just an object in this scheme
<Mike> just an attribute of an entity
<Mike> just another chunk of data that happens to be code
<Mike> reference it like any other.
<aloril> yes, but:
<aloril> <op><id>sight</id>
<aloril>  <ent>
<aloril>    <id>vodka_12</id>
<aloril>    <loc><id>Joe_12</id><coords>0,0,0</coords></loc>
<aloril>  </ent>
<aloril> </op>
<aloril> is legal too and how does recipient can differentiate between move and vodka_12 ?
<Mike> replace "vodka_12" with the id of your operation
<Mike> they don't have to
<Mike> strcmp("vodka_12", "move") != 0  :)
**cyanide (~ojw@reggae-04-139.nv.iinet.net.au) has joined #coders
<Mike> vodka_12 is just an object, move is just an object
<aloril> hmm... so this is how its done then:
<Mike> move most likely would be a sub object of a physics toolbox,
<Mike> or something equally arcane
<Mike> but that's not the protocol's business to know.
<aloril> is operation_dict.get(id)!=None: this is operation
<aloril> if operation_dict.get(id)!=None: this is operation
<Mike> I don't see the need for use of the term operation actually
<Mike> it seems quite ambiguous to me
<aloril> if method_dict.get(id)!=None: this is method ;-)
<Mike> and it's not relevant to lower level protocol discussion
<Mike> similarly with method
<Mike> it's just a chunk of data
<aloril> but you know it for sure only after asking server (in case of some operation client is not avare)
<Mike> we need more talk on these higher level Atlas features,
<aloril> but client can ask it beforehand though...
<Mike> the way we encode data should be simple and stop changing
<aloril> mike, your sounds quite cool actually...
<aloril> sorry for drilling you so much ;-)
<Mike> ah no worries, I've bugged you about Atlas far more :)
<cyanide> hmm, quick question - the <obj> tag is used for describing a hierarchy?
<Mike> it is a hierarchical data structure yes
<Mike> objs can contain objs
<aloril> it does force clients to fetch operation hierarchy before doing anything else though...
<Mike> possibly
<Mike> not necessarily
<cyanide> hmm
<cyanide> ok
<Mike> I haven't paid much attention to that issue yet though
<Mike> I need to clarify use of the type attribute
<aloril> mike, I wan't to catch jamie before deciding about above: two 'big' changes is unnecessary if we can make them one bigger change ;-)
<Mike> before I can make a more formal proposal regarding Atlas
<Mike> right, yeah I'd like to hear more about higher issues
<Mike> plus I was thinking with the new Atlas ideas floating around,
<Mike> we really need to update the Atlas site (next week?)
<Mike> it does not carry a useful definition of Atlas
<aloril> and of course if others are vehemently oppose and can justify it ..
<Mike> and many of the coders are drifting, really
<Mike> plus I'd like to back up any proposal I make with actual code :)
<aloril> mike, jamie said that too...
<aloril> he was coding his new proposal in C
<aloril> well in short you proposal:
<aloril> obj does have these:
<Mike> interesting :/
<Mike> not a language that's had much use here
<aloril> list: containing unnamed objects
<aloril> map: containing named objects
<aloril> jamie has his own server/client and already has protocol
<aloril> but would like to use atlas instead
<Mike> ah I see.
<aloril> ie he has experience as you can see from his mails to scripting@
<aloril> but he would like some changes ...
<aloril> and well I need catch him ;-)
<Mike> yeah I haven't talked to him personally
<aloril> your above suggestion does simplify libAtlas
<aloril> though now clients need to know all op.id:s
<aloril> though now clients need to know all op.id's
<Mike> could still specify inheritance
<aloril> inheritance is higher level feature
<Mike> can tell something is an op if it's a sub object of server,
<Mike> or something similarly banal
<Mike> server:move, or physics:move, or whatever
<Mike> then if you get physics:jump
<Mike> you don't know what to do, but you know it's an operation
<aloril> <op><id>get</id> <id>move</id> </op>
<aloril> to get info about what that mysterious 'move' obj is
<Mike> right
<Mike> I've got to go offline temporarily I'm afraid,
<aloril> all operations would be eventually inherited from : <ent><id>operation</id></ent>
<Mike> but thanks for the chat
<aloril> so thats how you now it ;-)
<Mike> I'll attempt to clarify my ideas
<Mike> and talk later in the week, or post the lists
<aloril> only problems is that you need to do it before any other action and that may be only small problem
<Mike> sorry I missed the last Atlas meeting by the way
<Mike> I heard about it after the event
<aloril> yeah it was kinda short warning time ;-)
<Mike> seemed to still be dogged by that ui-in-Atlas issue though
<aloril> yeah, we moved ui to later time..
<Mike> and I probably would have just started knocking heads together anyway :)
<aloril> MIM was most succesful result..
<Mike> right, still haven't fully grokked MIM, waiting until
<Mike> I'm done setting fire to Atlas :)
* aloril wondering what sal says about above syntax changes ;-)
<aloril> well MIM is going to have some changes
<Mike> perhaps I'll wait then :)