Yupi Emulator [C# 6/NHibernate/Post-Shuffle]

[Taiga]

Re: New Yupi Emulator [PostShuffle/C#6/Hibernate/Thrower/log4net/DotNetty/SuperSocket

@CodeDragon, again other good point. Making API compatible will be more complex, but why not just use the API? I think is good. Also the Database Modeling is changing rapidly, we using a tool of NHibernate that allows Database Upgrade. But we really want all data being managed by an unique module.

It's up to you on how you implement it. I would stick with the easiest solution since APIs tend to become very complex if you are going to start changing things around. Just give it some thought before you shoot your own foot off. I'm just making suggestions.

 

[ovflowd]

Re: New Yupi Emulator [PostShuffle/C#6/Hibernate/Thrower/log4net/DotNetty/SuperSocket

It's up to you on how you implement it. I would stick with the easiest solution since APIs tend to become very complex if you are going to start changing things around. Just give it some thought before you shoot your own foot off. I'm just making suggestions.

I think you're wrong (maybe i'be wrong) but the goodness of the API it's that it will not change, since only what changes it's in Backend.
The API will be the same, and only the backend will change. Obviously with major changes the API will change. But better change only one line command, than a lot of queries and PHP code.

 

[maritnmine]

Re: New Yupi Emulator [PostShuffle/C#6/Hibernate/Thrower/log4net/DotNetty/SuperSocket

the goodness of the API it's that it will not change

This is wrong. APIs will change as you add more features to your CMS that would then depend on a new API call or a modified API call. One day you might even realize your entire API scheme is poop and you redo everything.

Also, I'm with CodeDragon on this one. Coupling the API together with the gameserver is a very bad idea as the gameserver becomes a single point of failure which is very likely to suddenly just crash. A better idea would be to either have a separate API from the gameserver or have a direct connection towards the database as CodeDragon suggests. You can achieve most of the security benefits you get from encapsulating the database in an API by using access rights/privileges in the database.

Also, let me correct you that the API on the gameserver is not RESTfull as the gameserver itself is as stateless as you can get :^)

 

[ovflowd]

Re: New Yupi Emulator [PostShuffle/C#6/Hibernate/Thrower/log4net/DotNetty/SuperSocket

This is wrong. APIs will change as you add more features to your CMS that would then depend on a new API call or a modified API call. One day you might even realize your entire API scheme is poop and you redo everything.

Also, I'm with @CodeDragon on this one. Coupling the API together with the gameserver is a very bad idea as the gameserver becomes a single point of failure which is very likely to suddenly just crash. A better idea would be to either have a separate API from the gameserver or have a direct connection towards the database as CodeDragon suggests. You can achieve most of the security benefits you get from encapsulating the database in an API by using access rights/privileges in the database.

Also, let me correct you that the API on the gameserver is not RESTfull as the gameserver itself is as stateless as you can get :^)

Yes i agree in part with you. Maybe the API need be placed in somewhere else. But i continue thinking that API will be nice. But yes is harder.

 

[maritnmine]

Re: New Yupi Emulator [PostShuffle/C#6/Hibernate/Thrower/log4net/DotNetty/SuperSocket

But i continue thinking that API will be nice. But yes is harder.

In that case, make the model code a separate library you can re-use in your API module.

 

[ovflowd]

Re: New Yupi Emulator [PostShuffle/C#6/Hibernate/Thrower/log4net/DotNetty/SuperSocket

In that case, make the model code a separate library you can re-use in your API module.

Yupi is actually made in this way. We have separated modules working as Service.
We Have Yupi.Main.exe that call all modules, but actually have also Yupi.Rest.exe and Yupi.Model.exe

 

[maritnmine]

Re: New Yupi Emulator [PostShuffle/C#6/Hibernate/Thrower/log4net/DotNetty/SuperSocket

We Have Yupi.Main.exe that call all modules, but actually have also Yupi.Rest.exe and Yupi.Model.exe

Can you elaborate on why you did it this way?

 

[ovflowd]

Re: New Yupi Emulator [PostShuffle/C#6/Hibernate/Thrower/log4net/DotNetty/SuperSocket

Can you elaborate on why you did it this way?

Wasn't me. Was the Main Developer (Commiter) of Yupi Felix (Thedoct0r11)

 

[ovflowd]

Re: New Yupi Emulator [PostShuffle/C#6/Hibernate/Thrower/log4net/DotNetty/SuperSocket

Hey guys!
I added Documentation things directly with Swagger Update.
Check now the Yupi Emulator documentation here:

You must be registered to see links

 

[pel]

Any "updates" on the cms made by kylon? (or did he already give up again x.x)

 

[ovflowd]

Hum.. No he didn't gave up. He waiting someone code the RESTapi to he finish the Communication Engine.
I didn't finished the API in Swagger also, but we already have sufficient stuff in Swagger to do the basics of the Communication.

The developers of Yupi are afk, i think it's university stuff.
I'm also busy with university stuff.

But in my vacations will work hardly in Yupi.

 

[LeChris]

im late

how can cms be "small" and "fast" by
-combing high end c extension with hard installation for newbies with heavy framework

also if you're going for "rest api" why not use lumen? the fastest framework designed for apis, same developer as laravel


also
cms plan is dumb and you're overcomplicating things, learn KISS

points 1 and 2 contradict
rest of points are basic features of most frameworks

1. Will be a small and fast CMS
2. Using Laravel or PhalconPHP as Framework
3. Composer compatible
4. Built-in Installer
5. Template Engine
6. PDO & MVC
7. REST Module

 

[ovflowd]

Your comment it's outdated LeChris. See the discussions.
Those topics it's what i say to me when i want to go to sleep. Obviously will not be that.

As the developers said, Laravel supports Installer. I mean to create a Installer.
Small, it's small in disk space and size. Using SVG or SASS.

Thanks but i don't decide about the Framework. Know about kISS. Who will say what will be used it's kylon
I only suggested Phalcon or Laravel, personally i hate PHP Frameworks. Prefer code my own algorithms and learn with it. Some cases using libraries to help.

Which point is contradicting with what?.... [......]

What you mean with..
"Comining High end C extension"..

Heavy Framework... Hum... as i said, i prefer no Framework, but i don't know if the knowledge of Kylon it's advanced sufficient for that. He is learning most PHP. Like you, in my opinion.

Also know about Lumen, good idea. Really fast and small.

Again kylon will decide what will be done.
Those topics made by me, was an initial issue. Only to search about what can be merged in the software.
The internet has so many PHP frameworks that this is becoming to bore me.

So much same content. So much less innovation.



Observation.: KISSMVC it's outdated.



Observation.: Most thing that eat disk space are images and javascript.
CMS would be zero JavaScript. And zero​ Images.

 

[pel]

No JS and no Images?
Welcome to 1999!

 

[ovflowd]

No JS and no Images?
Welcome to 1999!

No Need of it.
SVG and SASS Images does a quite good job.
Why using JavaScript? We don't will need that. Maybe only for the Housekeeping.

Obs.: Also Less can do that.

 

[Joopie]

Observation.: KISSMVC it's outdated.



Observation.: Most thing that eat disk space are images and javascript.
CMS would be zero JavaScript. And zero​ Images.

No Need of it.
SVG and SASS Images does a quite good job.
Why using JavaScript? We don't will need that. Maybe only for the Housekeeping.

Obs.: Also Less can do that.

Well, I'm sure you know what you're talking about....

 

[Francis Joseph]

SVG and SASS Images does a quite good job.

You do not use SVG as a primary format for images on a website.

It should only be used where suitable, personally I only use it for rendering vector art such as logos. Mainly when I'm doing mobile application development because it keeps it looking crispy on every device. It's not something that you should be using throughout a normal website because it will make your website slow. I'm not sure what you're planning to use it for but you shouldn't be using it at all specially considering this is a Habbo project which couldn't possible have a requirement for SVG at all. You're going to end up bloating the hell out of your website.

Why using JavaScript? We don't will need that. Maybe only for the Housekeeping.

Always consider the user interface and the user's experience.

You should only take a sacrifice on the user interface when it damages the user experience. If something takes a toll on performance or ruins/dictates the flow of an application that's when it comes an issue. Removing Javascript because you don't need it is a huge step to consider. Personally, I love when a website takes advantage of it. Single page applications are honestly going to be the future in user experience.

Observation.: Most thing that eat disk space are images and javascript.

Please, oh please, do your research before starting a project.

Please look into the concept of minification/optimization/compression. Corporations do not just launch a static nor dynamic website straight off the bat. They use various compression libraries and methods to ensure assets stored for the website remain at a minimum. Code should never launched off production in a beautified state. Some modern browsers even minify website's assets in realtime as whitespace nor trails are needed. Do not over do a technical process for the sake of it. J-Query only way weighs 241.59kb when compressed so I can not imagine you writing some Javascript code big enough to even hit the 1mb mark.


It's great that you're making observations and you're keen to learn. But always consider the disadvantages alongside the advantages of a technical process. Even HTML5 supports application caching alongside JavaScript but these really shouldn't be concerned unless you're developing some sort of fully pledged web application.

Research is key otherwise you'll end up with a spaghettified and bloated website.


Good luck, I'm still lurking around on the thread.

 

[LeChris]

Okay,

I understand you're a horrible web developer, so I'll summarize.

KISS means to "Keep it simple, stupid"

Using a framework ,alongside an embedded and horribly implemented REST API to "be secure" is redundant, as any framework you use will automatically clean queries and any types of data used. Also, using any framework will more than triple your stack investment, and by the time you run composer installation it'll be 5 times the size of your assets (css/images).

Also,
There is plenty of innovation but a lot of people such as yourself are doing what has already been done, (re inventing the wheel) and considering it innovative because you're new to it. I have been using Laravel, Lumen, Angular, Node for a good year now and Sledmore is also using Laravel alongside an amazingly great javascript library for HabboRP. Using a framework isn't innovative, and not using a framework and creating your own algorithms is asking for bugs and issues (God forgiving I mention this, but your first PHP experience?)

Also, a few pointers to remember before doing a project of a high enough caliber

-Have an idea in mind
You currently have no clue what the duck you're dealing with in terms of security, causing you to write ALL WEB LOGIC ON YOUR SERVER? It isn't a REST API just because it's following a REST method on a system not designed for it, and especially highly inefficient at that, nor is it secure. Using a framework would be more than a hundred times better in terms of security and efficiency.

-Talk to your team
You obviously have no clue if Kylon is even capable, and you're mentioning random frameworks around assuming it'll be easy for your users to setup. There is a reason most hotels use Rev and Plus. It isn't that it's good, it's because they're easy. using any framework is a PR suicide, and not using one is a Code fluency suicide.

Basically, learn more of how web development works

 

[ovflowd]

Francis Joseph, i know all those things that you're saying. The onliest image in the CMS will be the logo, on max. It's a small CMS. With a minimal design. Really minimal design. With Client/Register/Index/Me/Staff/Articles.. And i think that's enough.

I'm not wondering about a complete suite for this project. Only a small thing, since Yupi works different.

I appreciate your big text Francis, your words are really more affordable than the words from LeChris, where he doesn't explain his point.
I know SVG isn't made for purpose of replacing Images of a web site, it's used for logos, art concepts, etc. Like as you said.

I know about codecs/compression, i'm doing Network Communications Engineering xD
You're right in all those points.

My user experience will be minimalist. I really don't know if a lot of users will use Yupi. And its development its really slowed down.
I agree that dynamic content is much better than static content.

Remember this is a test scenario. Yupi is in alpha. We don't are planning make something big yet. Not yet.

Thanks Francis!

 

[LeChris]

@Francis Joseph, i know all those things that you're saying. The onliest image in the CMS will be the logo, on max. It's a small CMS. With a minimal design. Really minimal design. With Client/Register/Index/Me/Staff/Articles.. And i think that's enough.

I'm not wondering about a complete suite for this project. Only a small thing, since Yupi works different.

I appreciate your big text Francis, your words are really more affordable than the words from LeChris, where he doesn't explain his point.
I know SVG isn't made for purpose of replacing Images of a web site, it's used for logos, art concepts, etc. Like as you said.

I know about codecs/compression, i'm doing Network Communications Engineering xD
You're right in all those points.

My user experience will be minimalist. I really don't know if a lot of users will use Yupi. And its development its really slowed down.
I agree that dynamic content is much better than static content.

Remember this is a test scenario. Yupi is in alpha. We don't are planning make something big yet. Not yet.

Thanks Francis!

you dislike my point because it's pointing out the flaws in your system