New proposal for a set of links on the front page
Lassi Kortela
(28 Dec 2020 14:31 UTC)
|
Re: New proposal for a set of links on the front page
Arthur A. Gleckler
(28 Dec 2020 16:25 UTC)
|
Re: New proposal for a set of links on the front page
Lassi Kortela
(28 Dec 2020 17:01 UTC)
|
Re: New proposal for a set of links on the front page
Arthur A. Gleckler
(28 Dec 2020 18:06 UTC)
|
Re: New proposal for a set of links on the front page
Jakub T. Jankiewicz
(28 Dec 2020 19:19 UTC)
|
Re: New proposal for a set of links on the front page
Marc Feeley
(28 Dec 2020 22:05 UTC)
|
Re: New proposal for a set of links on the front page
Lassi Kortela
(28 Dec 2020 22:49 UTC)
|
Re: New proposal for a set of links on the front page
Jakub T. Jankiewicz
(29 Dec 2020 08:42 UTC)
|
Details on privacy and tracking
Lassi Kortela
(29 Dec 2020 11:41 UTC)
|
Re: Details on privacy and tracking
Lassi Kortela
(29 Dec 2020 11:43 UTC)
|
Re: Details on privacy and tracking
Jakub T. Jankiewicz
(29 Dec 2020 12:49 UTC)
|
Re: Details on privacy and tracking
Lassi Kortela
(29 Dec 2020 13:06 UTC)
|
Re: Details on privacy and tracking
Jakub T. Jankiewicz
(29 Dec 2020 16:15 UTC)
|
Re: Details on privacy and tracking
Lassi Kortela
(29 Dec 2020 16:40 UTC)
|
Gambit and other JavaScript Schemes
Lassi Kortela
(29 Dec 2020 12:11 UTC)
|
Re: Gambit and other JavaScript Schemes
Lassi Kortela
(29 Dec 2020 12:17 UTC)
|
Re: Gambit and other JavaScript Schemes
Jakub T. Jankiewicz
(29 Dec 2020 12:55 UTC)
|
Re: Gambit and other JavaScript Schemes
Lassi Kortela
(29 Dec 2020 13:14 UTC)
|
Re: New proposal for a set of links on the front page
Marc Feeley
(29 Dec 2020 14:38 UTC)
|
Aspects of JavaScript Schemes
Lassi Kortela
(29 Dec 2020 14:55 UTC)
|
Re: Aspects of JavaScript Schemes
Marc Feeley
(29 Dec 2020 15:11 UTC)
|
Re: Aspects of JavaScript Schemes
Lassi Kortela
(29 Dec 2020 15:27 UTC)
|
Re: Aspects of JavaScript Schemes
Jakub T. Jankiewicz
(29 Dec 2020 16:54 UTC)
|
Re: Aspects of JavaScript Schemes
Marc Feeley
(29 Dec 2020 21:35 UTC)
|
Re: Aspects of JavaScript Schemes
Jakub T. Jankiewicz
(29 Dec 2020 22:33 UTC)
|
Re: Aspects of JavaScript Schemes
Jakub T. Jankiewicz
(29 Dec 2020 16:36 UTC)
|
Re: New proposal for a set of links on the front page
Lassi Kortela
(29 Dec 2020 15:04 UTC)
|
Re: New proposal for a set of links on the front page
Arthur A. Gleckler
(29 Dec 2020 16:19 UTC)
|
Re: New proposal for a set of links on the front page
Lassi Kortela
(29 Dec 2020 16:30 UTC)
|
Re: New proposal for a set of links on the front page
Arthur A. Gleckler
(29 Dec 2020 16:38 UTC)
|
Re: New proposal for a set of links on the front page
Lassi Kortela
(29 Dec 2020 16:46 UTC)
|
lips.scheme.org implementation subdomain
Lassi Kortela
(28 Dec 2020 22:28 UTC)
|
Re: lips.scheme.org implementation subdomain
Jakub T. Jankiewicz
(29 Dec 2020 08:04 UTC)
|
Hosting and SEO for Scheme implementations
Lassi Kortela
(29 Dec 2020 12:35 UTC)
|
Re: Hosting and SEO for Scheme implementations
Lassi Kortela
(29 Dec 2020 12:43 UTC)
|
Re: Hosting and SEO for Scheme implementations Jakub T. Jankiewicz (29 Dec 2020 13:20 UTC)
|
Re: Hosting and SEO for Scheme implementations
Lassi Kortela
(29 Dec 2020 13:45 UTC)
|
Re: Hosting and SEO for Scheme implementations
Jakub T. Jankiewicz
(29 Dec 2020 17:13 UTC)
|
Re: Hosting and SEO for Scheme implementations
Lassi Kortela
(29 Dec 2020 17:43 UTC)
|
Re: Hosting and SEO for Scheme implementations
Jakub T. Jankiewicz
(29 Dec 2020 18:34 UTC)
|
Re: Hosting and SEO for Scheme implementations
Lassi Kortela
(29 Dec 2020 18:46 UTC)
|
Re: Hosting and SEO for Scheme implementations
Arthur A. Gleckler
(29 Dec 2020 16:28 UTC)
|
Re: Hosting and SEO for Scheme implementations
Lassi Kortela
(29 Dec 2020 16:35 UTC)
|
Re: Hosting and SEO for Scheme implementations
Jakub T. Jankiewicz
(29 Dec 2020 17:21 UTC)
|
Re: Hosting and SEO for Scheme implementations
Lassi Kortela
(29 Dec 2020 18:15 UTC)
|
Re: New proposal for a set of links on the front page
Jakub T. Jankiewicz
(29 Dec 2020 20:05 UTC)
|
Scheme tutorials
Lassi Kortela
(29 Dec 2020 20:16 UTC)
|
Re: Scheme tutorials
Jakub T. Jankiewicz
(29 Dec 2020 21:44 UTC)
|
On Tue, 29 Dec 2020 14:34:52 +0200 Lassi Kortela <xxxxxx@lassi.io> wrote: > > If I would need to setup server then it's useless to me, I wanted > > something that would not require to pay for anything, so the service will > > not be lost after my death. I wanted something that will still exists > > after I'm dead. > > We should think about offering hosting to Scheme implementations. Most > implementations' sites are reasonably low-traffic and lightweight, so a > cheap server with nginx could probably handle many sites. > > We currently have only one server (one of the cheapest reputable > commercial VPS). It currently only hosts "community" sites (i.e. sites > that volunteers are making to cover all of Scheme, not just one > implementation). > > Arthur, do you think we could we add implementation sites to that server > or is there a point to separating implementation sites to their own servers? > > I think the charter of Scheme.org doesn't need to say how the servers > are handled, but in practice, it would be good to think of a clear policy. > > Would implementers trust having their sites on the same server as > community sites? It would be awesome if lips could be hosted on your sever, but nice thing about GitHub pages is that I've got Jekyll build on each commit for free. In order to connect git repo on GitHub with your server I would probably need something more then just static hosting. I can check if I can use GitHub actions to just upload static files to different server and build the files using GitHub actions. I would need SSH access probably, but simple ftp would also probably be fine. But I'm not 100% sure if simple hosting would work with GitHub actions, since I recently watched video about GitHub actions and the guy used VPS with root access to set this up. One note: I have tracking on lips.js.org right now, it use my private instance of Piwik (Matomo) but I don't use the data in any way, I just visit from time to time dashboard and see how many visitors I've got, that + Google Webmaster tools help be improve the SEO of the site. With my Piwk I can enable every possible privacy option, so it make sure that it don't store any sensitive data. Maybe I will switch to something lighter since Piwik is very heavy and sometimes overload my cheap shared hosting with too many php processes. > > > I think that simple redirect is fine then, the problem with domain is that > > the only useful if it stick to the address. Right now those two > > implementation are kind of use useless (the domain names). If you just > > want to have same link to that implementation then setup l.scheme.org > > with url shortener would provide the same benefot. > > The point of having a subdomain for everything is on the one hand to > make Scheme.org more consistent for users and admins, and on the other > hand to entice implementations to have a presence under Scheme.org, even > if it's just a name (subdomain with redirect). > > Making a subdomain is a small hassle to implementers, and having a > simple link to an external site would be easier. My personal opinion is > that we should think of Scheme.org like a long-term investment, that > cannot succeed if we don't get people at least a little bit invested in > it as a community. There should be at least a little give-and-take, and > adding a subdomain is pretty minimal as far as investments go. This > opinion may be somewhat unpopular, especially since it makes more work > in the short term, but it seems to me like it would make sense > long-term. What do you think? > > > The only benefit I see for domain is SEO and that it looks nice. But just > > redirect is kind of pointless. > > > > But if you decide that this is how all implementations will work then I'm > > fine with just redirect. But you need to know that it's good only for > > scheme.org to organize the structure it probably will of no use for the > > implementer, because he will not get even a link to his site so it will > > not benefit SEO at all. > > Thanks. This is very good advice. So search engines consider only the > target address of the redirect, not the source address. I'm not exactly sure how this works with redirect that you have, that is more on DNS side. But with normal 301 redirect it's recommended to use it because when you change the domain and old one is indexed in Google, new one will get the same ranking, you just move the ranking from old to new domain. Even when there are links pointing to old domain. Also giving new domain that is not indexed redirect to old domain that is indexed is kind of pointless in SEO perspective. The new domain that is redirect, will probably never got indexed by Google. My domain js.org is pretty new, I only have few links and I can change everything, also I'm in process of creating new website, so it would be great if new website have new domain. and domain will have name of the language which is keyword that people search using so it would be great. One problem with js.org is that I will need to manually change all the links that I've added, to have any links to new site because js.org don't offerer redirect so I will need to setup a site that would have a link to new website. -- Jakub T. Jankiewicz, Web Developer https://jcubic.pl/me