Subj : future for fido
To : Tim Schattkowsky
From : Martin Foster
Date : Sat Apr 09 2022 10:55 am
Hello Tim!
*** Friday 08.04.22 at 15:59, Tim Schattkowsky wrote to August Abolins:
SR>>>> Hi All I would have thought that this would have been a busy echo. If
SR>>>> there are any sysops intrested in discussing the future lets start an
SR>>>> echo !
TS>>> I think the Echo is related to an old project.
AA>> I haven't posted this description in a while..
TS> I think I mixed some things up :) Memory is getting worse of the years.
Yep, I know the feeling only too well :-/
TS> Of course I support the idea of this echo and would love to see even more
TS> discussion going on.
Perhaps folks might like to comment on your suggestion which you posted
recently in FTSC_PUBLIC .....
*** Thursday 10.02.22 at 14:42, Tim Schattkowsky wrote to All:
TS> Hello All,
TS> when using Fido today I regularly hit the wall when I notice that I would
TS> like to *attach at least a picture* to illustrate something. Also, people
TS> keep sendig me fido messages that refer to pictures put on their web
TS> space. This feels odd.
TS> Also, the current practice for *text styles is limited* in application
TS> and not well-defined. Still, this seems to be the minor of the two
TS> issues.
TS> I think this is really something that could/should be addressed in some
TS> way to enable relevant contemporary communication through fido.
TS> To adress this, I see _at least_ two options:
TS> 1) Do it fully email-style by using MIME with HTML text and
TS> embedded/referenced pictures. This will be a lot to implement and
TS> particularly difficult to handle in 16-Bit software due to memory
TS> restrictions and lack of frameworks. Also, memory comes to mind when
TS> considering the size of the resulting messages. Using @SPLIT, these
TS> could be extended beyound 63k, but the resulting messages might be
TS> considered an annoyance. 2) Define a simple fidonet-compatible way that
TS> is more in line with existing fido technology (particularly a maximum
TS> message length of 63k) but still enables including at least a picture
TS> and maybe simple text styles while maintaining readability on
TS> non-compatible systems.
TS> I find both alternatives interesting, but currently I prefer the latter
TS> with a focus on embedding the picture. The idea would by to have
TS> something that is more like the ability to post a picture on social media
TS> platforms. So instead of providing half a text processor for creating
TS> formatted text, people can just include the picture with their fidonet
TS> mail and ideally the editor will recompress the picture as needed to a
TS> jpg to limit the resuling message size including the encoding picture to
TS> 63k.
TS> My idea for the latter would be to include the .jpg as Base64 and add a
TS> kludge to it for inline-display. This could also be done for multiple
TS> images.
TS> An alternative would be including a link to the picture like we do today,
TS> but enabling the reader to automatically download such pictures and maybe
TS> include automated upload/linking of the image in the editor. However,
TS> that would be quite dependent on other services.
TS> *What do you think?*
TS> Regards,
TS> Tim
TS> -+- WinPoint 398.3
TS> + Origin: Original WinPoint Origin! (2:240/1120.29)
What do *I* think? .....
I absolutely love the idea of being able to use a Fido message reader
capable of displaying *inline* images in Fido messages.
