URL-та са удобна концепция, когато трябва да се укаже някакъв файл или ресурс нейде из мрежата...
В един стринг може да опишеш пълният адрес на даден файл, както и начина как да го получиш.

Примерно "http://www.example.com/data.txt"

Всичко е прекрасно, стига да нямаш повече от един мрежов интерфейс

Ако си в "multihome" система, примерно имаш GPRS, WiFi, Ethernet си остава твой проблема кой точно интерфейс да ползваш. Всяка операционна система и всяко приложение се спасяват поединично... Ако приложението е умно може да има опция за интерфейса. Примерно под Линукс на wget може да се укаже кой home да се използва, за да се дръпне файл от даден URL.
Според мен щеше да е много по-чисто ако са оставили стандартна възможност в URL-то да може да се указва и локалния интерфейс. Ама явно по-умните хора не мислят така. И все пак тъй като вече имам доста софтуер, който ползва само един стринг (URL) май ще ми е по-лесно да направя "нестандартни" URL-та.

Чудя се обаче как да го направя по-функционално... Примерно мога да направя нещо от сорта "<gprs: apn,user,pass>http://www...."

И така и така ще правя глупости, чудя дали да не вкарам и разни обработки като компресия или криптиране. Идеята е да остане само един единствен стринг, чрез който се указва един файл. Но се указва всичко необходимо за да се получи тоя файл...

И дали няма вече измислено някакво решение?

Сещаш ли се как се слага отзад номера на порта. Например нещо такова "www.example.com/data.txt:1234". Може би има начин различните портове да се рутират през различните интерфейси . Не знам дали може да се прави така, просто давам идея, която може и да е супер тъпа .

Всички елементи на URL-то се ползват за мрежовия достъп. Към тях ще е трудно да добавя каквото и да е... Още повече, че поддържам и резолване, демек като опитам да дръпна някакъв файл с абсолютен адрес, сървъра може да ме редиректне към релатив адрес и си има един куп правила кое се наследява, кое не. С две думи хич не ми се бара самото URL. По-скоро само пред него да слагам неща и трябва да има ясно разграничване кое - кое е.

Просто самото URL е много шибано. Примерно "www.example.com/data.txt:1234" няма схема, следователно е релатив линк и много зависи какъв е базовия ти линк спрямо който резолваш. Ако имаш преди това "http://www.example.org/test/file.txt" твоя линк ще резолвне на:

сайт: http://www.example.org/
път: test/www.example.com
файл: data.txt:1234

демек "http://www.example.org/test/www.example.com/data.txt:1234"

а ако има и куерита и фрагменти става пълно боза, дето хич не искам да размътвам

А какво ще стане ако ти ми дадеш линк, а аз нямам gprs интерфейс?
Dimitar имаше в предвит http://mcu-bg.com:80/mcu_site/index.php

Да, точно това имах предвид, ама съм го сложил на грешното място .

cost routing, load balancing или fail-safe никога не е било грижа на браузъра, затова на никой не му е дошло на ум да вмъква указания за интерфейса (дори не за транспортната среда) в URL.

твоя случай май е уникален, така че каквото и да измислиш ще важи само за тебе и няма да е съвместимо с никой.
според мен е по-добре да сложиш '@':

http@gprs://my.com:1234/file.txt
ftp@eth://user:pass@my.com/file.txt

Ползвай Рewrite URL или proxypass
С първото насочваш на къде да се преправи адреса с 2-то може да отваряш друг адрес спoред преправения URL

същото каквото става ако искаш да четеш несъщестуваш файл или да пишеш на несъщестуващ диск - грешка!



ех, уникален - колко да е уникален? Имам приложения дето четат или пишат файлове, като имената на файловете се задават като опции или се въвеждат от юзера.. Не е нещо необичайно

Уникалното в моя случай е само това че имам контрол върху ОС-а. Демек приложението като иска да отвори файл, то ми дава стринга с името на файла, така както е въведен. От там поемам аз и мога да върна хендъл към локален файл и хендъл към каквото си искам. Приложението изобщо няма нужда да знае къде е файла, какви протоколи и какви пътища, пароли, компресии и т.н. се ползват. Но пък аз трябва да знам какво иска приложението и най-лесният начин е всичко да е в стринга с името. Нямам ограничения за дължината, но пък не мога да мъча задклавиатурните устройства да въвеждат дълги фермани...
Та затова търся някакъв прост синтаксис, но който да е отворен. В смисъл да позволява добавяне в бъдеще на нови маршрути/протоколи и техните параметри.

Единият вариант е да добавиш допълнителен аргумент на викането освен URL, нещо като "interface selection".
Така и така наличния досега софтуер не може да ти ползва екстрата за избор на интерфейс (освен ако тя не представлява дефинирано правило според наличните аргументи - URL, процес който отваря, user, ...). Т.е. да указваш default пътя на ниво приложение според user-а, т.е. при стартиране на даден таск да му се дава (по правила, или по изискване от него) на "предпочитан" или пък "задължителен" интерфейс.
На ниво стек това се настройва с "route" командата - според адреса от URL-a се избира през къде от дефинираните пътища. Има си и default gateway за изхода (който е в дадена мрежа, т.е. интерфейс). Не знам дали там не може да се нагласят нещата според user id.

Това ми беше първоначалния вариант... Но тогава мислех като програмист
Всеки интерфейс/драйвер при отваряне на хендъл иска структура, която си е специфична за него. Естествено така става много по-бързо, няма парсвания няма нищо. Всички параметри са подготвени в удобен формат още по време на компилация...
Но после се наложи да става динамично, т.е. run time се избира интерфейс/драйвер. И обикновено избора се подава като стринг и попълването на структури стана неприятна работа. Та на следващия етап поизчистихме малко функциите и ги сведохме до файлови, gprs и етернет. Всички вече работят само с един стринг, просто стринга е име на файл или URL. Но са различни функции...
Сега обаче се иска динамично да се променя и избора между файл и URL-та за различни интерфейси...

Иначе триковете при РС долу-горе ги знам, ама не съм на РС
Нямам юзери, нито gateway... но и да имах това нямаше да ми помогне. Нещата трябва да се променят run time...

Нещо такова бих направил и аз, само бих му поизчистил йерархията:

device:http://whatever...
или по-DPS-чено:

#dev/http://... .