RejectedSoftware Forums

Sign up

What are the future plans about vibelog?

Hi Sönke:

I recently met ghost blog engine, and was intrigued by its simplicity. But I prefer much more on vibe.d/D than nodejs.

I found that your vibelog project is also having a similar simplicity, so I wanted to use it as my blog engine. I'm learning to use vibe.d and D, so picking up this little project is very nice.

But by checking out the project I found that some of the things are lacking for a personal blog engine as compared to ghost:

  1. no style. I would be nice to have a default style.
  2. sparse documentation.
  3. no binary download.
  4. dependency on mongodb. I'd also like that posts could be saved into files (like jekyll & github blogs) or simple dbs like sqlite.
  5. syntax highlighting and other tools are not incorporated

I know the situation may due to you are focused on vibe.d/dub and other higher priorities, so I'd like to contribute to it.
I've add bootstrap and a theme similar to ghost the other day, you can view a demo on http://zhaopuming.cn

What is your vision of this project? Do you want it to become a useful blog tool for not only your vibe.d site, but also a general purpose blog engine?

Here is what come into my mind first:

  1. bootstrap based themes. It should have a default theme, and people could contribute their themes. By doing that I'd like to change the class names and html styles into a more bootstrap flavored one.

  2. A better editor. I love markdown, so it would be nice to have a markdown editor with live preview. similar to stackedit

  3. make the database layer independent on databases. First I'd like to add plain .md file support.

  4. Move more logic into the front end. (Yes, ajax and all those crazy javascript stuff)

What do you think? I'd like that it stays within the line of vibelog, so I don't want to do a fork that would go too far away.

If you pre-approve what should be done first, I'll start doing it.

I think it has the same potential as ghost/nodejs. Or even wordpress.

Re: What are the future plans about vibelog?

On Wed, 12 Mar 2014 10:11:44 GMT, zhaopuming wrote:

  1. A better editor. I love markdown, so it would be nice to have a markdown editor with live preview. similar to stackedit

  2. make the database layer independent on databases. First I'd like to add plain .md file support.

  3. Move more logic into the front end. (Yes, ajax and all those crazy javascript stuff)

What do you think? I'd like that it stays within the line of vibelog, so I don't want to do a fork that would go too far away.

If you pre-approve what should be done first, I'll start doing it.

I think it has the same potential as ghost/nodejs. Or even wordpress.

I think the ideal would be a blog engine that uses TinyMCE or CKEditor for its HTML posts. There's quite a lot of stuff missing before then like js minification, cache engines, common library hooks and storage for creating components like "building blocks" to add template management, typography, switching editors, administrative modules, etc. without breaking anything

I've been building a backbone for a web framework that could host such a thing (it's called spee-d, it uses cache-d as a hierarchical distributed cache for cloud integration) and, so blogs are my first priority but about 1 month away from being developed right now.

Re: What are the future plans about vibelog?

On Wed, 12 Mar 2014 13:50:28 GMT, Etienne Cimon wrote:

On Wed, 12 Mar 2014 10:11:44 GMT, zhaopuming wrote:

  1. A better editor. I love markdown, so it would be nice to have a markdown editor with live preview. similar to stackedit

  2. make the database layer independent on databases. First I'd like to add plain .md file support.

  3. Move more logic into the front end. (Yes, ajax and all those crazy javascript stuff)

What do you think? I'd like that it stays within the line of vibelog, so I don't want to do a fork that would go too far away.

If you pre-approve what should be done first, I'll start doing it.

I think it has the same potential as ghost/nodejs. Or even wordpress.

I think the ideal would be a blog engine that uses TinyMCE or CKEditor for its HTML posts.

Do these support markdown with live preview like stackedit ?

There's quite a lot of stuff missing before then like js minification, cache engines, common library hooks and storage for creating components like "building blocks" to add template management, typography, switching editors, administrative modules, etc. without breaking anything

Yes, there are a lot to do. But first we can create a minified simple version of ghost, which has already proven to be useful.

I've been building a backbone for a web framework that could host such a thing (it's called spee-d, it uses cache-d as a hierarchical distributed cache for cloud integration) and, so blogs are my first priority but about 1 month away from being developed right now.

Would like to see, is it on github? or http://code.dlang.org?

I'm also starting to think about the plan. For now I'll just do some small tweaks to see what would be good.

Re: What are the future plans about vibelog?

On Wed, 12 Mar 2014 15:15:15 GMT, zhaopuming wrote:

Yes, there are a lot to do. But first we can create a minified simple version of ghost, which has already proven to be useful.

Yes, any library that doesn't have hard dependencies on certain storage devices is nice, but can also be changed later

