Talk:Spec:Place

[edit]

Place Interfaces

Having the possibilities of several (unlimited) types of places creates the need for which methods each type provides and what behavior is to be expected. Examples for different types include but are not limited to:

  • blog
  • chat
  • miniblog (twitter stuff)
  • forum/board
  • newsfeed

I suggest we introduce a certain entity variable _api or _interface or _type or, if the place supports several, _list_<one of the preceding>. This variable should be included in any information request about the place, as well as when we subscribe to a context of that place. Opinions?

--Marenz 12:48, 14 April 2010 (CEST)

<lynX 09:02, 15 April 2010 (CEST)> The original plan was to implement a decentralized conference control protocol. I wrote it down in 1995 in http://www.psyc.eu/conferencing but then we never really needed it, so in practice we have only been using simple little hints like _control _silent or even XMPP-MUC-compatible flags such as _list_feature.

The original MMP conferencing proposal is written in a very P2P vein:

  • There can be as many context authorities (masters) as you need
  • Enter/kick decisions can be delegated away from the context master
  • Voice rights are modeled so you can have hybrid multipeer multicast sending
  • A multicast tree structure is provided top-down.
  • Each member is represented by UNI, UNL and even a set of routing schemes meaning TCP, UDP, IP Multicast or other infrastructure options.

<[Tycho] 13:28, 15 April 2010 (CEST)> Sorry, lynX, but we are talking just about visual representation of messages in context. As I can see, you are talking about something different.

<Marenz 15:19, 15 April 2010 (CEST)>: I wasn't talking about any visual representation at all, neither of messages nor of context. When I say "interface" or "type" i mean the protocol interface as in the available methods of the entity, which has nothing to do with any visual representation of anything.

<Marenz 02:02, 17 April 2010 (CEST)> Still you are right, it is something else than what your conference protocol tries to do. It is not about controlling who is allowed to do what, it is about what functions the context provides. Functions like _message_comment for posting a comment to a blog entry or _message_reply for writing a reply in a forum to a certain topic. A blog offers different methods for using it as a forum. What I want to do is, define certain types/interfaces that a context can decide to provide upon entering it in a variable. We would have a certain set of predefined types (like the ones listed above) and of course any one can use any type one pleases, like a type "camera-controller" that offers _request_rotate_x and _request_rotate_y but only the correct client could use it properly (or a user that tries the offered commands manually, which of course she must know). Games could use that to offer gaming interfaces, e.g. type "EmpireEath" which has methods like _request_build_tower and _request_build_archer and whatever.. I hope it is more clear now where i want to go :)
<[Tycho] 13:48, 17 April 2010 (CEST)> Yes, you guessed correctly about _request_rotate_y :) But currently to froze we just need to decide a way for context to announce it's "type" before and at the time of entering. The actual types besides the default one can be added later by developers (or as part of specs for some basic types, but those aren't showstoppers).

<[Tycho] 22:29, 16 April 2010 (CEST)> The messages itself should be almost the same, just with added variables.

<Marenz 22:30, 16 April 2010 (CEST)> yes, the messages. And the available methods? and the variables they need to have defined? and the expected behavior? unknown.

<[Tycho]> The main idea is to have complete backwards compatibility, so any client can join any context and see the messages as long as they contain human-readable text (all basic types like blogs, microblogs, chats and so on). So all methods should be the same, except for those created by developers later for their special purpose.

<[Tycho]> Where this variable should be present ? Only when the context type is not default one.

  • _list_places_public
  • _list_places_entered
  • _echo_place_enter

<lynX> The names of methods will certainly change but I understand what you want to achieve. I wonder if some characteristics of the places are worth their own glyphs in the uniform rather than everything being an '@'. Well, let's see how all of this evolves – I guess we should look at other showstoppers before we move on with details of this...

<[Tycho] 20:23, 18 April 2010 (CEST)> I understand what you want to do with glyphs, but this is obviously wrong way since there is too few available chars are left to use, while my "type/interface" mechanism allows unlimited number of those types. And actually i don't want to use even "@", as you know :)

Retrieved from "http://about.psyc.eu/Talk:Spec:Place"