[Uni-verse] Update of WP 6.2 (Alternative Server implementation)

[Emil Brink]

Eskil Steenberg wrote:
> Hi
> 
> It feels like the same featiures could be obtained much more easely. First
> of all i think re implementing the entire server is a waist of time. There
> is a lot of things and behaviours that are going to be exactly the same as
> the current verse server and that is going to take alot of time writing,
> testing and to get right (believe me i know...). so the security things
> should be added to a version of our server rathere then re-implementing
> everything.

True, except for the bits about threading and stuff. I seem to recall 
you Eskil addressing why threading won't help the server performance 
right away somewhere, but I can't recall it right now. I do know that 
when the server sits in some loop sending out content to one client, 
other clients will experience latencies. Right? This seems to indicate 
that a more parallel server is not useless.

> Then again saving/loading functionality already exists as a separate
> applications and there isnt huge need to re implement them either.
> Generaly the application you plan to write seams to be just way too big.
> The interface should obviusly be a verse client that controls the setings
> using the method call system, so that other applications also can be used
> and so that it can be done remotely.

This feels obvious to me too, until I started to think of how exactly 
you could do that. As far as I know, you can't? There is no avatar 
object node representing the server, so there would be nowhere to send 
method calls to, would there?

I find this a bit lacking; we have this neat (imo) remote procedure call 
system, but no way to use it to control one of the more interesting 
entities present in any session, i.e. the server itself.

I'm sure it could be worked around, or even extended, pretty easily, but 
it's not something that has been talked about. We should come up with a 
standard way of exposing methods on the server.

> And if you want to have a webpage wthat displays statistics and stuff
 > that functionality should also be a separate application that connects
 > to a server to retreve the data.

Sure, but if it's done locally in the server, there can be a lot more 
information available easily. To me, the obvious (?) way to do it would 
be to define a method[*] that accepts e.g. a text node and buffer pair, 
and has the server fill in either raw information, or pre-cooked HTML, 
there. This keeps the information flowing inside Verse, at least.

> Verse is meant to distrobute the development. if you write a webpage
> generator, that should obviusly be conectable to any server implementation
> not just yours. The same goes for savers, loaders, admin tools and other
> things as well. It will also cut the number of dependencys and help
> porting of each tool. It makes things so much more flexible if the
> functionalitys are separate and you can exchane and modify them
> indipendently.

Yeah, I agree, being distributed and adding functionality in independent 
modules is a big plus with Verse.

Regards,

/Emil

[*] Assuming that a way to address the server through methods is found,
     of course.