Would like to see, is it on github? or http://code.dlang.org?

I'm also starting to think about the plan. For now I'll just do some small tweaks to see what would be good.

https://github.com/globecsys/cache.d
https://github.com/globecsys/spee.d
https://github.com/globecsys/config.d

I started writing spee.d a little before cache.d, I was going to put config and memory modules inside the web framework but I thought to make it more modular.

Config.d serves as compile-time variable provider to change the database or serialization method throughout the library chain.

Cache.d serves as a memory storage (with timers for saving to HDD) which is thread-local, it uses the Redis API for familiarity and I intend on making a legacy TCP handler that fits with Redis db tools, but I'm also making this into an elastic cache that fetches an IP from the configuration file and downloads its peers, to connect to them through websocket and extend the network (for automatic replication and clustering). This brings the data closer to computation (processor-local data is clustered vs computer-local data replicated).

So if you do auto db = DistCache("*"); auto data = db.get("someKey");, you're falling back on the network to get your data if you can't find it locally. But you also have LocalCache and RemoteCache to get data specifically from home or elsewhere.

Note that the pubsub model still applies, so this allows some pretty sweet callbacks and RPC

Spee.d is actually what combines the config and cache to build libraries. The HTTPRouter is going to be rewritten to PubSubRouter, and every library subscribes its functions through UDA and when a publish is sent they're found/called using compile-time named regex matching. It's a little hard to explain though.

e.g.

@subscribe("GET", "users/(?P<name>\w+)/(?P<id>\d+)/")
void users(string name, long id){
	print("this goes to the web OutputStream");
}

So the router is just calling a localdb.publish(method, path), and all the libraries that subscribed their methods and match are potentially called. This is really useful for data that can't be found in the cache

e.g.

@subscribe("MISS", "(?P<session_id>\w+)/Name")
void setNameFromSessId(string session_id){
	This.session["Name"] = ...
}

It's still a bunch of nice ideas. The database tools for spee.d will be HibernateD to create the SQL query and then it'll push it into any SQL library.

e.g.

auto sql = This.queryBuilder("users.id FROM users WHERE orders.qty > ?", qty);
This.query(sql);

This query could end up having 10 different joins but HibernateD figures it all out. The object schemas are all going to be compile-time stuff in Config.d, so libraries can also extend these schemas.

Still quite a bit of work to do before I get there XD

Re: What are the future plans about vibelog?

Hi Puming,

this all sounds like good points to move the project forward and I would very much appreciate any of your contributions. Indeed the only reasons why I didn't commence to go further with this yet, is that so far it was good enough for its current purpose and that the other projects drain all my development resources. But since recently I have reserved some hours per week for various open source projects, so I can try and help a bit here and there (but some others, like DDOX and vibenews unfortunately also need to fit into that schedule).

To your suggestions, I would add one additional thing that has a relatively high priority: The comment system needs to get a spam filter (e.g. using antispam) and a better editing UI, as well as proper e-mail notifications for commenters. Such a comment system could then also be nicely reused for the new Phobos documentation instead of Disqus.

But by checking out the project I found that some of the things are lacking for a personal blog engine as compared to ghost:

  1. no style. I would be nice to have a default style.

Agreed, this is probably the most notable thing that is currently missing. A possibility to switch between different styles using the management page would also be nice.

  1. sparse documentation.
  2. no binary download.

We finally have a good CI server running, which I could use now to automatically upload binaries for various platforms (similar to DUB). This is something that I could start to tackle over the next weeks, possibly together with a little home page (e.g. at vibelog.vibed.org).

  1. dependency on mongodb. I'd also like that posts could be saved into files (like jekyll & github blogs) or simple dbs like sqlite.

Sounds like a good idea. Together with this it would also be good to use the userman library, which is also used for the DUB registry and for the forum, to manage user credentials and make that DB engine independent as well. This would be something that I could look into as well.

  1. syntax highlighting and other tools are not incorporated

What I'm using now is JS based syntax highlighting with google-code-prettify. This requires a little text filter to be installed (blogSettings.textFilters ~= html => html.replace("<code><pre>", "<code><pre class=\"prettyprint\">")), but Brian Schott's planned std.d.lexer looks like it would be perfect for server side highlighting and I'm also planning to incorporate that for DDOX and the new Phobos documentation, so that would be a low hanging fruit.

I know the situation may due to you are focused on vibe.d/dub and other higher priorities, so I'd like to contribute to it.
I've add bootstrap and a theme similar to ghost the other day, you can view a demo on http://zhaopuming.cn

Looks very nice and clean. If you want to contribute this or a similar variant, I would be happy to add it.

What is your vision of this project? Do you want it to become a useful blog tool for not only your vibe.d site, but also a general purpose blog engine?

