Compare: https://msdn.microsoft.com/pt-br/lib...v=vs.100).aspx (v4.5)Quote:
Originally Posted by Joopie
With this: https://msdn.microsoft.com/pt-br/lib...v=vs.110).aspx (v.5.2+)
Printable View
Compare: https://msdn.microsoft.com/pt-br/lib...v=vs.100).aspx (v4.5)Quote:
Originally Posted by Joopie
With this: https://msdn.microsoft.com/pt-br/lib...v=vs.110).aspx (v.5.2+)
.. well, i don't see it.Quote:
Originally Posted by ovflowd
I prefer CouchDB for "web-scale" things, and put the NodeJS in my ass because it sucks.Quote:
Originally Posted by maritnmine
Is this Emulator compatible with RevCMS? i tried but it doesnt look compatible, idk.
Development Paused.
Since appears that the developers have abandoned the project.
Commited to Yupi
We started the Documentation of the REST API of Yupi Emulator.
What is Yupi RESTapi?
Yupi Emulator, differently that others, will not support directly Database edits, since isn't ever recommended. Yupi will be the first Post-Shuffle emulator with a defined API, used for all external communications that doesn't are made by Client <> Emulator.
The RESTapi will do stuff like SSO auth between Client and Emulator; Management of any in-game Data, RCON commands, and more.
Some Features:
1. Ability of control the server remotely
2. Ability of see the logs, hardware usage, and in-game statistics
3. Ability of control every data related to in-game things, like: {users, rooms, navigator, catalogue, furniture, groups, and more}
4. Ability of use external commands like {shutdown, restart, stats, alert}
The Item 3 will work in the following scenario:
1. The HTTP request will do something like that:
2. The REST Manager will handle it and redirect it to a desired Solution Handler (Controller), in case of Users, something like UserControlHandler.csCode:PUT https://your-server:8080/users?id=1
BODY {
username : newUsername,
rank : newRank,
...
}
3. The Handler will do something like send a Composer to Client with the new User Data
4. NHibernate will manage and update the Data Models and execute the transactions.
5. UserControlHandler.cs will return a message to REST Manager that will deliver it back to the Requester
(Something like that.)Code:CODE: 200 OK
BODY: {
message : "User Edited successfully"
}
You can see the RESTapi Documentation in the GitHub, in /Api/ folder. You can test the API in https://editor.swagger.io (We're using Swagger for YAML documentations)
Thanks!
- - - Updated - - -
YupiCMS
We are officially developing our CMS, made by @kylon
The CMS will have the following features:
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
8. Communication made with Emulator totally by REST
9. Will not use Connection with DATABASE, all Data Communication, Auth and User registration will be made by REST!!
10. Using Bootstrap 3.0
11. A powerful Housekeeping were you can control all Server features, like Edit User Data, Catalogue, Furniture, User Items, Rooms, Groups, etc.
12. And more!
- - - Updated - - -
Commited to Yupi
Updated Swagger Documentation
Sorry but wouldn't it make more sense to take a microservices architecture approach like the actual Habbo?
They are currently using https://github.com/orbit/orbit/wiki for their distributed systems which looks good.
Orleans looks interesting and seems to be faster then Orbit, https://github.com/dotnet/orleans - keep up the research!
Thanks for the nice tip! @Francis Joseph. I will create now an Issue in the Repository to debate about this.Quote:
Originally Posted by Francis Joseph
Can you explain a little bitter about what is "Orleans"?
Also what you think about the RESTapi?
Also if we're talking about scaling and redistribution we can use Cassandra for Database and Apache Hadoop.
Bootstrap 3 is not supported anymore as far as I know.Quote:
Originally Posted by ovflowd
It is still supported? It's even on the main download page of the official site...Quote:
Originally Posted by iExit
Bootstrap · The world's most popular mobile-first and responsive front-end framework.
It's nice to see a different approach for the back-end communication between web and server. This might actually be better then the socket 2 socket. Also make sure you double check your CMS info it doesn't make sense at all...
phalconphp and Laravel are two different frameworks.
Well, thanks.Quote:
Originally Posted by CodeDragon
I thought I read something about its not supported anymore.
Quote:
Originally Posted by CodeDragon
Yes i know, we will use PhalconPHP or Laravel, i prefer Phalcon.
Also what you mean with |Make double check with CMS info?|
What i'm planning:
1. In CMS Settings file we have a Token (Application Token)
2. The tokens are created in the Emulator Terminal by: token-gen ApplicationName ApplicationAddress (Futurely)
3. CMS communicate with the Emulator by REST. Not by Database.
Related Issue: https://github.com/sant0ro/Yupi/issues/156
> Using Laravel (and somehow PhalconPHP)Quote:
Originally Posted by ovflowd
> Calls it small
How does that even work? Lol?Quote:
Originally Posted by ovflowd
Considering composer comes packaged with 90% of modern PHP frameworks, not really a valid point.Quote:
Originally Posted by ovflowd
So basically this? https://github.com/RachidLaasri/LaravelInstallerQuote:
Originally Posted by ovflowd
I don't really see a benefit here, you're just over-complicating it and trying to make it flashy which is completely pointless. A direct connection to the database is fine.Quote:
Originally Posted by ovflowd
The use of Bootstrap is getting a bit boring now. Yes it is an excellent framework for front-end work but at least do something different. Maybe a genuine material design front-end or Semantic UI.Quote:
Originally Posted by ovflowd
It means that the current text you wrote in your previous post is confusing me. You're claiming that Laravel was made by PhalconPHP. I guess it are just typos. Please consider clarifying a few things.Quote:
Originally Posted by ovflowd
I'm sure you mean you do not want the users to directly interact with the database. In the post you wrote that there is no connection between the web and database. However I don't really recommend it unless you are going to use a front-end framework. Using the API will slow things a lot down it's okay if you want to use it for authentication but for the rest it's overkill. It's a nice idea but the overhead and the latency will be to much.
Correct me if I'm wrong. It's really confusing at the moment.
It's an interesting concept but there are pre-existing patterns available purposely designed for scaled service distribution!Quote:
Originally Posted by ovflowd
Laravel sounds good, I'm still very new to it however Lumen also looks great as a micro framework! :cool:
Answering @NoBrain
1. I meant "PhalconPHP OR Laravel"
2. Hum.. As i said no one will have access to the Database. The Server is the endpoint of the Data. Only NHibernate will control it. This is good in terms of security, since all type of Queries and Database Changes will pass by the NHibernate. Also a Database Backup module will be implemented in Yupi. I think an API communication complicate more the process but is good for Applications. We can say about GitHub Api, a good example to handle Applications.
Also using this pattern, we can say that Users doesn't need anymore reenter in the Hotel to see their data updated. Since Control Modules of RESTapi will take care of updating the data in execution time.
Also the API will have a Log System, "Audit System", this is good to know what is happening in the Emulator. And who is doing what.
Also only the Emulator will know the Database Access. It's more security layer. Obviously if someone get the Application Token will not be able to do XSS attacks through the API, since the API is trusted only for an IP Address. Each Token works for an Endpoint.
3. doesn't was me that choice Bootrstrap, i prefer Foundation 6
Thanks for your opinion.
- - - Updated - - -
That was the point of @Francis Joseph, we can have a good scale and replication, giving all the API work for Workers/Jobs that can be replicated locally or regionally. It's a hard concept, but thinking as CDN, or better, as a self-scalable/replicable environment, that will no impact the In-Game. But yes, in terms of sockets, we will have the API requests + Client connections. But if coded in a good way, this will not impact so hard in the Emulator.Quote:
Originally Posted by CodeDragon
- - - Updated - - -
Observation: @CodeDragon i updated the comment changing "of" to "or"
Considering you're using Laravel, which is used in enterprise applications by A LOT of companies, the security point you made is irrelevant. Laravel automatically filters queries, provides protection against a range of attacks and is generally excellent all around (in terms of security). It's very very difficult to exploit unless the developer is an idiot or if you do raw queries.Quote:
Originally Posted by ovflowd
Why don't you just set-up the permissions in the database itself by using an installer that sets them up correctly? This might become an issue on a shared hosting but I assume no one is going to use a shared webhosting to host their cms.Quote:
Originally Posted by ovflowd
As for database replication this also exists in almost all SQL servers. You really don't need to make it super complex. Just go with the bare bones by protecting the tables with permissions. That's a lot easier and faster to configure then writing a whole API.
Good point @NoBrain, i never used frameworks such Laravel or Phalcon, a friend of mine that works at Google, said Phalcon is great.
In all my works i use specific frameworks coded by me for the specific thing. I don't like a lot Frameworks, i prefer using some libraries and my code.
But the question isn't only about Queries, but is about providing a Full API.
@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.Quote:
Originally Posted by ovflowd
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.Quote:
Originally Posted by CodeDragon
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.
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 shit and you redo everything.Quote:
Originally Posted by ovflowd
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.Quote:
Originally Posted by maritnmine
In that case, make the model code a separate library you can re-use in your API module.Quote:
Originally Posted by ovflowd
Yupi is actually made in this way. We have separated modules working as Service.Quote:
Originally Posted by maritnmine
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?Quote:
Originally Posted by ovflowd
Wasn't me. Was the Main Developer (Commiter) of Yupi Felix (Thedoct0r11)Quote:
Originally Posted by maritnmine
Hey guys!
I added Documentation things directly with Swagger Update.
Check now the Yupi Emulator documentation here: Swagger UI
Any "updates" on the cms made by kylon? (or did he already give up again x.x)
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.
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
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.
- - - Updated - - -
Observation.: KISSMVC it's outdated.
- - - Updated - - -
Observation.: Most thing that eat disk space are images and javascript.
CMS would be zero JavaScript. And zero Images.
No JS and no Images?
Welcome to 1999!
No Need of it.Quote:
Originally Posted by iExit
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.
Quote:
Originally Posted by ovflowd
Well, I'm sure you know what you're talking about....Quote:
Originally Posted by ovflowd
You do not use SVG as a primary format for images on a website.Quote:
Originally Posted by ovflowd
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.
Always consider the user interface and the user's experience.Quote:
Originally Posted by ovflowd
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.
Please, oh please, do your research before starting a project.Quote:
Originally Posted by ovflowd
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.
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 fuck 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
@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 systemQuote:
Originally Posted by ovflowd
The system ever exists. How you can point flaws?Quote:
Originally Posted by LeChris
- - - Updated - - -
Sometimes i prefer say random things.Quote:
Originally Posted by Joopie
You know about REST? Than why are you using it on such a retarded scale, and not actually using frameworks in the ways intended and ways to be secure. End users don't trust Yupi because it's made by the developers of Azure, which was more cancerous than the Spanish Butterfly edits.
(Much love for Mikkel, on the other hand and the other main contributor to it)
Why? This makes you sound like a creep, just saying :P:
https://github.com/sant0ro/Yupi
http://i.imgur.com/DAUXtVD.png
It's to make fun. But you're right will change it.Quote:
Originally Posted by Quackster
- - - Updated - - -
@Quackster, updated it.
- - - Updated - - -
Answering to @iExit about JavaScript: You Might Not Need JavaScript
I'm sure we all can agree on you with the context of that article. Yet I think the title of that article is wrong and misleading.Quote:
Originally Posted by ovflowd
The reason I find this is because that JavaScript can do so much more then just, like that article is saying, do UI components. Yet I still believe that this isn't what @iExit was referring too. He was talking about "single page app/website/application". This is done by utilizing JavaScript. And there is so much that you couldn't do without JavaScript.
I agree with you. JavaScript do a lot more. But understand my point. It's a simple CMS, and only those UI components that CSS 3 offers, we will need. Like opening article in a "reveal modal", or "light boxes", or dismiss alerts.Quote:
Originally Posted by Joopie
I also agree that the point of @iExit was another. But i'm trying to also say which was my point. I use JavaScript in my daily tasks.
Thanks for your opinion @Joopie. I really apologize myself because my lack of updates for this project. I wish the developers return soon to it. Maybe in my vacations i help with this since i will try to do my first emulator good coded. Since Azure Emulator was my biggest mistake, and an arrogant act.
I hope people still are interested on this, since i love coding and helping people.
Best wishes,
Claudio
Hi people, sorry about the lack of updates.
My semester it's starting to end.
I did the deploy of Yupi Emulator in this scenario:
OS X Sierra + MariaDB 10 + Xamarin Studio + Mono. Build was successful. Only fixing some things in Deploy of Database. I think it's the strict configuration of MySQL.
I will start to develop and continue the things. My priority by now it's the RESTapi.
@BurakDev will continue with the Security part when he got time to do this :happymod:
@kylon it's doing the CMS but waiting for the conclusion of the RESTapi, cause that i'm doing priority to it.
Big hugs,
Uncle Claudio
I'm glad to say that Yupi it's back!
We're commiting again!
More updates in some minutes.
Good emulator ... I look forward to the results
Link me to your camera api please <3Quote:
Originally Posted by saamus
Make Habbo emulators great again!
#pray4yupi
#coming2020
Wonder what new features will come...if there will be any special.
Tho i look forward for this #pray4yupi:love:
Hahahahah, thanks @iExit, i hope you're not being irony.Quote:
Originally Posted by iExit
I will write here the commit changes. Are many.
- - - Updated - - -
Thanks @Articuz, #pray4yupi. I will write here the Commit Changes.Quote:
Originally Posted by Articuz
- - - Updated - - -
Commited to Yupi
Actually Felix (thedoct0r11) is commitigin in his fork, and i'm merging all the changes when a sufficient amount of commits happens.
Actually he is improving the Language System, the Yupi.Domain (Models), the WebModule, Coverage, Tests, and the CORE as itself. Soon he will continue commit the Emulator Features.
One of the biggest reasons of we're not commiting features NOW, it's because we want to create a stable CORE. Different of the actual emulators. Yupi will be scalabe, stable and dynamic.