Jump to content
IGNORED

Proposal for implemementing hyperlinks in CONFIG


Recommended Posts

I've pretty much resigned myself to the fact that I'm not going to be finding time soon to finish off the directory service for publicly-accessible FujiNet sites.  One of the issues I ran into was how the LDAP module for FUSE had some compatibility issues; I began looking into it and promptly watched as 27 million more urgent things competed for (and won) my attention.

 

However, I still believe that it's important to have a way to access more than just seven slot-defined TNFS servers directly from the FujiNet.  This is particularly true in light of the amazing progress that the Neon project is making at bringing a hypertext-style UI to networked A8s - not because the FujiNet is in competition with Neon, but because the two complement each other very well.

 

Knowing that CONFIG has limited space available for its needs, I'm proposing two ideas:

 

1) Touch a file, leave it zero-length, give it the extension TTML (TNFS Threadbare Markup Language ?), and have CONFIG interpret the filename as the URI to redirect to.

 

2) Touch a file, give it the extension TTML, have CONFIG interpret the content of the file as the URI to redirect to.

 

I can see positives and negatives to both approaches.

 

WRT 1), a filename other than the alphanumeric hostname of a server could cause difficulties on the host OS due to characters being included in the filename that the filesystem doesn't like.  For example: tnfs.example.org.ttml would be acceptable on pretty much any OS, but tnfs.example.org/subdirectory/.ttml may not be, even with escaping certain potentially-offensive characters.

 

As for 2), CONFIG would need to interpret the content, and that (I think) would be a more memory-expensive approach than interpreting the filename.  However, it would allow for non-alphanumerics and some degree of sanitising input.  It could also be used for moving between sections of a single TNFS host's content, effectively creating symlinks between different parts of the server.

 

Any thoughts?

  • Like 1
Link to comment
Share on other sites

5 hours ago, x=usr(1536) said:

2) Touch a file, give it the extension TTML, have CONFIG interpret the content of the file as the URI to redirect to.

Seems like a nifty idea to me. As you mentioned it would increase the size of CONFIG and 'how much' is the important part. We've already surpassed the minimum requirement for stock 400 machines, which is probably not a huge deal but still sucks. Make it happen and let's see.

 

5 hours ago, x=usr(1536) said:

I began looking into it and promptly watched as 27 million more urgent things competed for (and won) my attention.

This is the biggest problem I think. There is only a tiny amount of developers working on FujiNet and we can't do everything ;) This whole project is 110% open for a reason.

  • Like 1
Link to comment
Share on other sites

40 minutes ago, mozzwald said:

Seems like a nifty idea to me. As you mentioned it would increase the size of CONFIG and 'how much' is the important part. We've already surpassed the minimum requirement for stock 400 machines, which is probably not a huge deal but still sucks. Make it happen and let's see.

Hm, OK.  What about having CONFIG pass parameters to an external binary for processing .ttml files, then acting on whatever data the external binary passes back to it?  Would that be feasible?  Potentially, it could allow for more flexibility than just simple hyperlinks, but I'll admit that the memory constraints still apply.  This is one reason why I was going for the directory service approach: it could have all been handled on the server's backend, so would have had nearly no impact on CONFIG (or, indeed, the FujiNet itself).

 

The more I think about it, the more I feel that the current model of selecting servers from slots may not be ideal for what's being proposed. It certainly works, and there's nothing wrong with it, but it does have its limitations.  Right now I don't have any solid ideas of how to change that and still have things fit into current constraints, but I'll chew on it a bit.  My off-the-cuff thought is to have five or six servers that are essentially bookmarks (i.e., one-touch access, similar to how things are now), with a slot saved for directory browsing.  Or allow browsing and/or bookmarks in any slot.  There are options; it's just a question of what's workable.

Quote

This is the biggest problem I think. There is only a tiny amount of developers working on FujiNet and we can't do everything ;) This whole project is 110% open for a reason.

Completely understood ;-)  I'm having to be realistic about my time as well, and how much I can truly contribute.

Link to comment
Share on other sites

10 hours ago, x=usr(1536) said:

What about having CONFIG pass parameters to an external binary for processing .ttml files, then acting on whatever data the external binary passes back to it?

I suppose this would work, but not really sure what the benefit is.

 

10 hours ago, x=usr(1536) said:

The more I think about it, the more I feel that the current model of selecting servers from slots may not be ideal for what's being proposed.

The use case I see for this is having a dir of TTML files pointing to other tnfs servers and when you select one, it immediately browses that server and allows mounting disk images.

Link to comment
Share on other sites

2 hours ago, mozzwald said:

I suppose this would work, but not really sure what the benefit is.

I was thinking in terms of keeping the code out of CONFIG needed to parse the .ttml file and extract the URI.

2 hours ago, mozzwald said:

The use case I see for this is having a dir of TTML files pointing to other tnfs servers and when you select one, it immediately browses that server and allows mounting disk images.

Definitely - or being able to specify multiple TNFS servers in one file.

 

FWIW, I wasn't suggesting that the slot system wouldn't work for this - just that we may be running up against UI / UX limitations with it at some point.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...