In fact, it's already used for a couple of small blogs and while there will always be a strong focus on the embeddable property, I'd definitely like to improve it as a stand alone system, too.

Here is what come into my mind first:

  1. bootstrap based themes. It should have a default theme, and people could contribute their themes. By doing that I'd like to change the class names and html styles into a more bootstrap flavored one.

I'd be OK with that, I'll have to adjust a couple of styles, but it's always good to settle for a kind of standard.

  1. A better editor. I love markdown, so it would be nice to have a markdown editor with live preview. similar to stackedit

Good point. That should be very easy to implement and would especially help a lot for people who are not fluent with Markdown. This is also a good idea for writing forum posts, at least on large screens.

  1. make the database layer independent on databases. First I'd like to add plain .md file support.

  2. Move more logic into the front end. (Yes, ajax and all those crazy javascript stuff)

Sounds good, it should just still stay fully functional with JS disabled. But there are definitely a lot of places where the UI could greatly profit from some JS and AJAX.

What do you think? I'd like that it stays within the line of vibelog, so I don't want to do a fork that would go too far away.

Looks like all of your ideas are very much in line with mine, so except for the DB stuff, which I'd like to tackle in conjunction with the userman modifications, everything of the mentioned things should be good to go.

If you pre-approve what should be done first, I'll start doing it.

I think it has the same potential as ghost/nodejs. Or even wordpress.

Still a lot of work ahead, but it would definitely be nice to have something for D in that area. Especially when we can devote some time to do some serious performance tuning, it could have a good buzz factor.

Re: What are the future plans about vibelog?

To your suggestions, I would add one additional thing that has a relatively high priority: The comment system needs to get a spam filter (e.g. using antispam) and a better editing UI, as well as proper e-mail notifications for commenters. Such a comment system could then also be nicely reused for the new Phobos documentation instead of Disqus.

For comment system, I'd suggest that comments on phobos docs should not only be put at the bottom, but also inline with each module/function/class. We could put an icon at each function to popup its comments. It is more like taking notes(and discuss) with each paragraph.

For the antispam feature, I have no experience on that, so I'd have to learn about it :-)

For an editing UI, I suggest we combine markdown-editor and vim-bidings or emacs-bidings when JS is enabled, and use plain UI & button to preview when JS is disabled.

Also StackOverflow's PageDown would be considered

But by checking out the project I found that some of the things are lacking for a personal blog engine as compared to ghost:

  1. no style. I would be nice to have a default style.

Agreed, this is probably the most notable thing that is currently missing. A possibility to switch between different styles using the management page would also be nice.

See ghost's marketplace, what if we change the class names in the UI to be compatible with ghost's themes? That way people could potentially just use that market to use what themes they like.

  1. sparse documentation.
  2. no binary download.

We finally have a good CI server running, which I could use now to automatically upload binaries for various platforms (similar to DUB). This is something that I could start to tackle over the next weeks, possibly together with a little home page (e.g. at vibelog.vibed.org).

Looking forward to that.

  1. dependency on mongodb. I'd also like that posts could be saved into files (like jekyll & github blogs) or simple dbs like sqlite.

Sounds like a good idea. Together with this it would also be good to use the userman library, which is also used for the DUB registry and for the forum, to manage user credentials and make that DB engine independent as well. This would be something that I could look into as well.

OK :-)

another thing is Etienne Cimon suggested to use HibernateD, what is your comment on that?

  1. syntax highlighting and other tools are not incorporated

What I'm using now is JS based syntax highlighting with google-code-prettify. This requires a little text filter to be installed (blogSettings.textFilters ~= html => html.replace("<code><pre>", "<code><pre class=\"prettyprint\">")), but Brian Schott's planned std.d.lexer looks like it would be perfect for server side highlighting and I'm also planning to incorporate that for DDOX and the new Phobos documentation, so that would be a low hanging fruit.

Yes, I was planning to use google-code-prettify also as I noted you were using it in vibe.d's blog.

I know the situation may due to you are focused on vibe.d/dub and other higher priorities, so I'd like to contribute to it.
I've add bootstrap and a theme similar to ghost the other day, you can view a demo on http://zhaopuming.cn

Looks very nice and clean. If you want to contribute this or a similar variant, I would be happy to add it.

I'll complete it in my fork, and later create a pull request

What is your vision of this project? Do you want it to become a useful blog tool for not only your vibe.d site, but also a general purpose blog engine?

In fact, it's already used for a couple of small blogs and while there will always be a strong focus on the embeddable property, I'd definitely like to improve it as a stand alone system, too.

Glad to hear that :-)

