Virtual File System ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Virtual File System ?

julien
is Asciidoc java integration able to integrate with a Virtual File System for resolving resources such as inclusion ?

Intellij works with a VFS and does not provide physical files.
Reply | Threaded
Open this post in threaded view
|

Re: Virtual File System ?

mojavelinux
Administrator

We could certainly do it, though I don't think it's capable today. If you point to a strategy for doing VFS, I'm sure Alex and others interested in hacking on the java integration would be eager to add this feature. Naturally, if this warrant changes in Asciidoctor core, we can get that updated as well.

-Dan

On Jul 25, 2013 2:06 AM, "julien [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
is Asciidoc java integration able to integrate with a Virtual File System for resolving resources such as inclusion ?

Intellij works with a VFS and does not provide physical files.


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Virtual-File-System-tp387.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: Virtual File System ?

asotobu
In reply to this post by julien
Hi Julien,

I am Alex, the leader of Asciidoctor-Java-Integration project, I think it could be interesting adding support for VFS, I have never worked with it, so it is something new, but of course we can talk about it and integrate it. On the other side if you are thinking about supporting VFS inside AsciiDoc format (for example for using in include keyword) I think it would require some changes on Asciidoctor gem, or in next release developing an extension to resolve VFS locations.

Well if you need anything from Asciidoctor-java-integration project feel free to ask it, and of course we are in touch for VFS support.

Alex.
Reply | Threaded
Open this post in threaded view
|

Re: Virtual File System ?

julien
In reply to this post by julien
Replying to myself since I can't reply to both Dan and Alex at the same time :-)

Now, the IDE plugin would have to locate all relevant adoc files and copy them to a temp directory before doing a render. It can be resource consuming for the IDE and also could raise other issues.

With a basic resource resolution (like "Reader resolveResource(String uri)" ), Asciidoc can decouple the identifier of a resource from the actual content of this resource allowing an IDE plugin to delegate to the IDE filesystem. (note that would also ease integration in content management system, ServletContext#getResourceAsStream(), etc...).
Reply | Threaded
Open this post in threaded view
|

Re: Virtual File System ?

asotobu
I think I am missing something about VFS:

If the problem is resolving the document that is going to be rendered (in most cases transform an URI to a Reader instance), Asciidoctor-java-integration project offers a method where you can pass a Reader object, so I think that this transformation should be managed externally from asciidoctor-java-integration project, resolveResource method it is something specific of each system.

If the problem is with include keyword then from java part we cannot do anything.

Again maybe I am missing something and some changes on java part should be done.

Alex.
Reply | Threaded
Open this post in threaded view
|

Re: Virtual File System ?

LightGuardjp
Yeah, I can see includes being a little bit of a problem. Dan, sounds like we're starting to build up the need for an SPI in core.

If we had an SPI from core where it calls out to something to retrieve the referenced resources we'd be good. Of course we'd need Language X to Ruby capabilities, but with JRuby that's hardly a problem.

This also presents a possible performance hit, but it would be minor and we'd gain quit a bit from it.


On Thu, Jul 25, 2013 at 10:13 AM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:
I think I am missing something about VFS:

If the problem is resolving the document that is going to be rendered (in most cases transform an URI to a Reader instance), Asciidoctor-java-integration project offers a method where you can pass a Reader object, so I think that this transformation should be managed externally from asciidoctor-java-integration project, resolveResource method it is something specific of each system.

If the problem is with include keyword then from java part we cannot do anything.

Again maybe I am missing something and some changes on java part should be done.

Alex.


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Virtual-File-System-tp387p394.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML



--
Reply | Threaded
Open this post in threaded view
|

Re: Virtual File System ?

julien
In reply to this post by asotobu
I haven't been clear enough. The resolver is useful when Asciidoc process includes. At the moment it seems that processing an include resolves to the file designed file on the filesystem (likely resolving to a java.io.FIle with jruby). In case of Intellij, it would be resolved using the Intellij VFS.
Reply | Threaded
Open this post in threaded view
|

Re: Virtual File System ?

LightGuardjp
Yes, I understood this, sorry if my response didn't seem to indicate this. What I'm proposing is an SPI to allow you to create different resolvers and plug them into Asciidoctor core. That way it wouldn't have to be a file. As long as what Asciidoctor receives from this chain, hierarchy, whatever will resolve and return that resource in a way that Ruby can read it we're good. You'd need to write to whatever it is so that you can 

* register it with Asciidoctor
* have it return something that Asciidoctor can use

We could use this to resolve Files, URIs, VFS entries, bits stored in a database or other datastore.


On Thu, Jul 25, 2013 at 2:27 PM, julien [via Asciidoctor :: Discussion] <[hidden email]> wrote:
I haven't been clear enough. The resolver is useful when Asciidoc process includes. At the moment it seems that processing an include resolves to the file designed file on the filesystem (likely resolving to a java.io.FIle with jruby). In case of Intellij, it would be resolved using the Intellij VFS.


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Virtual-File-System-tp387p399.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML



--
Reply | Threaded
Open this post in threaded view
|

Re: Virtual File System ?

julien
can you schedule it in Asciidoctor roadmap ?
Reply | Threaded
Open this post in threaded view
|

Re: Virtual File System ?

asotobu
If it is inplemented as Jason said, then I will implement in Java part. We have been playing with Dan with something similar for extensions, so for this case an interface would be created, so resolvers could be written in Ruby or Java

El dijous 25 de juliol de 2013, julien [via Asciidoctor :: Discussion] ha escrit:
can you schedule it in Asciidoctor roadmap ?


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Virtual-File-System-tp387p402.html
To unsubscribe from Virtual File System ?, click here.
NAML


--
Enviat amb Gmail Mobile
Reply | Threaded
Open this post in threaded view
|

Re: Virtual File System ?

LightGuardjp
Dan is pretty much the owner and lead for the project. I'll have to defer to him for scheduling and design decisions.


On Thu, Jul 25, 2013 at 3:13 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote:
If it is inplemented as Jason said, then I will implement in Java part. We have been playing with Dan with something similar for extensions, so for this case an interface would be created, so resolvers could be written in Ruby or Java

El dijous 25 de juliol de 2013, julien [via Asciidoctor :: Discussion] ha escrit:
can you schedule it in Asciidoctor roadmap ?


If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Virtual-File-System-tp387p402.html
To unsubscribe from Virtual File System ?, click here.
NAML


--
Enviat amb Gmail Mobile



If you reply to this email, your message will be added to the discussion below:
http://discuss.asciidoctor.org/Virtual-File-System-tp387p403.html
To start a new topic under Asciidoctor :: Discussion, email [hidden email]
To unsubscribe from Asciidoctor :: Discussion, click here.
NAML



--
Reply | Threaded
Open this post in threaded view
|

Re: Virtual File System ?

julien
Actually if someone can come up with a small specification for this work in the Ruby part (a doc that describes what to do at high level), I'm willing to implement it.

Although I don't know the Ruby language at all, it would be a good incentive and opportunity for me to learn it.

let me know if that is feasible.