Here is what come into my mind first:

  1. bootstrap based themes. It should have a default theme, and people could contribute their themes. By doing that I'd like to change the class names and html styles into a more bootstrap flavored one.

I'd be OK with that, I'll have to adjust a couple of styles, but it's always good to settle for a kind of standard.

  1. A better editor. I love markdown, so it would be nice to have a markdown editor with live preview. similar to stackedit

Good point. That should be very easy to implement and would especially help a lot for people who are not fluent with Markdown. This is also a good idea for writing forum posts, at least on large screens.

  1. make the database layer independent on databases. First I'd like to add plain .md file support.

  2. Move more logic into the front end. (Yes, ajax and all those crazy javascript stuff)

Sounds good, it should just still stay fully functional with JS disabled. But there are definitely a lot of places where the UI could greatly profit from some JS and AJAX.

What do you think? I'd like that it stays within the line of vibelog, so I don't want to do a fork that would go too far away.

Looks like all of your ideas are very much in line with mine, so except for the DB stuff, which I'd like to tackle in conjunction with the userman modifications, everything of the mentioned things should be good to go.

OK :-)

If you pre-approve what should be done first, I'll start doing it.

I think it has the same potential as ghost/nodejs. Or even wordpress.

Still a lot of work ahead, but it would definitely be nice to have something for D in that area. Especially when we can devote some time to do some serious performance tuning, it could have a good buzz factor.

I came to this plan regarding your response:

  1. The the css and themes
  2. build a live editor
  3. See if I can help with your work in userman and DB stuff.

Re: What are the future plans about vibelog?

On Wed, 12 Mar 2014 15:34:59 GMT, Etienne Cimon wrote:

On Wed, 12 Mar 2014 15:15:15 GMT, zhaopuming wrote:

Yes, there are a lot to do. But first we can create a minified simple version of ghost, which has already proven to be useful.

Yes, any library that doesn't have hard dependencies on certain storage devices is nice, but can also be changed later

Would like to see, is it on github? or http://code.dlang.org?

I'm also starting to think about the plan. For now I'll just do some small tweaks to see what would be good.

https://github.com/globecsys/cache.d
https://github.com/globecsys/spee.d
https://github.com/globecsys/config.d

I started writing spee.d a little before cache.d, I was going to put config and memory modules inside the web framework but I thought to make it more modular.

Config.d serves as compile-time variable provider to change the database or serialization method throughout the library chain.

Cache.d serves as a memory storage (with timers for saving to HDD) which is thread-local, it uses the Redis API for familiarity and I intend on making a legacy TCP handler that fits with Redis db tools, but I'm also making this into an elastic cache that fetches an IP from the configuration file and downloads its peers, to connect to them through websocket and extend the network (for automatic replication and clustering). This brings the data closer to computation (processor-local data is clustered vs computer-local data replicated).

So if you do auto db = DistCache("*"); auto data = db.get("someKey");, you're falling back on the network to get your data if you can't find it locally. But you also have LocalCache and RemoteCache to get data specifically from home or elsewhere.

Note that the pubsub model still applies, so this allows some pretty sweet callbacks and RPC

I like this idea :-) Added your repos to my discovery and learning list

Spee.d is actually what combines the config and cache to build libraries. The HTTPRouter is going to be rewritten to PubSubRouter, and every library subscribes its functions through UDA and when a publish is sent they're found/called using compile-time named regex matching. It's a little hard to explain though.

e.g.

@subscribe("GET", "users/(?P<name>\w+)/(?P<id>\d+)/")
void users(string name, long id){
	print("this goes to the web OutputStream");
}

So the router is just calling a localdb.publish(method, path), and all the libraries that subscribed their methods and match are potentially called. This is really useful for data that can't be found in the cache

So the router is calling multiple functions simaltaneously? what about the results? does it wait for all results?

e.g.

@subscribe("MISS", "(?P<session_id>\w+)/Name")
void setNameFromSessId(string session_id){
	This.session["Name"] = ...
}

It's still a bunch of nice ideas. The database tools for spee.d will be HibernateD to create the SQL query and then it'll push it into any SQL library.

e.g.

auto sql = This.queryBuilder("users.id FROM users WHERE orders.qty > ?", qty);
This.query(sql);

This query could end up having 10 different joins but HibernateD figures it all out. The object schemas are all going to be compile-time stuff in Config.d, so libraries can also extend these schemas.

I was thinking about a DAO with struct/function way of abstracting the DB stuff because what I really wanted to use is plain files (similar to jekyll).

What do you think ?

Still quite a bit of work to do before I get there XD

What is your plan for the blog engine? are you going to do vibelog or create a new project? I wish we can join forces and then I would be able to learn from all your guys :-)